[FEATURE] Desktop: derive the session project label from the folder name (or make it configurable) — multiple clones of one repo are indistinguishable in the tag and in Group by → Folder
Problem
In the Desktop app, every session shows a project tag/chip next to its title. The tag appears to be derived from the git repo name, not the working directory.
I work with several clones of the same repo side by side (~/Repositories/mobile1, mobile2, mobile3 — all pointing at the same remote) so parallel AI sessions don't collide. All of their sessions show the same tag ("mobile"), so I can't tell from the session list which clone a session is modifying.
Update (2026-08-12): the same label defeats the new "Group by" feature
The sidebar now has Group by (Date / Folder / State / Custom groups). "Folder" groups by this same repo-derived label, so sessions from all three clones collapse into a single "mobile" group — grouping by folder can't distinguish the folders.
Custom groups don't cover it either: sessions can only be moved into a group manually in the UI. There is no hook, setting, or session-management tool to auto-assign a new session to a group, so with many new sessions a day the groups are stale the moment they're created.
So both surfaces that could distinguish parallel clones — the project chip and Group by → Folder — collapse on the repo name.
Request
Either:
- derive the label from the directory basename (
mobile1/mobile2/mobile3) — or prefer it when it differs from the repo name, or - allow a per-directory display name (e.g. a
displayNamein.claude/settings.local.jsonor a Desktop UI affordance).
Per the comment below, the folder-basename label already exists in the code as extractProjectName(cwd) — it just never wins when a git remote exists. The per-directory displayName is the strongest option since it also covers workspaces whose basename isn't meaningful, and one fix covers both the chip and the grouping.
Who this affects
Anyone running parallel AI sessions against multiple checkouts of one repo — which the agent-workflow era makes common: numbered clones, monorepo workspaces (see the comment below: 8+ checkouts, one core chip), or long-lived per-branch checkouts. The more parallel sessions a user runs, the more they need the session list to answer "which working copy is this session touching?" — and that's exactly the population Desktop's multi-session UI targets.
Workarounds tried
- The AI-generated session title can't be shaped from CLAUDE.md — it's produced by a separate summarization step.
- The session-management tool available to the model (
set_session_title) can rename other sessions but not the current one, so a session can't prefix its own title with the clone name at start. A skill that sweeps and prefixes other sessions' titles works, but it's manual and always one step behind. - Custom groups + manual dragging: no way to automate assignment (verified: no hook/API, and the assignments aren't in any scriptable file on disk).
Letting a session set its own title (or honoring a per-directory display name) would also solve this.
🤖 Filed with Claude Code
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Hitting this too, with a variant that makes it worse: a monorepo checked out into many numbered workspaces.
I keep 8+ parallel checkouts (
E:\Code1…E:\Code11), each on a different feature branch, all pointing at the sameorigin(…/core.git). Every session in every workspace shows the same chip:core. The session list gives me no way to tell which branch/workspace a session belongs to — and unlike separate repos, there is nothing else in the tree that differs to fall back on.Confirming the mechanism from the Desktop bundle (
app-1.25927.0/resources/app.asar): the label comes fromgetGitRepoName(cwd)→gitStatus.getGitInfo(cwd)?.repo, and only falls back toextractProjectName(cwd)(the last path segment) when there is no git repo. So the folder name is already computed as a fallback — it just never wins when a remote exists. I grepped the bundle for any toggle (showWorkingDirectory,repoChip,showRepoName, …) and found none.Two things that would each fix it, in preference order:
displayNamein.claude/settings.local.json. This is the strongest option because it also covers the case where the folder basename isn't meaningful either; I could label mine by the ticket the workspace is working (Code9 · SPRY-8839).extractProjectNamefallback selectable.Code9is already more informative thancorefor me.Adding the branch to the chip (or as a second chip) would also go a long way on its own, since the whole reason for N checkouts is N concurrent branches.
Related: #81063, #80187.
Updated the issue body: the new sidebar Group by → Folder feature uses the same repo-derived label, so all my clones still collapse into one "mobile" group — and Custom groups can't close the gap because assignment is drag-only (no hook, setting, or API to auto-assign new sessions, and the assignments aren't in any scriptable file on disk).
So a single fix — per-directory
displayName, or basename-wins-when-it-differs — now covers both the project chip and session grouping.@ndls21 thanks for digging out the mechanism in the bundle; agree that
displayNamein.claude/settings.local.jsonis the strongest option, since it also covers checkouts whose basename isn't meaningful on its own.Ideally, you should also be able to tell the AI to place a session in a specific folder based on its context. In short: _Auto-grouping_