Show project/directory name as prefix in terminal tab title

Status Closed — not planned

Maintainer reply None cached

Activity 8 comments · opened Feb 16, 2026 · closed Apr 13, 2026

Problem

When working with multiple Claude Code sessions across different projects, all terminal tabs look the same. Claude Code already sets the terminal title dynamically (with AI-generated context summaries), but there's no indication of which project a terminal belongs to.

For example, I might have Claude Code running in ~/code/support, ~/code/webapp, and ~/code/api simultaneously. All tabs show context like "Searching for emails" or "Editing CLAUDE.md" but I can't tell which project each tab is for without clicking into it.

Proposed Solution

Include the project/directory name as a prefix in the terminal title that Claude Code sets via OSC escape sequences.

Instead of:

Searching for emails

Show:

support - Searching for emails

The prefix could be derived from:

The current working directory basename (simplest)
A configurable terminalTitlePrefix in .claude/settings.json (most flexible)

Configuration Example

// .claude/settings.json
{
  "terminalTitlePrefix": "Parfinity Support"
}

If not configured, fall back to the directory basename.

Use Case

Anyone running Claude Code across multiple projects in parallel (common for developers managing several repos) would benefit from being able to visually distinguish terminals at a glance.

Related Issues

#25789 (update title on /rename) - complementary, focuses on session name
#25550 (conversation context in VS Code tab title) - related, VS Code specific
#25307 (configurable state indicators) - related, focuses on state display

View original on GitHub ↗

8 Comments

svenefftinge · 6 months ago

Additional context: There's already CLAUDE_CODE_DISABLE_TERMINAL_TITLE as an env var to disable the title-setting behavior entirely. This means the infrastructure for managing terminal titles is already in place. Adding a configurable prefix (or defaulting to the directory basename) would be a natural extension of the existing mechanism.

babs · 6 months ago

I'd add, general customization with place holders to allow users to choose as prefix or suffix, cwd, git repo, maybe a project metadata set and retrieved from the $PROJDIR/.claude/settings.local.json ?

// .claude/settings.json
{
  "terminalTitleTemplate": "${CLAUDE_SUMMARY} [${CLAUDE_METADATA_PROJ_NAME:-$PWD}]"
}

hakanensari · 5 months ago

+1 — Same pain point here with git worktrees. Running claude --worktree 577-order-change-sync creates isolated checkouts for parallel feature work, but all tabs look identical.

The directory basename prefix would work perfectly for this. A worktree named 577-order-change-sync would show as:

577-order-change-sync · discussing order sync

The configurable terminalTitlePrefix in settings is a nice escape hatch for when the directory name is too long or not descriptive enough.

(Closed my duplicate #31894 in favor of this one.)

brianruggieri · 5 months ago

Hey, I built something that solves this today and I just stumbled on this issue. ccp is a bash wrapper for the Claude Code CLI that sets each pane's title to project (branch) | task | status using hook events. If you're running worktrees in parallel, each pane gets its own independent title so 577-order-change-sync and main show up separately without any config.

The task label can also be AI-generated, which I've seen mentioned in some other issues. There's an opt-in flag that distills your prompt into a 3-5 word summary, so instead of just the directory name you get something like 577-order-change-sync(feat/order-sync) | Fix order sync bug | Testing. Useful when the worktree name alone isn't descriptive enough.

It uses CLAUDE_CODE_DISABLE_TERMINAL_TITLE=1 under the hood (which someone mentioned above is already in place) and takes over from there. Might be useful for folks until native support lands: https://github.com/brianruggieri/claude-code-pulse

guplem · 5 months ago

Related issues: #17951, #34223, #32600, #34889

github-actions[bot] · 4 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

douglasg14b · 4 months ago

Love this auto-closing bot.

And by love. I love massive information fragmentation and effectively impossible product support it causes.