Skip to content

[BUG] Bash tool cd within project root persists across calls by default — breaks statusline, enables silent directory drift #35058

Closed as duplicate

Description

@dkodr

[BUG] Bash tool cd within project root persists across calls by default — breaks statusline, enables silent directory drift

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report
  • I am using the latest version of Claude Code

What's Wrong?

When the Bash tool executes cd to a subdirectory within the project root, the new working directory persists across subsequent Bash tool calls. Only cd outside the project root triggers a CWD reset.

This causes two concrete problems:

  1. Statusline breaks: A statusLine command that relies on pwd (e.g., showing git branch/status) loses context after a subagent or the model itself runs cd to a subdirectory. The statusline then reports incorrect git information or fails entirely.

  2. Silent directory drift: When subagents perform cd to explore other directories (especially via /add-dir), the main session's CWD silently changes. The user has no indication that subsequent commands will run in a different directory. In one real session, a subagent's cd shifted CWD to an entirely different repository (added via /add-dir) for 17 minutes and 114 log entries before it was reset.

What Should Happen?

CWD should reset to the project root after every Bash tool call, regardless of whether cd targeted a path inside or outside the project. This is what CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 does — but it's not the default, and it's completely undocumented.

Steps to Reproduce

Test 1 — cd within project (default behavior, no env var)

  1. Start Claude Code in a project directory (e.g., /home/user/my-project/)
  2. Run Bash: cd src && pwd → outputs /home/user/my-project/src
  3. Run Bash: pwd → outputs /home/user/my-project/src (persisted — wrong)

Test 2 — cd outside project (default behavior, no env var)

  1. Run Bash: cd /tmp && pwd → outputs /tmp
  2. Run Bash: pwd → outputs /home/user/my-project/ (reset — correct)

Test 3 — with CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1

  1. Set CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 in settings.json env
  2. Restart Claude Code
  3. Run Bash: cd src && pwd → outputs /home/user/my-project/src
  4. Run Bash: pwd → outputs /home/user/my-project/ (reset — correct)

Real-world impact (session evidence)

In a real session using a git worktree, the following CWD transitions were observed in the JSONL log:

Time CWD changed to Trigger
13:19 repo-B (different repo, added via /add-dir) Subagent cd
13:19 Back to project root (repo-A worktree) Reset
13:19 repo-B again Another subagent cd
13:19 Back to project root Reset
13:35 repo-B Subagent cd — persisted for 17 minutes
13:52 Back to project root Reset

During the 13:35–13:52 window, 114 JSONL log entries had "cwd" pointing to repo-B instead of the actual project root. Any Bash commands during that period would have executed in the wrong repository. The user had no visual indication of this — the CWD shift was completely silent.

The inconsistency

Scenario Default behavior With env var =1
cd outside project Reset + visible message Reset (silent)
cd within project No reset (persists) Reset (silent)
cd to /add-dir path No reset (persists) ? (not tested)

The env var also suppresses the "Shell cwd was reset" message, making the reset silent in all cases.

Questions for the team

  1. Why isn't CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 the default? The variable has existed since v1.0.18, so the team clearly identified the problem. The current default breaks the statusline and enables silent directory drift.

  2. Why is this variable undocumented? Issue [DOCS] CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR #9359 requested documentation and was closed as "not planned". The variable doesn't appear in the settings docs or any official reference.

  3. Should /add-dir directories be treated as "within project"? The current behavior allows cd to an /add-dir path to persist, which is arguably even more dangerous than within-project persistence since it's a completely different repository.

Proposed fix

Change the default to CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 (always reset CWD to project root). Users who need the old behavior can set =0. Also document the variable.

Error Messages/Logs

No error messages — the issue is silent by nature, which makes it worse.

Claude Model

Opus 4.6

Is this a regression?

No — this has been the behavior since at least v1.0.18 (when the env var was introduced as a workaround)

Claude Code Version

2.1.76

Platform

Anthropic API (Max subscription)

Operating System

Windows 11 Pro (10.0.26200) with Git Bash

Terminal/Shell

Windows Terminal + Git Bash

Additional Information

Related issues:

Activity

  1. github-actions commented on Mar 16, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. Custom statusLine command resets shell CWD between Bash tool calls #31471
    2. [BUG] Bash tool working directory does not persist across calls for TeamCreate sub-agents #35023
    3. [BUG] Bash tool pwd behavior creates unrecoverable confusion for the model #22023

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. added
    duplicateThis issue or pull request already exists
    and removed
    bugSomething isn't working
    has reproHas detailed reproduction steps
    platform:windowsIssue specifically occurs on Windows
    on Mar 20, 2026
  3. github-actions commented on Mar 20, 2026

    @github-actions

    This issue has been automatically closed as a duplicate of #31471.

    If this is incorrect, please re-open this issue or create a new one.

    🤖 Generated with Claude Code

  4. github-actions commented on Mar 27, 2026

    @github-actions

    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.

  5. locked as resolved and limited conversation to collaborators on Mar 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions