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

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/..., 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 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 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

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.

Yes still occurring, here's what happened to me (this is a common painpoint, this is just an example):

⏺ Now let me regenerate the Gradle lock file with the new Spring Boot 4.0 dependencies.

⏺ Bash(cd backend && rm gradle.lockfile && ./gradlew dependencies --write-locks) timeout: 3m 0s
  ⎿  Starting a Gradle Daemon (subsequent builds will be faster)

     > Task :dependencies
     … +452 lines (ctrl+o to expand)

⏺ Excellent! The lock file has been regenerated successfully. I can see that:
  - Spring Boot 4.0.0 is active
  - Spring Framework 7.0.1 is being used
  - Jackson 2 compatibility is working (using com.fasterxml.jackson 2.20.1)
  - Exposed 0.61.0 is unchanged

  Now let's attempt to build the project.
⏺ Bash(cd backend && ./gradlew clean build --console=plain 2>&1 | head -300) timeout: 5m 0s
  ⎿  Error: Exit code 1
     (eval):cd:1: no such file or directory: backend

⏺ Bash(pwd && ls -la | head -20)
  ⎿  /Users/cr/code/loculus/backend
     total 208
     drwxr-xr-x@ 29 cr  staff    928 Dec 17 12:58 .
     … +18 lines (ctrl+o to expand)

⏺ I'm already in the backend directory. Let me run the build.

⏺ Bash(./gradlew clean build --console=plain 2>&1 | head -300) timeout: 5m 0s
  ⎿  Running…
     ctrl+b to run in background

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

Does this help a bit https://github.com/anthropics/claude-code/issues/1669#issuecomment-3671800762?

This issue was closed incorrectly despite recent human comments. This behavior of the bot is reported at https://github.com/anthropics/claude-code/issues/16497. Please upvote that issue, so maybe it gets noticed.

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.