[BUG] Session working directory diverges from the directory Claude Code was launched from

Status Open
Reported on v2.1.156
Maintainer reply None cached
Activity 4 comments · opened May 29, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Summary:
Claude Code was launched from one project directory, but the agent's session working directory resolved to a different, unrelated project directory. The agent's shell (pwd) and the session's reported "primary working directory" both pointed at the wrong project, causing the agent to attempt work against the wrong repository.

What Should Happen?

CWD should not default to other directory than launch
Directory of current should show in agent list

Error Messages/Logs

Steps to Reproduce

Title: Session working directory diverges from the directory Claude Code was launched from

Summary:
Claude Code was launched from one project directory, but the agent's session working directory resolved to a different, unrelated project directory. The agent's shell (pwd) and the session's reported "primary working directory" both pointed at the wrong project, causing the agent to attempt work against the wrong repository.

Environment:

  • OS: macOS (darwin)
  • Shell: bash
  • Claude Code: <run: claude --version>
  • Two sibling project directories existed on disk:
  • Dir A — where the CLI was actually launched (the intended project)
  • Dir B — an unrelated project; the session's cwd resolved here

Steps to reproduce (observed):

  1. Launch Claude Code from Dir A.
  2. Issue a task that pertains to Dir A.
  3. Observe that the agent's environment reports its primary working directory as Dir B.
  4. pwd and git rev-parse --show-toplevel inside the agent's Bash tool both return Dir B.

Expected:
The session working directory should equal the directory the CLI was launched from (Dir A). pwd and the reported primary working directory should match the launch directory.

Actual:

  • Session "primary working directory" = Dir B (not the launch dir).
  • Agent shell pwd = Dir B.
  • After a cd inside a single Bash command, the shell cwd was reset back to Dir B on the next command (cwd appears pinned to the wrong primary working directory).
  • Result: the agent began operating against the wrong repository — including attempting to clone a project that already existed locally — before the mismatch was caught.

Impact:

  • Agent works in the wrong project context; file searches, git operations, and edits target the wrong repo.
  • Wasted turns, tokens, and effort; risk of changes landing in the wrong repository if not caught.
  • Erodes trust in the displayed/active working directory.

Notes / possible causes to investigate (unconfirmed):

  • Possible restoration of a prior session's working directory (e.g., resume/continue state) overriding the launch directory.
  • Possible influence from project-level config or a nested config directory resolving to a sibling project.
  • Whether the reported "primary working directory" is derived from launch cwd vs. some cached/last-used value.

Workaround used:
Operated on the correct project exclusively via absolute paths (git -C <abs-path> …), ignoring the session cwd entirely.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.156 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] · 3 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/61287
  2. https://github.com/anthropics/claude-code/issues/43029

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

rodlec888 · 3 months ago

I'm hitting the same issue from a different angle. In my case, the trigger is the "remote active by default" setting.

Repro:

  1. Enable remote-by-default in Claude Code settings
  2. Start a session in Project A
  3. Open a separate terminal in Project B, run claude
  4. Instead of a new session, it attaches to Project A's session — wrong CWD, wrong CLAUDE.md, wrong git repo

This makes the remote-by-default setting completely unusable for multi-project workflows. Every new claude invocation gets captured by the first running session regardless of which directory you launched from.

My workaround: Disable remote-by-default entirely; activate remote individually per session.

Same root cause as your report — the session's working directory diverges from the launch directory — but triggered by the remote/attach mechanism rather than session restore. Figured it's worth adding since it confirms the bug from a second entry point.

Environment: macOS 12.7, Claude Code CLI, zsh

Fludem · 2 months ago
I'm hitting the same issue from a different angle. In my case, the trigger is the "remote active by default" setting. Repro: 1. Enable remote-by-default in Claude Code settings 2. Start a session in Project A 3. Open a separate terminal in Project B, run claude 4. Instead of a new session, it attaches to Project A's session — wrong CWD, wrong CLAUDE.md, wrong git repo This makes the remote-by-default setting completely unusable for multi-project workflows. Every new claude invocation gets captured by the first running session regardless of which directory you launched from. My workaround: Disable remote-by-default entirely; activate remote individually per session. Same root cause as your report — the session's working directory diverges from the launch directory — but triggered by the remote/attach mechanism rather than session restore. Figured it's worth adding since it confirms the bug from a second entry point. Environment: macOS 12.7, Claude Code CLI, zsh

This makes sense I started experiencing this bug soon after enabling remote by default

rodlec888 · 1 month ago

Same workaround here: disable remote-by-default entirely; activate remote individually per project-session.