[BUG] Change folder is not "visible" to claude code in session
Environment
- Platform (select one):
- [X] Anthropic API
- [ ] AWS Bedrock
- [ ] Google Vertex AI
- [ ] Other:
- Claude CLI version: 1.0.21 (Claude Code)
- Operating System: Ubuntu 22.04
- Terminal: VSCode
Bug Description
Claude Code loses track of the current working directory after executing cd commands, causing subsequent shell commands to fail because they are executed in the wrong directory. The session does not maintain awareness of directory changes between commands.
Steps to Reproduce
- Start Claude Code in a repository root directory
- Execute a command that changes directory, e.g.,
cd docs && ls -l - Ask Claude Code to perform another file operation (e.g.,
grepfor something in the repository) - The subsequent command fails because Claude Code still assumes it's in the repository root, but the shell session is actually in the
docssubdirectory
Expected Behavior
Claude Code should maintain awareness of the current working directory throughout the session, tracking any cd commands and adjusting subsequent command paths accordingly. Alternatively, each command should be executed from a consistent starting directory (repository root).
Actual Behavior
After executing a cd command, Claude Code's internal state doesn't update to reflect the new working directory. Subsequent commands fail with "file not found" or similar errors because they're being executed from the wrong directory. The issue persists until explicitly asking Claude Code to run pwd or cd back to the root directory.
Additional Context
This issue significantly impacts workflow when Claude Code needs to navigate between directories for different tasks. It requires manual intervention to reset the working directory, breaking the natural flow of automated command execution. A potential workaround is to always use absolute paths or chain commands with && to ensure they run in the intended directory, but this shouldn't be necessary.
A idea could be to provide pwd as context on each execution to the LLM and a notice that its NOT in the project root
@dkmaker can you clarify if you are executing these in Bash mode or "normal" mode?
A idea could be to provide pwd as context on each execution to the LLM and a notice that its NOT in the project root
More related context...
You can see in the message logs ~/.claude/projects/..., the cwd is part of the metadata of each message...
{..., "cwd":"/Users/<REDACTED>/cc-x-03","type":"user","message":...}
in fact I just tried this, and I ran "cd" ("normal" mode) and the new message records show the updated directory that I CD'd into.
This partially explains why CC is able to answer questions like "What's the name of the current directory" SOMETIMES without using any tools, which, if you ask "how did you know that?" it said something like "It's part of the provided context", however it is not consistent with what you're observing, which I've also experienced before too, so it's a bit of guess-work.
Well i have seen it a few times - example it does a cd docs && ls -l to fetch the files - dont know why it suddenly does that but then after that it runs a grep command but the arguments is relative to the project root - but the command before changed into a folder
Then it tries like 4-5-6 different appraches before it actually (Probably) realizes it or i have to ask it to check if its in the right folder - just seen it a couple of times - can probably just make a memory that it should never use cd or it should wrap in a popd/pushd clause or always use relative etc.
Did not investigate that it actually sends cwd - then it should probably be optimized somewhere else
@dkmaker can you clarify if you are executing these in Bash mode or "normal" mode?
A idea could be to provide pwd as context on each execution to the LLM and a notice that its NOT in the project root
More related context...
You can see in the message logs
~/.claude/projects/..., thecwdis part of the metadata of each message...{..., "cwd":"/Users/<REDACTED>/cc-x-03","type":"user","message":...}in fact I just tried this, and I ran "cd" ("normal" mode) and the new message records show the updated directory that I CD'd into.
This partially explains why CC is able to answer questions like "What's the name of the current directory" SOMETIMES without using any tools, which, if you ask "how did you know that?" it said something like "It's part of the provided context", however it is not consistent with what you're observing, which I've also experienced before too, so it's a bit of guess-work.
As you can see here - the issue is here - it does not return to the root after it issued the command
@dkmaker I'm not suggesting this is a false bug or anything... we don't know exactly how CC determines, with respect to a specific task or prompt, what directory it's in, and why it gets it wrong sometimes... I was just meaning to share the knowledge that cwd is part of the metadata of every message record in the logs, and it seems like CC is sometimes able to introspect this, and sometimes maybe it doesn't bother to... obviously the mechanisms are obscure because we have no idea how CC is instructed. This is a really big problem IMO.
@dkmaker I'm not suggesting this is a false bug or anything... we don't know exactly how CC determines, with respect to a specific task or prompt, what directory it's in, and why it gets it wrong sometimes... I was just meaning to share the knowledge that
cwdis part of the metadata of every message record in the logs, and it seems like CC is sometimes able to introspect this, and sometimes maybe it doesn't bother to... obviously the mechanisms are obscure because we have no idea how CC is instructed. This is a really big problem IMO.
Would love to see current folder and current model and cost below the prompt box that would be nice to be able to enable
I made a instruction to always uses popd/pushd and denid cd command in bash that solves it
Go into the .claude/projects/your-project folder, sort by last modified, and open the file with tail and you can watch the message stream. I'm just on the API plan maybe it's different if you have a subscription but that's one way to see something I just wouldn't make too many assumptions about it. Just because something is in a log doesn't mean it's in Claude's context. And who knows they could change the design at any time.
Go into the .claude/projects/your-project folder, sort by last modified, and open the file with tail and you can watch the message stream. I'm just on the API plan maybe it's different if you have a subscription but that's one way to see something I just wouldn't make too many assumptions about it. Just because something is in a log doesn't mean it's in Claude's context. And who knows they could change the design at any time.
Also using consumption / api - will check thx for the idea - but for reference the memory works - but should probably be implemented in the system in the build in prompt unless somehow it can be changed and prevented so each bash exit returns automaticly after bash command - but can cause other issues
Should bash commands not just be executed in a sub-shell so that their PWD does not affect the PWD of the CC process?
This issue persists and repeatedly causes Claude to get lost. It doesn't help that the search tool does not acknowledge when it searches in a completely invalid place, so that is likely a quick way to add proper feedback that Claude is in the wrong directory.
This issue persists and repeatedly causes Claude to get lost. It doesn't help that the search tool does not acknowledge when it searches in a completely invalid place, so that is likely a quick way to add proper feedback that Claude is in the wrong directory.
CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR | Return to the original working directory after each Bash command
Set this to 1 in settings then claude code always returns - and somehow it says to bash that all should be relative - that fixed my issue
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.