claude-code - 💡(How to fix) Fix [FEATURE] Surface the active Claude Code environment (CLI / Desktop Code tab / Cowork) in the model's context [1 comments, 2 participants]

Problem

When I'm using Claude Code, the model has no awareness of which surface I'm working in:

• Claude Code CLI (claude in a terminal)
• Claude Code in the Code tab of the Claude Desktop app
• Cowork tab in the Claude Desktop app

These three surfaces share a lot of plumbing (~/.claude/settings.json, plugins, skills, MCP servers) but differ in meaningful ways:

• Available slash commands — e.g. /plugin marketplace add works in the CLI but my Code tab in Desktop returned /plugin isn't available in this environment
• How sessions/windows work — Cmd+N + sidebar in Desktop vs claude + interactive prompt in CLI
• Cowork's frozen skill bundle vs the Code tab's live ~/.claude/skills/ symlinks
• Pane availability — Terminal pane only in local Desktop sessions; absent in Cowork; absent in CLI
• Permission and approval models look slightly different
• Computer-use availability and tier rules

Today, the model just sees currentDate, the cwd, and basic OS info. It has to guess which surface I'm using based on indirect signals (which slash commands are available, plugin namespace prefixes that appear in the skill list, etc.) — and it gets it wrong, repeatedly.

A concrete recent example

I asked Claude to help install a plugin. I'm in the Code tab of the Desktop app. The model:

1. Misidentified my session as Cowork based on plugin namespace prefixes in the available skill list.
2. Recommended two slash commands that, when I tried them, returned /plugin isn't available in this environment.
3. Recommended a workaround that involved packaging skills as .skill files — the Cowork-specific path — when the right answer was just to use the Code tab's actual plugin install flow.
4. Wrote a long explanation conflating "Claude Desktop" with "Cowork," even though those are different tabs in the same app.

I had to correct the model multiple times. The information it needed to behave correctly was already in my project-level memory — but the model didn't know to look there because it didn't know which surface it was in.

Why it matters

Recommendations from the model are only as good as its knowledge of the operating environment. Telling someone in the Code tab to "run /plugin install in your terminal" is wrong; telling someone in CLI to "open Settings and click X" is also wrong. The capability matrix across surfaces is non-trivial and seems to keep diverging as Claude Code spreads to more surfaces (CLI, Desktop tabs, IDE extensions, web, mobile remote control).

This is foundational context — at least as important as currentDate, arguably more important, since it changes the entire menu of viable actions the model can recommend.

Suggested fix — part 1: tell the model where it is

Surface the active Claude Code environment to the model on every turn, the same way currentDate is exposed today. One line is enough:

claude-code-environment: desktop-code-tab

…with possible values like cli, desktop-code-tab, desktop-cowork, desktop-chat, vs-code-extension, jetbrains-plugin, web — whatever set of surfaces the team supports.

Bonus points for including the app/CLI version so the model can also reason about features that have shipped or been removed since training cutoff.

Suggested fix — part 2: tell the model what that environment can DO

Knowing the surface is half the battle. The model also needs current knowledge of what each surface is capable of — and these surfaces evolve fast (new panes, new shortcuts, new slash commands, deprecated flags, changing permission models). Training data goes stale within months.

Two reasonable ways to keep the model honest, in order of preference:

Option A — Anthropic-maintained skills, auto-loaded by environment. Ship official skills (one per surface, or a consolidated one with sections) that document each environment's current capabilities: available slash commands, panes, shortcuts, plugin install flow, permission modes, what's NOT supported, etc. The model auto-loads the relevant one based on the environment ID. Skills are already the right abstraction for this kind of just-in-time procedural knowledge — and Anthropic can update them in lockstep with product changes, giving the whole user base a single source of truth instead of a drift-prone training cutoff.

Option B — bake it into the system context directly. Higher token cost, harder to update independent of model rollouts, but guaranteed visibility.

Either is fine. The status quo — where users like me write our own reference_claude_code_desktop.md files in personal memory just to give the model a fighting chance — should not be the path Anthropic relies on. It's asking individual users to compensate for missing first-party context, and the results vary wildly depending on whether someone thought to do it.

Why this matters to me

It's genuinely frustrating that an Anthropic application running an Anthropic model has no idea what Anthropic surface it's running in, or what that surface is currently capable of. I'm filing this issue from a Code tab in the Desktop app — the model that helped me draft it had to be corrected mid-conversation because it assumed I was in Cowork.

I currently maintain a hand-written 200-line reference file in personal memory that documents how the Desktop app works, including a section on "when this memory is stale, re-fetch the source URL." That shouldn't be on me. As Claude Code spreads across more surfaces (CLI, three Desktop tabs, IDE extensions, web, mobile remote control) this gap only grows.