claude-code - 💡(How to fix) Fix [FEATURE] Configurable default session accent color (env var / settings key / agents flag)

Preflight

• Searched existing issues; no open request for a configurable default session accent color.
• On the latest Claude Code release; behavior reproduced in both interactive and claude agents sessions.

Problem Statement

The per-session accent color (the rule above/below the input box and the session-name label, set via /color) is the only way to color a session, and it is:

• assigned a random/default value on every new session,
• settable only interactively via /color <name>,
• scoped per-session with no global or launch-time default.

There is no --color CLI flag, no settings.json key, no environment variable, and the claude agents (background-agents) subcommand accepts no name/color/initial-prompt seam at all. So every agent spawned from the background-agents view comes up in the default color and must be re-colored by hand.

This matters most when the accent color is being used as a safety signal. Concretely: we run Claude Code in multiple WireGuard-bound network namespaces, one per environment (dev / demo / travel / customer kits). A launcher wrapper already sets a per-kit env var and a statusline badge so the operator always knows which isolated environment — and which live tunnel — a session is bound to. The input-box accent would be the strongest at-a-glance reinforcement of that, but because it can't be defaulted, every background agent starts in an ambiguous default color, defeating the "instantly see which environment I'm acting against" goal precisely where mistakes are most costly.

Proposed Solution

Any one of these (in rough order of preference) would fully solve it:

1. CLAUDE_DEFAULT_COLOR (or similar) environment variable — read at session start as the initial accent when no per-session override exists. Trivial for launcher wrappers/netns/profile setups to set per-environment; requires no Claude-side config plumbing.
2. settings.json defaultColor key — same effect, scoped via the existing user/project/local settings hierarchy.
3. claude agents honoring --color <name> (and ideally an initial /color prompt), so the background-agents view has the same launch-time seam interactive sessions could use.

The named-color palette /color already accepts is sufficient; this is purely about supplying that value at launch instead of only interactively.

Alternative Solutions

• Terminal-emulator profiles (e.g. Windows Terminal) per environment — works for the terminal chrome but cannot touch Claude Code's in-TUI accent and does not survive into the background-agents view.
• Manually running /color <name> in every spawned agent — current workaround; error-prone and easy to forget in exactly the high-risk multi-environment case.
• Resuming a single pre-colored session per environment instead of spawning new ones — sacrifices the multitasking the background-agents view exists for.

Priority

Medium

Feature Category

CLI / Configuration

Use Case Example

# launcher binds the session to an isolated per-environment netns + tunnel
export CLAUDE_DEFAULT_COLOR=green     # dev
export CLAUDE_DEFAULT_COLOR=orange    # demo
export CLAUDE_DEFAULT_COLOR=purple    # travel
claude agents
# every agent in the background view opens in the environment's color,
# with no manual /color and no chance of acting against the wrong tunnel blind

Additional Context

/color persists per-session and shows in the /resume picker, so the color model and palette already exist — the only gap is a non-interactive way to supply the initial value (env var / settings key / agents flag). Operators using Claude Code for environment-isolated / multi-tenant / production-vs-lab work would benefit from the accent being a reliable, automatic environment indicator rather than a manual per-session step.