Shell tool working_directory parameter silently ignored in multi-root workspaces — commands run in first workspace root instead

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Shell tool’s working_directory parameter is silently ignored in multi-root workspaces. Commands run in the first workspace root instead of the path passed in, with no error returned. The tool’s output footer even claims the cwd is the path I specified, but a follow-up pwd in a later Shell call reveals the cwd was actually the first workspace root — and files get written to the wrong repo.

Two older forum threads describe the same symptom class:

Neither fix covers the multi-root + explicit working_directory case on Cursor 3.1.17.

Steps to Reproduce

  1. Open a single Cursor window with a multi-root workspace containing two git repos, e.g.:

    • /Users//projects/repo-a (listed first)
    • /Users//projects/repo-b

  2. Ask the agent to create a directory tree inside repo-b, e.g.
    “create subdir-1/{foo,bar}/.gitkeep in repo-b”.

  3. The agent calls the Shell tool with:
    command: “mkdir -p subdir-1/{foo,bar} && touch subdir-1/{foo,bar}/.gitkeep && ls -la subdir-1/”
    working_directory: “/Users//projects/repo-b”

  4. Shell output footer reads:
    Current directory: /Users//projects/repo-b
    and the ls -la subdir-1/ at the end appears to succeed.

  5. In a later Shell call, run pwd and ls /Users/<me>/projects/repo-b/subdir-1.

    • pwd returns /Users//projects/repo-a (the FIRST workspace root).
    • ls on repo-b returns “No such file or directory”.
    • ls /Users/<me>/projects/repo-a/subdir-1 shows the tree — the writes landed in the wrong repo.

Expected Behavior

When working_directory is passed to the Shell tool, the command must execute with that cwd. If the parameter cannot be honored, the tool should return an error and NOT execute — rather than silently running in the first workspace root while still reporting "Current directory: " in the output footer.

The misleading footer is the worst part: it actively tells the agent the command ran where it was asked to, so the agent has no way to detect the mis-routing without an extra verification step.

Operating System

MacOS

Version Information

Cursor version: 3.1.17 (commit fce1e9ab7844f9ea35793da01e634aa7e50bce90, arm64)
OS: macOS 25.4.0 (darwin)
Workspace: multi-root (20 folders added to one window)

For AI issues: which model did you use?

Claude (Sonnet/Opus tier) via built-in Cursor agent mode

Additional Information

Impact: destructive and silent. Writes land in the wrong repo with no indication. For engineers working across multi-root workspaces (common pattern — I had 20 repos open in one window), this is a silent correctness bug with a wide blast radius (misplaced commits, stray files under the wrong .git, accidental secrets-leakage scenarios).

Current workaround I’m using:

  • Ignore working_directory entirely and prefix every command with cd /abs/path && … in a single command string, OR
  • Use absolute paths in every mkdir/touch/cp/etc., OR
  • Open every Shell call with pwd as a sanity probe.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi @reiz_fizz
This is a confirmed bug – thanks for the detailed write-up with reproduction steps. You’re right that the working_directory parameter is being silently overridden, and the misleading footer makes it especially frustrating since the agent has no way to detect the mis-routing.

We’ve been investigating this with other users who reported the same issue, and we’ve identified the root cause. A fix is being tracked and worked on by our desktop team.

In the meantime, your workarounds are exactly right – the most reliable approach is to prefix commands with cd /absolute/path && ... or use absolute paths throughout. I know that’s inconvenient, especially with 20 folders in one window.

You may also find this related thread helpful, where several other users are tracking the same issue: Shell tool does not reliably honor working_directory

I’ll follow up here once a fix ships.