[FEATURE] Allow /rename and /color to be set programmatically at session start

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/58578
2. https://github.com/anthropics/claude-code/issues/40393
3. https://github.com/anthropics/claude-code/issues/35378

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

+1 on this — adding a use case the current proposal doesn't quite cover.

I also run multiple Claude Code sessions on the same repo concurrently (different worktrees, parallel agents, etc.). Solution 1 as written ({ "session": { "color": "grey" } }) gives every tab on that repo the same colour, which puts me back where I started.

Two small extensions that would close this gap:

• Solution 1 enhancement: accept a palette/family value. e.g. "color": "random:grey" or "color": ["grey-1", "grey-2", "grey-3"] — Claude Code picks a different one per concurrent session.
• Solution 3 enhancement: explicitly allow the SessionStart hook to return a colour name in hookSpecificOutput (alongside additionalContext). That lets users implement any policy — random shade, hash of worktree path, hash of session ID — without Claude Code having to bake it in.

Bare /color (2.1.128) already does the random pick inside the session; the only missing piece is automating it at start.

Author here.
Keeping this open - the 3 flagged "duplicates" each cover one slice; this issue is the consolidation, and the slices don't overlap enough to fold into any single one.

Coverage gap:

• #58578 - settings.json defaults for name/colour; no CLI flags, no hooks, no worktree story.
• #40393 - --color / --title CLI flags only; no project config, no hooks.
• #35378 - --name or hooks for the banner name; no colour at all.

This issue asks for all three surfaces (project config + CLI flags + SessionStart hook output) so users can pick whichever fits their workflow.

+1 to @agsonsmith's worktree extensions - same problem here (10+ concurrent sessions, some on the same repo via worktrees).
Concretely:

1. settings.json should accept a palette/family, e.g. "color": "random:grey" or "color": ["grey-1","grey-2","grey-3"], so

concurrent sessions on one repo don't all collide on the same shade.

1. SessionStart hook should be allowed to return a colour name in hookSpecificOutput alongside additionalContext, so users can

implement any policy (random, hash of worktree path, hash of session id) without Claude Code baking it in.

Happy to close in favour of a single consolidated issue if maintainers prefer - just flagging that the 3 currently flagged don't add up to the full ask.

@SueSingh You can try:
claude -n "test" "/color yellow"

+1 on this. Concrete use case: I'm an IC running multiple businesses (an MSP, an
AI automation lab, my wife's e-commerce shop, a 3D-printing side line) plus a job
search, all from the same workstation. At any moment I have 5-10 Claude Code
sessions open across as many repos.

Visual disambiguation between sessions matters a lot when context-switching.
I currently /color each session manually after launch, but I forget about
half the time, and the muscle-memory taxes the very switch the color is meant
to ease.

What would actually help: a single field in .claude/settings.json read at session
start, e.g.

{ "sessionColor": "hexcode" }

Project-level overrides global, the UI honors it without a prompt. No new
slash-command-from-hook plumbing required if the setting is read directly.

Bonus value if cloud Claude Code sessions can render the same color hint, since
I bounce between local + web frequently and the disorientation cost is identical.

Happy to test a prerelease if it helps.

Author here, reporting back.

@zbrkic thanks - tried the -n + /color approach. What worked and what didn't, for the thread:

Worked: the -n / --name flag. It reliably sets the session name, and - notably - the Windows Terminal tab title under WSL2 as well. My original post assumed that was impossible (escape sequences not reaching Windows Terminal); it isn't. This flag also wasn't available when I filed - it shows up in the changelog around v2.1.144 - so it's a recent addition that now fully covers the name/title half of this request.

Didn't work for my setup: /color as the launch command. claude -n 'name' '/color yellow' only colours the session if /color is the one command you launch with. My profiles already launch /start-session, and the initial prompt accepts a single slash command - the second is treated as text (the limitation in the original post). So it's /start-session or /color, never both. zbrkic's one-liner works only for launches that don't already dispatch a command.

How I got colour working anyway - outside Claude Code. Each project has its own Windows Terminal profile with "tabColor" set in settings.json. The OS tab is colour-coded on launch. Caveats: it colours the Windows Terminal tab, not the in-Claude /color accent; and being per-profile it does nothing for @agsonsmith's and @Mfrostbutter's same-repo / worktree case - every session on that profile gets the same colour.

