[FEATURE] Project-scoped session name prefix and color in settings.json (16th filing, please triage instead of stale-closing)

Status Open
Maintainer reply None cached
Activity 1 comment · opened Sep 23, 2026

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, /rename or 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's color frontmatter) and is persisted as an agent-color entry in that session's transcript. A plain claude in a project directory has no color of its own, and /clear even 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:

  1. display.namePrefix is prepended to whatever session name the existing sources produce: WIN: fix login flow for an AI title, WIN: api for --name api, WIN alone when there is no name yet. A prefix composes with the current name sources instead of competing with them, so --name, /rename and 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.
  2. display.color is the default chip color when no /color has been issued in that session and no agent color applies. An explicit /color or an agent's color still wins for that session.
  3. Accepted color values are the ones /color accepts today. Hex support is a separate, also stale-closed request (#74447) and should not block this one.
  4. The prefix also seeds the terminal title (the path terminalTitleFromRename already uses), the claude agents list, the session pickers and the peer-registration name used by ListAgents and SendMessage. One setting, one identity, everywhere the name is shown.
  5. 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, the agent-name and agent-color transcript entries). This adds one more source for those two values with a defined precedence.
  • settings.json already 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 sessionColor and sessionName in .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 --color CLI 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

  • --name and /color in 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 color plus --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

  1. 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.
  2. 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.
  3. If declined, a one-paragraph reason on this issue, so people stop filing it.
  4. 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