[BUG] Claude Code frequently loses track of which directory it is in

I have seen this issue as well. My folder structure is /Users/username/workspace/project-name claude code will often try to run code in workspace folder. I even moved to /Users/username/project-name outside of workspace folder but it seem to remember that folder and keeps navigating back to it.

I can't stress enough how significant this issue is. It's in the top 3 time wasters along with forgetting to source a venv and not sufficiently testing code before marking a todo complete.

Right, it wastes both user time, but also user tokens (we're paying for this).

This happens all the time. Every time it tries to invoke make or run a test or git add files. It tries commands in the wrong directory, then tries to cd to directories it's already in, then tries to change to an absolute path that may or may not be correct. Maybe it should cd back to the directory it was started in?

This looked like an infinite loop. It just kept going until I stopped it:

⏺ Bash(cd ...)
  ⎿  Error: (eval):cd:1: no such file or directory: ...

⏺ Bash(cd ...)
  ⎿  Error: (eval):cd:1: no such file or directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(...)
  ⎿  Read 40 lines (ctrl+r to expand)

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../..)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...

⏺ Read(../../../../../../...)
  ⎿  Error: File does not exist. Current working directory: ...
  ⎿  Interrupted by user

All of these were trying to access the same file from the same directory. The file appeared to be in the current working directory, judging by the one command that succeeded.

One possibly relevant detail: Our codebase is primarily Go, but we also have Typescript -- it's a small monorepo. The Go code is split at the top level into public/ and internal/, each of which has its own go.mod. Typescript is in ui/src primarily. I start claude code in the top-level directory of the git repo.

How about providing a guideline like this in Claude's markdown file, or a generic markdown file that you ask claude to read before starting any session. This worked for me till some extent, until it loses context after compacting. I just had to ask it to go through the markdown again. Just a workaround, till the time it is actually fixed by the devs.

Directory Navigation Guidelines:

• Project Root: /Users/abc/Github/Project/ - Contains client/, server/, sdk/, docs/, etc.
• Working Directory: /Users/abc/Github/Project/client/ - This is where you'll usually be working
• Key Directories:
• Documentation: /Users/abc/Github/Project/docs/ (NOT in client/docs/)
• Frontend Code: /Users/abc/Github/Project/client/ (apps/, libs/, etc.)
• Server Code: /Users/abc/Github/Project/server/
• When files are not found: Always check if they exist at the project root level (../filename) before assuming they don't exist
• Use absolute paths: When in doubt, use full absolute paths starting from /Users/abc/Github/Project/

This is currently the most severe and debilitating issue I've experienced with claude-code. In one of my recent sessions, it mistook the directory it was in and removed all files in the project directory (it was trying to clean the build subdirectory). Thankfully, there were no changes since the last Git commit, so nothing was lost, but it's extremely frustrating that this keeps happening. How hard is it to keep Claude's cwd in memory and/or checking before running commands?

Why does Claude not prepend to every prompt, "You are currently in this directory:..."?

I have the current directory in my status line and check it often because of this very problem.

#!/bin/bash
# Read JSON input from stdin
input=$(cat)

# Extract values using jq
MODEL_DISPLAY=$(echo "$input" | jq -r '.model.display_name')
CURRENT_DIR=$(echo "$input" | jq -r '.workspace.current_dir')

# Show git branch if in a git repo
GIT_BRANCH=""
if git rev-parse --git-dir > /dev/null 2>&1; then
    BRANCH=$(git branch --show-current 2>/dev/null)
    if [ -n "$BRANCH" ]; then
        GIT_BRANCH=" |  $BRANCH"
    fi
fi

echo "[$MODEL_DISPLAY] ${CURRENT_DIR}$GIT_BRANCH"

I completely solved the problem with these hooks:

https://github.com/lpasqualis/lpclaude/tree/master/hooks

I completely solved the problem with these hooks: https://github.com/lpasqualis/lpclaude/tree/master/hooks

Thanks. Should I use both hooks, or is guard-cd.sh enough to solve this problem?

