claude-code icon indicating copy to clipboard operation
claude-code copied to clipboard

[BUG] Change folder is not "visible" to claude code in session

Open dkmaker opened this issue 6 months ago • 9 comments

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

  1. Start Claude Code in a repository root directory
  2. Execute a command that changes directory, e.g., cd docs && ls -l
  3. Ask Claude Code to perform another file operation (e.g., grep for something in the repository)
  4. The subsequent command fails because Claude Code still assumes it's in the repository root, but the shell session is actually in the docs subdirectory

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.

dkmaker avatar Jun 12 '25 12:06 dkmaker

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 avatar Jun 12 '25 12:06 dkmaker

@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.

hesreallyhim avatar Jun 12 '25 19:06 hesreallyhim

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 avatar Jun 12 '25 22:06 dkmaker

@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.

As you can see here - the issue is here - it does not return to the root after it issued the command

Image

dkmaker avatar Jun 13 '25 14:06 dkmaker

@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.

hesreallyhim avatar Jun 13 '25 14:06 hesreallyhim

@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.

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

dkmaker avatar Jun 13 '25 19:06 dkmaker

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.

hesreallyhim avatar Jun 13 '25 19:06 hesreallyhim

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

dkmaker avatar Jun 13 '25 20:06 dkmaker

Should bash commands not just be executed in a sub-shell so that their PWD does not affect the PWD of the CC process?

jimsynz avatar Jun 13 '25 20:06 jimsynz

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.

bbqsrc avatar Sep 08 '25 07:09 bbqsrc

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

dkmaker avatar Sep 08 '25 08:09 dkmaker

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.

github-actions[bot] avatar Dec 05 '25 10:12 github-actions[bot]