[FEATURE] Surface the active Claude Code environment (CLI / Desktop Code tab / Cowork) in the model's context

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.

1. Recommended two slash commands that, when I tried them, returned

/plugin isn't available in this environment.

1. 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.

1. 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.