[BUG] Session/project context unclear — project label doesn't reflect the folder actually being worked in
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Description:
When working across multiple projects in a single Claude Code session (or across sessions), it's often unclear which project/repo the current session is actually scoped to. The session header can show a project/repo label that doesn't match the folder Claude is actually reading/writing files in.
Concrete repro:
Start a session in one project (e.g., a repo whose GitHub remote is owner/ProjectA).
Mid-conversation, pivot to working entirely in a different, unrelated local project folder (different repo, different remote, no relation to ProjectA).
Continue working there for an extended period — file edits, builds, deploys, etc. all happening in the new folder.
The session UI continues to display a project/repo tag referencing the original project (ProjectA), not the folder actually being used.
This makes it genuinely hard to trust the session header as a source of truth for "what am I currently working on" — especially when browsing to a new folder or starting a new session, where it's still not obvious at a glance which working directory/project is active.
Why it matters: When juggling multiple real projects, a wrong or stale project label creates real risk of confusion about which codebase changes are landing in, and undermines confidence when reviewing session history later.
Comparison: Google Antigravity handles this more clearly — the active project/working directory is unambiguous at all times, including after switching or starting fresh. Would be good for Claude Code to match that clarity.
What Should Happen?
The session header should always display the project/repo actually being worked in — derived from the current working directory (and its git remote, if any), not fixed to whatever was active when the session started. Specifically:
When Claude's working directory changes mid-session (e.g., the user pivots to a different local folder), the label should update to reflect the new project immediately.
When starting a new session by browsing to a folder, the label should be unambiguous from the very first message — showing the actual folder/repo name, not a stale or inherited value from a previous session.
If a session ever spans multiple unrelated projects, that should be visibly surfaced (e.g., "now working in X, previously Y") rather than silently showing only one fixed label for the whole session.
The bar is: at any point in a session, a glance at the header should correctly answer "which project am I currently in" — the way it does in Google Antigravity today.
Error Messages/Logs
Steps to Reproduce
The session header should always display the project/repo actually being worked in — derived from the current working directory (and its git remote, if any), not fixed to whatever was active when the session started. Specifically:
When Claude's working directory changes mid-session (e.g., the user pivots to a different local folder), the label should update to reflect the new project immediately.
When starting a new session by browsing to a folder, the label should be unambiguous from the very first message — showing the actual folder/repo name, not a stale or inherited value from a previous session.
If a session ever spans multiple unrelated projects, that should be visibly surfaced (e.g., "now working in X, previously Y") rather than silently showing only one fixed label for the whole session.
The bar is: at any point in a session, a glance at the header should correctly answer "which project am I currently in" — the way it does in Google Antigravity today.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude 1.25927.0 (003700) 2026-08-04T05:34:55.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_