> I completely solved the problem with these hooks: > > https://github.com/lpasqualis/lpclaude/tree/master/hooks Thanks. Should I use both hooks, or is guard-cd.sh enough to solve this problem?

Guard-cd is all you really need

> > I completely solved the problem with these hooks: > > https://github.com/lpasqualis/lpclaude/tree/master/hooks > > > Thanks. Should I use both hooks, or is guard-cd.sh enough to solve this problem? Guard-cd is all you really need

I ended up installing lpclaude in its entirety. Pretty cool, thanks a lot!

Duplicate https://github.com/anthropics/claude-code/issues/2001 has this comment:

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

My problem was fixed by removing the line
cd $HOME
from my ~/.profile.
It seems that if you cd in your ~/.profile , ~/.bashrc or related scripts, Claude gets lost.

@leonbloy That's on you, but this problem is generally unrelated to that. Claude genuinely forgets what it did a few seconds ago.

I don't understand why the cwd isn't just part of the latest user prompt. I run into this issue pretty constantly

Claude is constantly doing stuff like this to me, it really should be addressed - it adds a lot of delay to processing as it spins around 3 times to figure out where it is in the directory structure constantly:

Now let me test that one of the scripts works from its new location:
● Bash(cd scripts && bash -n quick_test.sh && echo "Script syntax check passed")
⎿ Script syntax check passed
● Let me verify the path resolution works:
● Bash(cd scripts && dirname "$PWD/quick_test.sh" && echo "../build from scripts goes to: $(cd ../build && pwd)")
⎿ Error: /bin/bash: line 1: cd: scripts: No such file or directory
● Bash(ls -la scripts/)
⎿ Error: ls: cannot access 'scripts/': No such file or directory
● Let me check where the files actually are:
● Bash(find . -name "quick_test.sh" -o -name "run_game.sh" -o -name "run_vortex.sh" 2>/dev/null)
⎿ ./quick_test.sh
./run_game.sh
./run_vortex.sh
● It seems the git mv command moved them to the current directory instead of scripts/. Let me fix this:
● Bash(mkdir -p scripts && git mv quick_test.sh scripts/ && git mv run_game.sh scripts/ && git mv run_vortex.sh scripts/)
⎿ (No content)
⎿ Interrupted · What should Claude do instead?
> Check if you are in the scripts directory
● You're right! Let me check my current working directory:
● Bash(pwd)
⎿ /home/viblio/coding_projects/mm_claude/scripts
● Ah yes, I'm in the scripts directory! That explains why the earlier git mv commands moved the files here. Let me verify the
scripts are now in the right place: (edited)

This is one of the top issues with Claude; it severely degrades user experience, wastes time and money

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.

My subjective experience is that this has improved somewhat, but it is still a problem.

Still a problem for me - see #14326

I enabled CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR and so far had 0 issues of Claude being confused by the directory not changing - so maybe that should just be the default? Perhaps with an explicit /cd and/or Chdir tool for when changing the directory is intentional?

