v2.1.132 (Cursor): parallel agent panels share one shell, sub-agent calls reset cwd mid-run

Resolved 💬 3 comments Opened May 7, 2026 by vladanmusic-git Closed Jun 5, 2026

Environment

  • Claude Code extension version: 2.1.132 (anthropic.claude-code-2.1.132-darwin-x64)
  • Host: Cursor (running Claude inside Cursor's agent panel, not standalone CLI)
  • OS: macOS Darwin 24.6.0
  • Pattern: 2-3 Claude Code agent panels open in the same Cursor window, each working in a different cwd

Symptom

When I run two or more Claude Code panels in the same Cursor window, a Bash tool call in one panel will sporadically have its current working directory yanked sideways during execution. The visible artifact is a tooltip / overlay that reads:

Shell cwd was reset to /Users/<user>/<some-other-panel's-cwd>

…appearing on a Bash tool call that started with an explicit cd ~/correct/dir && <command>. The command runs but in the other panel's cwd, producing wrong-folder output (e.g., git status returning the other repo).

It also presents as a perceived mid-session "stall": the tool call appears to hang, then the OUT renders with the wrong-cwd warning.

Reproduction

  1. Open Cursor.
  2. Open two Claude Code agent panels in the same window (not separate windows).
  3. Panel A: cd into repo X, start a multi-step task that runs Bash repeatedly with cd /repo-X && cmd chains.
  4. Panel B: cd into repo Y, do the same with cd /repo-Y && cmd chains.
  5. Run them in parallel. Within ~10–30 minutes, one panel will hit the "Shell cwd was reset to <other panel's cwd>" warning during a Bash call.

Each panel emits cd <its-own-dir> && <cmd> explicitly, yet the cwd still gets stomped — suggesting both panels share a single underlying shell pool / persistent process, and Panel A's cd (or the shell handoff at the end of a sub-agent / Task tool call) bleeds into Panel B between or during commands.

What I checked first to rule out user-side causes

To rule out hook overhead, I instrumented all 4 of my user-side Stop / PostToolUse hooks (capture-error.sh, claude-validate-edit.sh, append-session-log.sh, closer-no-shell-cmd-guard.py) with millisecond-level timing. Over a 2-hour window with multiple stalls reproduced, no hook ever exceeded 300ms (max observed: 282ms; mean 10–95ms across 466 fires). I also audited every hook in the active chain plus my recent ~/bin scripts: none change cwd (no cd, pushd, popd); the only git-related hook uses git -C "$REPO" which doesn't mutate cwd. User-side hooks and memory are clean.

Hypothesis

Cursor's Claude Code extension reuses one persistent shell per host window across tool calls. When a sub-agent (Task tool) is dispatched, it borrows that shell, runs commands in its own cwd, and returns control — and the cwd at handoff sometimes leaks into a sibling panel's next Bash call. With 2+ panels in the same window, the shell pool is shared, so a cd from Panel B's sub-agent can land in Panel A's next command.

I'd expect each panel to either:

  1. Have its own dedicated persistent shell, OR
  2. Re-cd to the panel's project root before every Bash tool call, OR
  3. Spawn a fresh subshell per Bash tool call (no persistent state across calls).

Workaround

Open each parallel Claude Code session in a separate Cursor window (Cmd+Shift+N) instead of as a second panel inside the same window. This appears to give each session its own shell pool.

Why this matters

I run 3–5 parallel Claude Code sessions on the same Mac as a normal workflow. Sharing one window across panels was the obvious habit. With shared-shell collisions, every parallel session has to live in its own window, which fragments the desktop and disables some of Cursor's UI patterns (split panes, etc.).

Ask

  • Could each agent panel be given its own persistent shell process / cwd state?
  • Or could the extension re-cd to the panel's project root at the start of every Bash tool call?

Happy to provide more detail / repro recordings if useful.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