/color reports success but has no visual effect in the Desktop app (macOS)

Summary

In the Claude Desktop Code tab, /color <name> prints a success message and changes nothing. The command parses, is accepted, and reports Session color set to: orange - but no prompt bar, chrome, or other UI element changes colour.

This is not the same as the existing /color issue cluster (see below), all of which assume the colour renders and ask for it to persist. Persistence is moot when the colour never appears at all.

Environment

• Claude Code 2.1.214
• macOS (Apple Silicon), Claude Desktop app, Code tab
• macOS system appearance: Dark
• No custom theme; ~/.claude/settings.json has "theme": "light" (also ignored - the app follows system appearance)

Steps to reproduce

1. Open the Claude Desktop app, Code tab, in any project.
2. Run /color orange (or any of red/blue/green/yellow/purple/pink/cyan).
3. Observe the confirmation message.

Expected: the prompt bar renders in the chosen colour, as it does in the CLI.

Actual: Session color set to: orange is printed. No visual change anywhere in the window. Repeating with other colours behaves the same.

Nothing is written to disk: after running the command there is no colour key in ~/.claude/settings.json or settings.local.json, and no file under ~/.claude is modified.

Why this is worth separating from the persistence requests

statusLine is likewise ignored in the Desktop app (#41456), but it fails silently. /color gives positive confirmation of an action it does not perform, which is worse: there is no signal that anything is wrong, so the natural conclusion is that the user did something incorrectly.

Existing /color issues, all about persisting the colour across sessions rather than about it not rendering: #39517, #38368, #51493, #28708, #49293, #44002.

Documentation gap

https://code.claude.com/docs/en/desktop has a "What's not available in Desktop" section listing third-party providers, Linux Computer Use, inline code suggestions, agent teams, and terminal-dialog commands (/permissions, /config). Neither /color nor statusLine is listed, so there is no way to discover the limitation short of trying it.

If this is intended behaviour rather than a bug, both belong in that list.

Note on history

We have no evidence /color has ever rendered in the Desktop app; we have not tested earlier versions, so "never worked" is our impression rather than a verified claim.

Motivation

The underlying goal is telling concurrent sessions apart at a glance. The desktop app already renders the project name twice (title chip and the git bar above the composer), and that was still not enough to prevent instructions intended for one project being typed into another twice in one day - which is why a pre-attentive cue like colour matters, and why #65595 (assign colours to projects) is the feature this bug currently blocks from being self-served.

Workaround that does work today, for anyone finding this: /rename 🟦 <name> puts a coloured emoji in the session title chip, and SessionStart hooks can set it automatically via hookSpecificOutput.sessionTitle.