@ANogin Even with CLAUDE-BASH-MAINTAIN_PROJECT_WORKING_DIR I frequently see Claude getting confused when the project has a structure with nested directories. It will frequently cd into the data directory and then be surprised that things that existed in the parent directory are not there (with many variations which would be hilarious if this wasn't also a matter of professionality, cost, and patience).

This is still a problem Jan 28 2026!

claude frequently changes current dir and then it forgets where it is! I can see this because I see it trying to read files with a relative path and it fails to read them, then moments later it reads successfully with the correct path, or it has changed dir again.

This business of changing dirs and forgetting what is cwd is very frustrating. I am sure that it costs us tokens.

Why change dirs at all? Why not stay in the same dir for the whole session and always use correct paths?

@1MikeMakuch well we need it to have the ability to change dirs if you have a monorepo with modules that have their own .env or any other direnv-type stuff. The cwd should just be always part of the message imo. Maybe that's currently how it works and Claude just isn't used to it

@1MikeMakuch well we need it to have the ability to change dirs if you have a monorepo with modules that have their own .env or any other direnv-type stuff. The cwd should just be always part of the message imo. Maybe that's currently how it works and Claude just isn't used to it

1MikeMakuch's concern is still valid. The issue persists and keeps burning up tokens for nothing.

Handling directories without getting confused about it really feels like it should be a throughly solved problem in 2026. How hard is it for Claude Code to not confuse itself about what the current directory is? Why are we needing to work around this at all? Why does this bug persist after so many bug reports?

It's not just about burning tokens on wasted work. Sometimes the task is "create this new subdirectory and create the following files in that directory", and a command like that can create the new directory almost anywhere.

All that would be needed is to prefix every new prompt with "Your cwd is: ..."

> @1MikeMakuch well we need it to have the ability to change dirs if you have a monorepo with modules that have their own .env or any other direnv-type stuff. The cwd should just be always part of the message imo. Maybe that's currently how it works and Claude just isn't used to it 1MikeMakuch's concern is still valid. The issue persists and keeps burning up tokens for nothing. Handling directories without getting confused about it really feels like it should be a throughly solved problem in 2026. How hard is it for Claude Code to not confuse itself about what the current directory is? Why are we needing to work around this at all? Why does this bug persist after so many bug reports?

Well I don't know your code of course, and BTW claude is working great overall but there are some issues this being one ugly one...

Just wanted to add:

• It would certainly be possible to perform all file I/O without ever changing dirs right? Just always use absolute paths.

• Also I sometimes see claude executing bash commands in the following form:

Bash(cd /home/myuser/src/myapp && git status --short)

which is great because it works and it communicates clearly to the user. You could always do that and never have to chdir. I'd prefer it to always stay in the dir where it was started, then when I give it a relative path to the start dir it always makes sense.

In any case, currently it's not fully working, it's buggy. I have to interrupt it too often and remind it where things are or get it to figure out what dir it's currently in. That seems broken to me.

Thanks
Mike

Let me just resurface these earlier comments with workarounds:

• https://github.com/anthropics/claude-code/issues/1669#issuecomment-3272548126 links to a third-party hook which restricts cd
• https://github.com/anthropics/claude-code/issues/1669#issuecomment-3280175253 links to a comment about CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 which I have used to partially remedy this problem

Still happening:

$ claude --version
2.1.37 (Claude Code)

Related: #24021, #22945.

I just discovered the /statusline command will let you have the cwd displayed in the claude status line so at least we can see what the current dir is.

I also discovered you can actually "cd dir1" and it works, although it takes a lot longer than we'd like.

in windows,
claude regularly asks for permission to CD back into it's own project directory. usually combined with another command with an &&.

maybe related- the permission prompt incorrectly believes it's trying to CD into the drive root. maybe becuase of the windows paths being \ instead of / like on unix.

Not a real solution, but so far this in base CLAUDE.md seems to help it keep better track:

# Shell

- Use pushd and popd to navigate so you don't get lost.

This continues to be a problem. Every day, many times a day I see claude performing actions and fail because it's in the wrong dir.

It's shocking that this has been reported for over 8 months and not being addressed.

@bcherny can you please take a look at this

This is making claudecode completely unusable. It forgets cwd every command, for every project, every day. Over and over I instruct it to check cwd before running a command. It refuses to do this no matter what. Just keeps trying to run a build script in my Projects parent folder. It seems like command chaining was disabled, so I can't even workaround with cd /PROJ/DIR && pnpm build.

⏺ Bash(pnpm run build)
  ⎿  Error: ERR_PNPM_NO_SCRIPT  Missing script: build

     Command "build" not found.

⏺ Bash(pnpm run build)
  ⎿  Error: ERR_PNPM_NO_SCRIPT  Missing script: build

     Command "build" not found.

⏺ Bash(pnpm run build)
  ⎿  Error: ERR_PNPM_NO_SCRIPT  Missing script: build

     Command "build" not found.

It just keeps doing the same thing until I stop it.

Since this issue is not blowing up, then it is likely I'm the one doing something wrong. Any advice please, this is destroying my output.

This is making claudecode completely unusable. It forgets cwd every command, for every project, every day. Over and over I instruct it to check cwd before running a command. It refuses to do this no matter what. Just keeps trying to run a build script in my Projects parent folder. It seems like command chaining was disabled, so I can't even workaround with cd /PROJ/DIR && pnpm build.

Yes, it is very annoying.

It just keeps doing the same thing until I stop it. Since this issue is not blowing up, then it is likely I'm the one doing something wrong. Any advice please, this is destroying my output.

https://github.com/anthropics/claude-code/issues/1669#issuecomment-3671800762 suggests to set the CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR variable to 0. This seems to help some folks. See https://code.claude.com/docs/en/settings#environment-variables for docs on how to set environment variables in Claude.

You can add a CLAUDE.md rule to force directory awareness, and a PostToolUse hook to remind Claude of its current directory after every Bash command:

1. Add to your project's CLAUDE.md:

## Working Directory Rules
- Before any file operation, confirm you are in the correct directory with `pwd`
- NEVER use `git reset --hard` or `git clean -fd` without explicit user confirmation
- Use absolute paths for critical operations

2. PostToolUse hook to show current directory after Bash commands:

#!/bin/bash
# ~/.claude/hooks/cwd-reminder.sh
# PostToolUse — shows current working directory after Bash commands

INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty')

[ "$TOOL_NAME" != "Bash" ] && exit 0

# Show current working directory as feedback
echo "📂 Working directory: $(pwd)" >&2
exit 0

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "bash ~/.claude/hooks/cwd-reminder.sh" }
        ]
      }
    ]
  }
}

