[FEATURE] Project-scoped session name prefix and color in settings.json (16th filing, please triage instead of stale-closing)
Preflight Checklist
- [x] I have searched existing requests. This has been requested at least sixteen times since March 2026. Every filing was either auto-closed as stale or closed as a duplicate of another filing that was then auto-closed as stale. The full list is below. Not one received a design decision.
- [x] This is a single feature request: a project-scoped default for the two attributes the session chip already has, its name and its color.
Problem Statement
Claude Code is explicitly a multi-session product now. --name, --bg, /rename, /color, claude agents, the tab bar and the fullscreen session lists exist so that one person runs five to ten sessions at once. What is missing is the one thing that makes those sessions recognizable at a glance: a stable per-project identity on the chip.
Both attributes of the chip are per session today, and both reset on every new session:
- The name comes from
-n/--name,/renameor the AI-generated title. Every new session in the same project starts blank or with a fresh AI title, and AI titles collide across projects (#91054). - The color comes from
/color(or from an agent definition'scolorfrontmatter) and is persisted as anagent-colorentry in that session's transcript. A plainclaudein a project directory has no color of its own, and/cleareven drops it (#96295, #74352).
Identity is tied to the wrong object. The project is what stays constant across sessions and the project is what the user is trying to recognize. Session-level naming solves "which of my ten tabs is which" only if I retype the same name and color ten times a day, on every surface (terminal, VS Code, desktop), because shell aliases do not reach the extension or the app.
The workaround people have converged on is a hack with side effects: define an agent under .claude/agents/ purely for its color and start every session with --agent. That swaps in the agent's system prompt and changes model behaviour to get a colored chip. Others run terminal-specific hooks (#36928 comments). A cosmetic preference should not require either.
Proposed Solution
Add a project-scoped display block to settings.json, the file that already carries every other per-project setting, resolved through the normal user, project and local precedence:
{
"display": {
"namePrefix": "WIN",
"color": "green"
}
}
Semantics:
display.namePrefixis prepended to whatever session name the existing sources produce:WIN: fix login flowfor an AI title,WIN: apifor--name api,WINalone when there is no name yet. A prefix composes with the current name sources instead of competing with them, so--name,/renameand AI titles keep working unchanged. It also gives every project a namespace, which is exactly what #88939 and #72555 ask for on the cross-session messaging side, and what the collision dedup in #91054 lacks.display.coloris the default chip color when no/colorhas been issued in that session and no agent color applies. An explicit/coloror an agent'scolorstill wins for that session.- Accepted color values are the ones
/coloraccepts today. Hex support is a separate, also stale-closed request (#74447) and should not block this one. - The prefix also seeds the terminal title (the path
terminalTitleFromRenamealready uses), theclaude agentslist, the session pickers and the peer-registration name used byListAgentsandSendMessage. One setting, one identity, everywhere the name is shown. - Absent block, absent key or invalid value: current behaviour. No new warnings beyond the existing settings validation.
Why this is a small change, not a design project:
- The rendering, persistence and resume plumbing for a named, colored chip already exists (
agentName,agentColor,standaloneAgentContext, theagent-nameandagent-colortranscript entries). This adds one more source for those two values with a defined precedence. settings.jsonalready has project scope and a strict zod schema with.describe()documentation. One nested object with two optional strings is the entire schema change.- Backward compatibility is total. Nothing is removed or re-keyed.
Why settings.json and not a new file: #57849 proposed .claude/config.json. No such project file exists in the current build, and a second per-project config file for two keys would be worse than the problem.
Prior filings of this request
Open, never triaged:
- #34121 (2026-03-13) Persist prompt color across sessions via settings.json
- #36928 (2026-03-21) Add persistent session color setting
- #58588 (2026-05-13) Allow /rename and /color to be set programmatically at session start
- #88939 (2026-08-23) Configurable peer-registration session name (per-project prefix)
- #90987 (2026-08-31) Reopening request: tab color/visual differentiation for concurrent sessions
- #7229 (2025-09-06) and #94368 (2026-09-14) Terminal title settings, the name half of this request
Closed as stale by the bot, no maintainer comment:
- #43216 per-project persistent color/theme settings
- #57849 per-project color and display-name override
- #60476 customizable mascot color per project
- #62754 session display name via hook or CLI flag
- #63264
sessionColorandsessionNamein.claude/settings.json - #72209 VS Code: distinct per-tab color to tell sessions apart
- #73570 tab groups color-coded by project
- #75406 persistent session color via settings.json or CLI flag
- #78203
--colorCLI flag - #87122 setting to hide the session-name badge
- #87202 expose the session color to statusLine and hooks
Closed as duplicates, pointing at issues that were then stale-closed or never triaged:
- #64449, #66642, #77839, #79350, #72555 closed as duplicates
- #86353 was closed by a maintainer with "duplicate of #75406, please follow and upvote that issue so we can track it in one place". #75406 was then auto-closed as stale on 2026-09-20 without a comment.
That last chain is the reason this filing is worded the way it is. Users did what they were told, consolidated onto the canonical issue, and the bot closed the canonical issue.
Alternative Solutions
--nameand/colorin a shell alias per project. Terminal only. The VS Code extension and the desktop app do not run my alias, and I have to redo it on every/clear.- Agent definition with
colorplus--agent. Stable colored chip, but the session now runs a different system prompt. The fact that this is the best available workaround is the strongest evidence the feature is missing. statusLine. Text under the prompt, not the chip, not in the tab bar or the session lists, and it cannot read the session color (#87202).- SessionStart hook injecting
/color. Tried in #85951, does not run slash commands. - A mod through the hooks API. The chip is not exposed to mods, and "write a plugin" is not an acceptable answer for a two-key preference.
What I am asking for from maintainers
- A triage decision on the merits: accepted, declined with a reason, or a concrete blocker. Sixteen filings and zero design comments in six months is a process failure, not a signal that nobody wants it.
- If accepted but not scheduled, a label that exempts this issue from the stale bot, so the next person is not told to consolidate onto an issue that will be closed anyway.
- If declined, a one-paragraph reason on this issue, so people stop filing it.
- If it is a green light but not a priority for the team, say so. We are ready to implement it ourselves and submit a PR, with the schema key, the precedence rules above, the resume path and tests. The application source is not in this repository, so that needs a contribution path from your side; a design ack and a pointer are enough for us to start.
Priority
High. Everyone who runs several sessions across several projects pays this cost every day, on every surface, and the product's own direction (background sessions, fleet view, tab bar, cross-session messaging) multiplies it.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