[Feature Request] Unify Chat, Cowork, and Code tabs into a single adaptive interface

Problem Statement

The Claude Desktop App currently presents three separate tabs — Chat, Cowork, and Code — each offering a different interaction mode with the same underlying model. This forces users to decide upfront which "mode" of Claude they need, switch tabs when their task evolves, and lose conversational context when they do.

In practice, real work doesn't fit neatly into one tab:

• A conversation that starts as Chat ("how should we architect this?") naturally evolves into Code ("ok, implement it") and then Cowork ("let me review what you did")
• Switching tabs breaks the thread — the user re-explains context or starts over
• Users who discover one tab may not realize the capabilities in the others exist

The three-tab model reflects internal product boundaries, not user workflows.

Proposed Solution

Replace the three tabs with a single adaptive interface that fluidly shifts modes based on what the user and agent are doing:

1. Conversation is the baseline — Every interaction starts as a conversation (currently "Chat"). No mode selection required.

1. Tool use surfaces contextually — When Claude needs to read files, run commands, or edit code, the Code-mode tool panel appears inline or in a sidebar — not in a separate tab. The conversation thread remains continuous.

1. Cowork emerges from collaboration — When the user and Claude are co-editing, reviewing, or iterating on artifacts, the interface adapts to show shared workspace elements (diffs, previews, file trees) alongside the conversation. This is currently "Cowork" but shouldn't require a tab switch to access.

1. Mode indicators, not mode selectors — Instead of tabs the user clicks to switch modes, show subtle indicators of what capabilities are currently active (e.g., "Claude has file access", "Preview active", "Editing src/app.py"). The user sees what Claude can do without having to enable it.

Use Case

A developer opens the Claude Desktop App and says: "Let's review the changes I made to the auth module today."

In the current design, this requires choosing the right tab. Is it Chat (just talking about it)? Code (looking at files)? Cowork (reviewing together)?

In the proposed design, the developer just asks. Claude reads the git diff (tool use surfaces automatically), discusses the changes (conversation), and offers to fix an issue it spots (editing surfaces automatically). One continuous thread, no tab switching, no context loss.

Why The Current Design Creates Friction

• Discovery problem — Users in Chat don't know Code exists. Users in Code don't know Cowork exists. Each tab hides the others' capabilities.
• Context fragmentation — Switching tabs starts a new context. The architectural discussion in Chat doesn't carry into the Code session.
• Decision fatigue — "Which tab do I need?" is a question the user shouldn't have to answer. The agent should adapt to the task, not the other way around.
• Redundant UI surface — Three tabs sharing the same model, same account, same project — with different subsets of capability artificially separated.

Precedent

This mirrors how IDEs evolved. Early IDEs had separate modes for editing, debugging, and terminal. Modern IDEs (VS Code, JetBrains) present a unified workspace where panels appear contextually — the debugger shows up when you're debugging, the terminal when you need it, the editor always. Users don't switch "modes" to access different capabilities.

Success Criteria

• A user can go from conversation → code editing → review → back to conversation without switching tabs or losing context
• All current Chat, Cowork, and Code capabilities are accessible from a single starting point
• The interface visually adapts to show relevant panels (file tree, diff view, terminal, preview) based on what the agent is doing — without the user manually selecting a mode
• Zero increase in onboarding friction — a new user who just wants to chat can do so without encountering IDE-like complexity