Net: -n covers the name half. The colour half still has no in-Claude answer that survives an existing launch command. The ask stands: color in .claude/settings.json (palette-aware, per @agsonsmith), or a --color flag that doesn't compete with the initial-prompt slot.

+1 — running into the same gap in a different workflow.

Concrete asymmetry worth highlighting: the SessionStart hook already supports sessionTitle via hookSpecificOutput, so the auto-naming half of this request works today:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "echo '{\"hookSpecificOutput\": {\"sessionTitle\": \"my-project\"}}'" }
        ]
      }
    ]
  }
}

Adding an analogous sessionColor field to hookSpecificOutput would be the minimal change that closes the loop for everyone using per-project hooks. The settings.json and CLI-flag variants would still be nicer, but the hook field alone would already unblock auto-color-coding per repo.

+1. Use case: launching multiple parallel sessions from shell functions/terminal profiles, each needing a distinct color and name for visual identification. --name <name> already exists for the rename half; a matching --color <color> flag (or env var / settings key) would complete it. Currently the only path is manually typing /color in every session, which doesn't work for scripted launches.

+1 for --color {color} shell arg

I would just add a small enhancement: If I /rename a session to a colour that is also available via /color, update the TUI with that colour. If I start up a session with a name like 'red', then also color that terminal red; iff there's a colour param also provided with the name, then respect that more-specific colour choice.

+1 for --color or something in json

Typing /rename in ten tabs every morning got me too. magent (https://magent.now) opens each project in its own Windows Terminal window running claude --continue and sets the window title from outside the process, so the WSL2 escape-sequence limit doesn't bite. It won't touch the in-Claude session name or the color, so it only fixes the tab-identity half of this. I work on it.

+1 — same need: auto-name and auto-color each session from the first prompt (e.g. open Claude Code, ask for a code review, and the session names itself "Code review — <project>").

Some findings from digging into how /rename and /color persist (v2.1.220, Windows 11):

• Both are stored as records appended to the session's .jsonl transcript: {"type":"custom-title","customTitle":"...","sessionId":"..."} and {"type":"agent-color","agentColor":"purple","sessionId":"..."}. The live session registry ~/.claude/sessions/<pid>.json also carries name + nameSource (derived vs user).
• Externally appending those records mid-session (simulating what a UserPromptSubmit hook could do) partially works: the Windows Terminal tab title and the /resume list pick up the new name, and the title/color are replayed on resume.
• But the running TUI never re-reads them: the prompt bar label and color stay on their in-memory state, so there is no way to affect the live UI from outside.

So the persistence layer is already there — what's missing is just a supported write path that the TUI applies live. Either of these would solve it:

1. A hook output field, e.g. {"hookSpecificOutput": {"sessionName": "...", "sessionColor": "..."}} on SessionStart / UserPromptSubmit, or
2. A CLI/control-protocol command (claude session rename <name> --color <color>) targeting a running session.

Option 1 on UserPromptSubmit would be ideal: the hook sees the first prompt, so it can derive a meaningful title from the actual task.

Two things worth adding here, one on the hook side and one on the colour side.

The hook side. A UserPromptSubmit hook can run arbitrary code from a typed token with no model turn, by returning decision: "block" together with hookSpecificOutput.suppressOriginalPrompt: true, and exiting 2. That is not /color becoming programmable, but it does mean "type ,web, something happens, no turn burned, nothing added to the transcript" is available today without waiting on a CLI flag.

Two details that are easy to lose an hour to:

• It must be synchronous. The async flag's own schema says the hook runs in the background without blocking, so an async hook returns after the prompt already reached the model and cannot gate anything. Nothing warns you.
• Exit 2 as well as printing the JSON. With exit 0 you take a success branch that appends a spurious "completed" line and reports the outcome as success.

It only fires at an idle input box. Typed mid-turn the message goes straight to the model, so it is not a general-purpose RPC.

The colour side. My own approach paints the terminal window rather than the Claude Code prompt bar, which sidesteps the escape-sequence problem in the original post entirely, because it never goes through the terminal in the first place. It drives macOS Terminal.app through AppleScript.

That means it is no help at all on WSL2, and I would rather say that plainly here than have someone install it and find out. The Windows Terminal equivalent is driving the profile from outside the process, which is roughly what magent does in the comment above. Worth noting that Terminal.app is the one terminal with no native per-tab colour at all: iTerm2, kitty and Ghostty already have it, so on those the whole problem is a config line rather than a tool.

https://github.com/dotcomjack/claude-session-tint if the hook pattern is useful to lift. MIT.