[BUG] Bash tool starts in $HOME instead of session/project cwd under Termux proot, while Claude Code reports cwd was reset

Description

On Debian 13 (Trixie) ARM64 running inside Android Termux via proot-distro, Claude Code's Bash tool starts commands in $HOME instead of the current session/project working directory.

Claude Code prints:

Shell cwd was reset to /home/user/project

after each Bash call, but the command itself actually runs in:

/home/user

This is not only a noisy message issue. The real execution directory is wrong, so commands may run in the home directory instead of the intended repository.

Expected behavior

Even if Claude Code launches a fresh shell process for each Bash tool call, the working directory should persist at the session level.

If the current session/project cwd is:

/home/user/project

then pwd and other Bash commands should execute from that directory unless explicitly changed.

Actual behavior

Bash commands run in $HOME, while Claude Code reports that cwd was reset to the project directory.

Example output:

$ pwd
/home/user
Shell cwd was reset to /home/user/project

And:

$ env | grep -E '^(HOME|PWD|OLDPWD)='
HOME=/home/user
PWD=/home/user
OLDPWD=/home/user/project
Shell cwd was reset to /home/user/project

This suggests Claude Code's internal session cwd and the actual shell process cwd are diverging.

Why this is serious

This can cause commands to run in the wrong directory, for example:

• git init may initialize $HOME instead of the intended repo
• file creation/deletion may affect the wrong tree
• debugging becomes confusing because the reported cwd and real cwd do not match

Environment

• Claude Code version: 2.1.123
• OS inside runtime: Debian 13 (Trixie) ARM64
• Host/runtime context: Android Termux using proot-distro
• Claude Code shell: non-interactive bash
• User login shell: zsh
• Shell customization: Zinit + Powerlevel10k
• Node management: fnm
• Python management: uv

Reproduction

1. Start Claude Code in a project directory, for example:

   /home/user/project

2. Run:

   pwd

3. Observe output similar to:

   /home/user
   Shell cwd was reset to /home/user/project

4. Run:

   env | grep -E '^(HOME|PWD|OLDPWD)='

5. Observe output similar to:

   HOME=/home/user
   PWD=/home/user
   OLDPWD=/home/user/project
   Shell cwd was reset to /home/user/project

6. Run:

   bash --noprofile --norc -c 'pwd'

7. It still prints:

   /home/user

Diagnostics / what was ruled out

This does not appear to be caused by shell rc files:

• ~/.bashrc exits early for non-interactive shells

• no relevant cd logic was found in the startup files used by this Bash invocation

• inside Claude Code's Bash tool, the same behavior occurs with:

  bash --noprofile --norc -c 'pwd'

This also does not appear to be a generic inability of proot to set cwd for child processes:

• Python subprocesses launched with an explicit cwd=... work correctly
• Node child processes launched with an explicit cwd also work correctly
• outside Claude Code, in the same Termux/proot shell session, plain bash correctly inherits cwd from its caller

That suggests the environment may be a trigger, but the issue is more likely in Claude Code's cwd propagation / Bash launcher behavior under this runtime.

Additional control experiment

In the same Termux + proot environment, outside Claude Code:

cd /home/user/project
bash --noprofile --norc -c 'pwd'

prints:

/home/user/project

By contrast, when the same bash --noprofile --norc -c 'pwd' command is executed via Claude Code's Bash tool, it prints:

/home/user

This shows that plain bash in this environment correctly inherits cwd from its caller. The cwd loss appears specific to Claude Code's Bash tool invocation path rather than to bash, --noprofile --norc, or proot in general.

Claude Code settings checked

• no custom statusLine configuration
• no cwd-related custom hooks affecting Bash execution
• CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR is not set

Relevant configuration excerpts (sanitized)

~/.bashrc

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

. "$HOME/.local/bin/env"
. "$HOME/.cargo/env"
[ ! -f "$HOME/.x-cmd.root/X" ] || . "$HOME/.x-cmd.root/X"
export DISPLAY=unix:/home/user/termux/usr/tmp/.X11-unix/X0
. "$HOME/.deno/env"

~/.profile

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

. "$HOME/.local/bin/env"
. "$HOME/.cargo/env"
. "/home/user/.deno/env"

~/.zshrc (relevant excerpt)

# non-real terminal handling
if [[ -t 0 && -t 1 ]]; then
  _ZSHRC_REAL_TTY=1
else
  POWERLEVEL9K_DISABLE_GITSTATUS=true
fi

export GOROOT="/usr/local/go"
export GOPATH="$HOME/go"

_zshrc_prepend_path "$HOME/.local/bin"
_zshrc_prepend_path "$HOME/.cargo/bin"
_zshrc_source_if_readable "$HOME/.cargo/env"
_zshrc_prepend_path "$HOME/.local/share/fnm"

~/.claude/settings.json (sanitized)

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "<redacted>",
    "ANTHROPIC_BASE_URL": "<redacted>",
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
    "ANTHROPIC_MODEL": "<redacted>",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "<redacted>",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "<redacted>",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "<redacted>",
    "ANTHROPIC_REASONING_MODEL": "<redacted>"
  },
  "permissions": {
    "allow": [
      "Bash(chmod +x:*)"
    ],
    "defaultMode": "auto"
  },
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[timestamp] Session ended\" >> ~/.claude/date-log.txt"
          }
        ]
      }
    ]
  }
}

Related issues

This seems related to the broader cwd tracking/reset issues, but this case is more severe because the shell process itself starts in the wrong directory:

• #1669
• #5441
• #42837

Suggested direction

It would help if Claude Code:

1. guaranteed that each Bash tool invocation starts in the actual session cwd
2. surfaced the real shell cwd more explicitly when it differs from Claude Code's internal cwd
3. added regression coverage for environments like WSL / proot / container-like Linux runtimes

Notes

I am intentionally using sanitized paths and environment details in this report to avoid leaking private local information. If needed, I can provide more reproduction details in a redacted form.