Repository navigation
Bash cwd no longer persists between calls (regression, even without CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR) #42837
Description
Description
Running cd /some/path && pwd via the Bash tool no longer persists the working directory between calls. It immediately resets back to the project root with the message:
Shell cwd was reset to /Users/.../project-root
This used to work. I have 51+ instances across past conversation logs where cd successfully persisted the cwd between Bash tool calls in the same session.
Steps to Reproduce
- Open Claude Code in any project directory (e.g.,
~/projects/myapp) - Ask Claude to change directories:
cd ~/ && pwd - Observe the output shows the new directory (
/Users/username) but also shows:Shell cwd was reset to /Users/username/projects/myapp - Subsequent Bash calls are back in the original project root
Expected Behavior
Per the official docs (Bash tool behavior):
"Working directory persists across commands. Set
CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1to reset to the project directory after each command."
The cwd should persist. The env var CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR is the opt-in to reset — implying the default is persistence. The env var is not set in my environment.
Environment
- OS: macOS (Darwin 25.3.0)
- Claude Code: Latest version
- Shell: zsh
CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR: Not set- Custom
statusLine: Yes (configured insettings.json)
Relationship to #31471
Issue #31471 documents that a custom statusLine command can reset shell cwd between Bash calls. However, in my case:
- This is a regression — the same
statusLineconfig was present in prior sessions wherecdpersistence worked correctly - Something changed in a recent Claude Code update that broke this behavior
- The
statusLinecommand usescdonly inside a$(...)subshell (to get the git branch), which should not affect the parent shell's cwd
Impact
This prevents users from changing their working context mid-session, which is a core workflow — e.g., switching between project directories, navigating to home directory, etc. The only workaround is prefixing every single Bash command with cd /desired/path &&.
Activity
github-actions commentedon Apr 2, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
navarro165 commentedon Apr 2, 2026
Correction / Clarification
I want to reframe this issue more precisely. This isn't just about Bash
cdpersistence — it's about Claude Code's ability to change its session working directory mid-conversation.How it used to work:
When a user tells Claude "change dir to ~/" (or any path), Claude runs
cd ~/ && pwdvia the Bash tool, and the Claude Code harness detects the new cwd and updates the session's working directory for ALL tools — Read, Glob, Grep, Edit, Bash, etc. All subsequent operations resolve paths from the new directory.This is confirmed by 51+ instances across my past conversation logs where this worked correctly with the same configuration I have now.
What happens now:
Claude runs
cd ~/ && pwd, output shows the new path, but immediately the harness resets it:Shell cwd was reset to /original/project/root. All tools continue operating from the original directory.Key point:
This is a regression in a core workflow — the ability to tell Claude Code "switch to a different directory" and have the entire session context move there. The same
statusLineconfig and environment were present when this worked before.navarro165 commentedon Apr 2, 2026
Closing to refile with corrected description.
navarro165 commentedon Apr 2, 2026
Superseded by #42844 which has a corrected description. Please disregard this issue.
[260416-150656-worktree-close-cd-main-race] parallel multi-worktree r…
maod65104-hash commentedon Apr 27, 2026
Proposed follow-up cleanup item: #53849 (“Reduce Shell cwd reset message noise”). It captures the shell cwd reset message clutter issue and should be prioritized ahead of other follow-ups when sub-issues are available.
github-actions commentedon May 29, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Jul 30, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.