Shell working_directory ignored in multi-repo workspaces

[watson (Thomas Watson)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In a Cursor workspace containing multiple Git repositories, the Shell tool’s working_directory parameter does not reliably re-root the command in the target repository. Commands — especially git — silently keep operating on the first repository listed in the workspace (the “primary” workspace root), even when an absolute path to a sibling repo is passed as working_directory.

This means that when the user asks the agent about a commit / branch / file that only exists in a non-primary repo, the agent gets fatal: bad object <sha>, “branch not found”, etc., and has no obvious feedback that its working_directory was effectively ignored. The agent then spends a lot of tokens hunting for something in a repo that can never contain it. The only reliable workaround is to avoid the working_directory parameter entirely and inline cd /absolute/path && <cmd> instead.

Bonus: the Shell tool’s post-amble cheerfully reports Current directory: /absolute/path/to/sibling-repo even when the spawned process clearly didn’t run there — so the agent has no signal that anything went wrong.

Steps to Reproduce

1. Open a Cursor workspace whose Workspace Paths list contains at least two separate Git repos — e.g. repo-A listed first, repo-B listed second. (At Datadog this is normal: we routinely have dd-source, web-ui, browser-sdk, etc. all in one workspace.)
2. Make sure each repo has commits the other does not.
3. Start a fresh chat. Ask the agent something only repo-B can answer, e.g.:

   In repo-B, what does commit <sha that only exists in repo-B> change?

4. (Optional, to make this even more egregious) Explicitly warn the agent in the prompt that the workspace root is repo-A and that it must navigate to repo-B first.
5. Watch the agent call Shell with working_directory: /abs/path/to/repo-B and a git show <sha> / git log … command.
6. Observe that the output is from repo-A: wrong branch, wrong commits, wrong untracked files, or fatal: bad object. The post-amble still says Current directory: /abs/path/to/repo-B.
7. Have the agent instead run cd /abs/path/to/repo-B && git show <sha> inline (no working_directory parameter) — and observe it now works.

Expected Behavior

When working_directory is set on a Shell call:

• The spawned process’s CWD should actually be that directory, so git (and any other CWD-sensitive tool) operates on the repo at that path.
• If for any reason CWD can’t be set, the tool should fail loudly instead of silently running against the workspace root.
• The post-amble’s Current directory: line should reflect the actual CWD of the executed command (e.g. pwd after the command), not just echo back the requested working_directory.

Operating System

MacOS

Version Information

Version: 3.5.17 (Universal)
VSCode Version: 1.105.1
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
Date: 2026-05-20T02:43:31.559Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

claude-opus-4-7-thinking-xhigh

Additional Information

Observed evidence from a real session

Workspace (anonymized — real session had 7 sibling repos under one parent directory):

Workspace Paths:
  - /Users/<me>/code/repo-A   ← primary
  - /Users/<me>/code/repo-B
  - /Users/<me>/code/repo-C
  - /Users/<me>/code/repo-D
  - /Users/<me>/code/repo-E
  - /Users/<me>/code/repo-F
  - /Users/<me>/code/repo-G

User asked about commit <sha-in-repo-B> in repo-B and pre-warned the agent that the current working directory was misleading.

1. Shell call: git status && git branch --show-current && git log --oneline -10
working_directory: /Users/<me>/code/repo-B
   → Branch reported was the branch checked out in repo-A, not repo-B. Untracked files matched the repo-A git_status block from the system prompt, not repo-B’s.
2. Shell call: git worktree list with the same working_directory.
   → Returned repo-A’s worktrees.
3. Reading /Users/<me>/code/repo-B/.git/HEAD directly confirmed the repo was on a different branch than what the earlier git status reported — i.e. those git calls clearly hadn’t run inside repo-B at all.
4. Shell post-amble said Current directory: /Users/<me>/code/repo-B, but running env later revealed PWD=/Users/<me>/code/repo-A and OLDPWD=/Users/<me>/code/repo-A. So the post-amble’s “Current directory” line is misleading — it appears to echo the requested working_directory, not the actual session CWD.
5. Once the agent switched to cd /Users/<me>/code/repo-B && git show <sha> inline, the command immediately worked and resolved the commit.

So in this session: every git invocation that relied on working_directory ran against the wrong repo; every inline-cd version worked.

Why this matters

Multi-repo Cursor workspaces are common in monorepo-adjacent setups (frontend repo + backend repo + SDK + tooling, all open at once). When the user asks about anything in a non-primary repo, the agent:

• Gets fatal: bad object, branch-not-found, or empty results.
• Has no diagnostic signal that its working_directory was effectively ignored (the tool tells it the CWD is fine).
• Spirals: tries --all, walks worktrees, fetches, even doubts whether the user remembered the SHA correctly.
• Burns a large number of tokens before stumbling onto inline cd as a workaround.

Even when the user explicitly pre-warns the agent (as in this session), the agent still gets tricked because it trusts the Shell tool’s reported Current directory: line.

Suggested fixes

1. Make working_directory actually change the spawned process’s CWD (or fail loudly if it can’t), so child processes — git in particular — see the right repo.
2. Change the Shell post-amble’s Current directory: line to be derived from a real pwd after the command, not from the requested working_directory.
3. Optionally: when a workspace contains multiple git repos, document in the Shell tool description that working_directory is per-call only and that inline cd is the safer pattern for chained git commands.

Does this stop you from using Cursor

No - Cursor works, but with this issue