3. PreToolUse hook to block dangerous git commands entirely:

#!/bin/bash
# ~/.claude/hooks/git-safety.sh
INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty')
[ "$TOOL_NAME" != "Bash" ] && exit 0

COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Block destructive git operations
case "$COMMAND" in
  *"git reset --hard"*|*"git clean -fd"*|*"git clean -f"*|*"git checkout -- ."*|*"git push --force"*)
    echo "BLOCKED: Destructive git operation detected. Use a safer alternative or get explicit user confirmation first." >&2
    exit 2
    ;;
esac

exit 0

This prevents the exact scenario that caused your 60-hour loss. Exit code 2 = hard block that Claude cannot override.

For me it's mostly causing annoying permission prompts when it combines cd with other commands using && and then I'd have to tell it to run them separately. Ended up having Claude create a hook that automates this.
Requires Bun but you can ask Claude to rewrite it in another language:

#!/usr/bin/env bun
// PermissionRequest hook:
// Block "cd dir && ..." / "cd dir ; ..." — forces cd separately.

const data = await Bun.stdin.json();
const command = data.tool_input?.command || '';

if (/^\s*cd\s+[^;&]+\s*(&&|;)/.test(command)) {
  const result = {
    hookSpecificOutput: {
      hookEventName: 'PermissionRequest',
      decision: {
        behavior: 'deny',
        message: "Don't combine cd with other commands. Run cd separately first, then run the remaining command(s).",
      }
    }
  };

  console.log(JSON.stringify(result));
}

configured under hooks like this:

    "PermissionRequest": [
	  {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bun path/to/above/script.ts"
          }
        ]
      }
    ]

+1 on this.

Workarounds I've used that has helped in the meantime:

• A PreToolUse hook that blocks cd commands, forcing the use of absolute instead of relative paths
• Rewrote all agent definitions to reference root-level Makefile targets instead of subdirectory commands
• Added explicit "never use cd" instructions to CLAUDE.md and auto-memory

I still encounter the issue since agents don't always follow instructions, but for the most part the hook has sped up the time it takes for Claude to "fix" the command it's trying to exectute.

Some ideas for improvement:

1. Each Bash tool invocation should start from the project root, not the CWD left by the previous call. The current persistence serves no purpose that cd /path && command chains don't already handle.
2. A first-class setting like "bashResetCwd": true or "bashBlockCd": true that doesn't require a custom hook.
3. When defining agents in .claude/agents/, allow specifying a workingDirectory so the agent's Bash calls always execute from a defined location:

