[BUG] Merged Home: chat threads and Cowork sessions coexist in one project with different capabilities and no visible mode indicator

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of the desktop app

What's Wrong?

Since the Chat/Cowork merge, a Cowork project's thread list holds plain cloud-chat threads and Cowork sessions side by side, and nothing in the sidebar, the thread header, or the composer says which kind a given thread is. The two kinds have very different capabilities — a Cowork session has the connected local folders, the sandbox shell, local MCP servers (Desktop Commander etc.), project skills, and the scheduled-task tools; a chat thread inside the same project has none of those — but the only way to find out which one you are in is to ask it to do something and watch it fail.

That is not a cosmetic gap. It cost me a full working session today, and it is the second time.

What happened (2026-09-16)

1. Inside my Cowork project "Project Tracking and To-Dos" I opened what I believed was a Cowork session and gave it a detailed, multi-step instruction: verify the host machine via Desktop Commander, read four library files from the connected folder, create a scheduled task (morning-packet-append, 45 5 * * *), write its SKILL.md, run the hygiene check, and update the roadmap.
2. The first step — scutil --get LocalHostName via Desktop Commander — "timed out after 4 minutes." The assistant told me to check for a pending approval prompt in the desktop app. There was no prompt, because the thread had no Desktop Commander at all; it was a cloud chat.
3. I had the assistant look for the scheduled-task tools. Its words: "the tool that would let me create the scheduled task directly isn't in my toolset in this conversation, however this surface is officially categorized." It could not tell me what kind of thread it was either, and admitted its earlier claim about what the sidebar proved was "an inference dressed up as certainty."
4. Its proposed test was to type /schedule and see whether anything fired. Nothing did. Its summary: "whatever this session is called, create_scheduled_task and every variant I searched for are not in my tool list … That's a fact about this specific conversation, not a claim about Cowork in general."
5. Its closing diagnosis, which is the bug: "a Project can apparently hold both plain chat threads and actual Cowork tasks side by side, with nothing in the interface distinguishing them once you're inside one … It's not you missing a UI cue; there wasn't a reliable one to find."

So the model spent most of an hour trying to introspect its own session type by trial and error, and I spent that hour with it, because the app that knows the answer does not display it. The scheduled task still does not exist.

Why the existing threads don't cover this

• #94538 reports that the Chat/Cowork picker appears only on the empty composer and a started thread is locked to its mode. This issue is the consequence: if a thread is locked to a mode, the UI has to show which one. It doesn't.
• #40750 asked for capability indicators instead of mode tabs. The merge shipped the unification without the indicators.
• #94752 is the same failure for the Chat/Code toggle (too small to tell which is highlighted).
• #76694 / #85930 / #90402 are the project-folder and sidebar regressions from the same rollout; this issue is about the thread list they left behind.

What Should Happen?

1. Every thread in a project's list carries a persistent, unmistakable mode badge (Chat vs. Cowork) — in the sidebar row and in the open thread's header.
2. The composer in a chat thread inside a Cowork project states what the thread cannot do (no local folders, no local MCP, no scheduled tasks) before the user types into it.
3. A project's default "new thread" action inside a Cowork project should create a Cowork session, or ask — not silently create a cloud chat that then lives beside the real ones.
4. Ideally: the model itself is told its session type in-context so it can say "this is a chat thread; open a Cowork session for that" on the first turn instead of the tenth.

Is this a regression?

Yes. Before the merge, Cowork tasks and chats lived in separate tabs with separate lists, so a thread's kind was given by where you found it.

Environment

• Claude Desktop 2.110.0 (Info.plist CFBundleShortVersionString), macOS 26.5.1, Apple Silicon
• Cowork project with a connected local folder; the failing thread appears in that project's list
• Claude Code Version: N/A — desktop app (merged Chat/Cowork Home), filed here because Cowork/desktop regressions from the merge are tracked under area:cowork / area:desktop