Agent Shell working_directory ignored; footer reports requested cwd (workspace is a git subdirectory)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Agent Shell tool’s working_directory argument does not change the spawned process cwd when the Cursor workspace is a subdirectory of a larger git repo. The tool footer still prints Current directory: , so the agent treats the command as if it ran at the git root.

This is a single-folder workspace (not multi-root).

  • Workspace: /path/to/git-root/nested/workspace
  • Git toplevel: /path/to/git-root

When the agent passes working_directory: /path/to/git-root and then uses repo-relative git paths (nested/workspace/…), git resolves them again from the workspace cwd:

warning: could not open directory 'nested/workspace/nested/workspace/': No such file or directory

Same family as forum topic 157608 – staff confirmed that was platform-side in April 2026 (working_directory received, not applied). Still present on 3.16.17. Our shape is different: cwd stays at the workspace, and working_directory pointing up to the parent git root is ignored.

Client is Windows (Remote-SSH). The Shell process runs on the Linux remote.

Steps to Reproduce

  1. Open a single-folder workspace that is a subdirectory of a git repo (workspace != git toplevel). Remote-SSH is enough; multi-root is not required.
  2. Ask the agent to run a Shell call with working_directory set to the git toplevel (the parent of the workspace):
pwd; git rev-parse --show-toplevel; git status --short -- <path-from-git-root-to-workspace>/
  1. Compare three things from that one call:
    • pwd inside the command
    • the Shell tool footer Current directory:
    • git’s path warning

Just reproduced 2026-08-16 in this session:

  • Tool arg working_directory: /path/to/git-root
  • Footer: Current directory: /path/to/git-root
  • pwd: /path/to/git-root/nested/workspace
  • git: warning: could not open directory ‘nested/workspace/nested/workspace/’: No such file or directory

git -C /path/to/git-root … works. Inline cd is the other workaround. Do not trust working_directory.

Expected Behavior

  1. The spawned process cwd must be the requested working_directory, so pwd and git see that directory.
  2. If cwd cannot be set, the tool should error and not run the command.
  3. The footer Current directory: must come from a real pwd after spawn, not echo the requested argument. A lying footer is what makes the agent keep using site-relative paths.

Operating System

Windows 10/11
Linux

Version Information

Version: Cursor 3.16.17 (6b2afae0257df2bb5e1835f15165dc2f0de056b0, 2026-08-14T01:41:12.803Z)
OS Version: Windows_NT x64 10.0.26200
Remote: Linux (Ubuntu 24.04.4 LTS, 7.1.5-x64v3-xanmod1) via Remote-SSH
CPUs: AMD Ryzen 9 9950X3D 16-Core Processor (32 x 4292)

For AI issues: which model did you use?

Cursor Grok 4.6 (Agent). Reproduced by the agent itself via the Shell tool, not a user-typed terminal.

For AI issues: add Request ID with privacy disabled

e6572f2e-29a5-4085-8996-8b0ff5893d18

Additional Information

Related:

This report is the inverse of the first thread: we ask for the parent of the workspace (the git root). Process cwd stays in the workspace. Footer still claims the parent. Repo-relative git paths then double.

Workspace folder name starts with a hyphen. Unlikely the cause, but it is in the path.

Workaround we now use: always git -C /absolute/git/root plus repo-relative paths. Never rely on Shell working_directory.

Does this stop you from using Cursor

No - Cursor works, but with this issue