---
name: backend-engineer
workingDirectory: server/
---

1. Claude's default behavior should prefer absolute paths and tool-specific flags (--package-path, --cwd, -C) over cd.

/tmp/gh-comment-1669.md

Until this is fixed upstream, you can use a hooks guard that checks the working directory before any destructive Bash command runs.
Add to .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/cwd-guard.sh"
          }
        ]
      }
    ]
  }
}

Create ~/.claude/hooks/cwd-guard.sh:

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
echo "$COMMAND" | grep -qE '(git (reset|clean|checkout \.)|rm -rf|rm -r )' || exit 0
CWD=$(pwd)
PROJECT_ROOTS=(
  "$HOME/workspace"
  "$HOME/projects"
)
in_project=false
for root in "${PROJECT_ROOTS[@]}"; do
  if [[ "$CWD" == "$root"* ]]; then
    in_project=true
    break
  fi
done
if [ "$in_project" = false ]; then
  echo "BLOCK: Destructive command outside project roots (CWD: $CWD)"
  echo "Command: $COMMAND"
  echo "Expected roots: ${PROJECT_ROOTS[*]}"
  exit 2  # exit 2 = block the tool call
fi
if echo "$COMMAND" | grep -qE '^git ' && [ ! -d "$CWD/.git" ] && [ ! -f "$CWD/.git" ]; then
  echo "BLOCK: git command but no .git found in $CWD"
  exit 2
fi
exit 0

How it works:

• Hooks run before Claude executes the tool, so the command is blocked before any damage
• exit 2 blocks the command and shows the message to Claude — it won't retry blindly
• exit 0 = allow, exit 1 = error (also blocks), exit 2 = explicit deny
• Only triggers on destructive patterns (git reset, git clean, rm -rf, etc.), so normal commands run without overhead
• The PROJECT_ROOTS array lets you whitelist your workspace directories — customize to match your setup

This would have prevented the git hard reset in wrong directory scenario from #1668. The hook catches it before execution, not after.

This is a longstanding issue — Claude's CWD tracking can drift during complex multi-directory operations. A PreToolUse hook can add a safety layer:

1. CWD drift detector — warn on destructive commands outside project root:

Save as ~/.claude/hooks/cwd-drift-detector.sh:

#!/bin/bash
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0

# Only check destructive commands
if ! echo "$COMMAND" | grep -qE '(git\s+(reset|clean|checkout\s+--|push\s+--force)|rm\s+-rf)'; then
  exit 0
fi

# Check if we're in a project root
CWD=$(pwd)
IS_PROJECT=false
for marker in .git package.json Cargo.toml go.mod pyproject.toml Makefile; do
  [ -e "$CWD/$marker" ] && IS_PROJECT=true && break
done

if [ "$IS_PROJECT" = false ]; then
  echo "WARNING: Destructive command outside project root." >&2
  echo "  CWD: $CWD" >&2
  echo "  Command: $(echo "$COMMAND" | head -c 100)" >&2
fi
exit 0

Then in settings:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/cwd-drift-detector.sh" }]
      }
    ]
  }
}

2. PostToolUse CWD logger — audit trail for debugging:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "echo \"$(date +%H:%M:%S) CWD: $(pwd)\" >> /tmp/claude-cwd.log" }]
      }
    ]
  }
}

Neither fully solves the drift issue (that requires a Claude Code core fix), but the combination catches the most dangerous cases — destructive commands in the wrong directory.

Just chiming in to say we are also experiencing this issue.

Hooks are a nice guard against tool use, but they don't prevent Claude from wasting tons of tokens traversing other, unrelated directories when searching or planning.

Something as simple as Add a prefix to all the skills in this repo becomes a much longer and more expensive process.

@ThariqS You are looking for bugs to fix... please start with this one, it is a very serious problem and this is a very old bug report with tons of confirmations that this is an issue.