`Shell` tool does not reliably honor `working_directory`

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m seeing what looks like a bug in Cursor’s Shell tool where the working_directory argument is not consistently applied to the command being executed.

Edit: Reproduction Request IDs

  • With GPT-5.4: 07900b06-2e57-4f6b-a1f4-69f83abbc1b9
  • With Claude Opus 4.6: 8167ddb0-0f95-49a0-b4b3-5ff8bff1513e

Steps to Reproduce

  1. Open a project that has a backend/ subdirectory.

  2. Ask the agent to run a shell command with working_directory set to that backend/ directory.

  3. Example command:

    pwd
    
  4. Also tried:

    uv run python -c 'import os; print(os.getcwd())'
    

Actual behavior
Both commands reported the project root instead of the specified backend/ directory.

At the same time, Cursor’s shell session metadata later indicated that the persisted shell cwd had changed to the backend/ directory. That makes it look like the session state updates after the command, but the command itself still executes in the previous directory.

Expected Behavior

The command should run inside the specified backend/ directory, so both commands should report the backend directory as the current working directory.

Operating System

MacOS

Version Information

Version: 3.1.10
VSCode Version: 1.105.1
Commit: dacbe9b31599a253763e4910eb6ab38704653320

For AI issues: which model did you use?

GPT-5.4 for testing

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report.

To figure out what’s actually happening, we’ll need the Request ID from a chat where the issue reproduces. That lets us check what value the model is really sending for working_directory to the Shell tool, so we can tell if it’s a model issue or a platform issue.

How to get it: in the chat, open the context menu (three dots in the top right) > Copy Request ID.

One more thing, have you tried reproducing this with a different model besides GPT-5.4? Historically, CWD issues like this were more often about how the model formats the tool call args, not the command execution itself. It’d be really helpful to see if it also reproduces with Claude.

Let me know how it goes.

Thanks for the quick reply. Here are the Request IDs for two minimal reproductions:

  • With GPT-5.4: 07900b06-2e57-4f6b-a1f4-69f83abbc1b9
  • With Claude Opus 4.6: 8167ddb0-0f95-49a0-b4b3-5ff8bff1513e

Hope it helps!

Thanks for the quick follow-up with the request IDs!

I checked both request IDs and can confirm this is a platform-side issue, not a model issue. In both reproductions, the model correctly sent the working_directory value pointing to your subdir directory, but the command itself executed in the workspace root. The shell metadata updating afterward with the correct directory is consistent with what you observed.

I wasn’t able to reproduce this on the latest version of Cursor. Since you’re on 3.1.10, could you update to the latest version and test again? If the issue still reproduces after updating:

  1. Share a new Request ID from the updated version

  2. Include the Cursor version shown in Help > About

That will help us determine whether this was resolved in a recent update or if it’s still present.

Hello Mohit,

I upgraded to 3.1.15 and ran my experiment again - the issue persists. New request IDs:

  • GPT 5.4: 70b4b05c-749e-4660-b66b-5426733a60c3
  • Claude Opus 4.7: 084f6bbc-6007-4ae8-91e2-7ad327504150

Full About Cursor content:

Version: 3.1.15
VSCode Version: 1.105.1
Commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Date: 2026-04-15T01:46:06.515Z (5 days ago)
Layout: editor
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.3.0

This same issue also came up for my colleague on a different machine (also on mac).

Hey @mbraak

Thank you for the follow-up, the additional request IDs, and for confirming this on 3.1.15 and a second machine – that’s all extremely helpful.

I’ve now inspected the request IDs you shared. In every case, the model is sending the correct working_directory value in the tool call arguments. The issue is on the platform side – the working_directory parameter is received but not properly applied to command execution, so pwd returns the workspace root.

We have a strong hypothesis about the root cause, and we believe it may already be addressed in the nightly build. Could you try the following to help us confirm?

  1. Install Cursor Nightly if you don’t have it already

  2. Open your same cursor_bug_reproduction workspace in Nightly

  3. Run the same reproduction steps (ask the agent to run pwd with working_directory set to subdir)

  4. Share the Request ID from that attempt (found in Cursor Settings > General > scroll to bottom > Request ID) – regardless of whether it works or fails

If it works on Nightly, that confirms our hypothesis and the fix will ship with the next stable release. If it still fails on Nightly, we’ll file it for deeper investigation.

Appreciate your patience and the detailed reproduction steps – they made tracking this down much faster.

Does not seem to work either: 710de71e-a29f-40fd-97dc-d289efff3b07

Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z (20 hrs ago)
Layout: editor
Build Type: Stable
Release Track: Nightly
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.3.0

Thanks for testing on Nightly and sharing the request ID. I’ve confirmed from the logs that the issue persists on 3.1.17, same behavior as before: the working_directory is correctly received but not applied to the actual command execution.

Our initial hypothesis about the fix being present in Nightly didn’t hold up. I’ve updated the report with your latest findings and escalated this for further investigation. Apologies for the extra round of testing on your end.

I’ll follow up here once there’s progress. Thank you for your patience and the thorough reproductions across versions.

Describe the Bug

This is only happening in one specific directory, but every time the agent makes a Shell toolcall, the working directory is ignored and the command is always ran from the project root.

Steps to Reproduce

I can consistently use the below prompt and it will show me the return is the project root, not the temporary directory.

Run pwd in /tmp and let me know what it returns.

Expected Behavior

The command should actually be ran from the requested project root.

Operating System

MacOS

Version Information

This is only happening in one specific directory, but every time the agent makes a Shell toolcall, the working directory is ignored and the command is always ran from the project root. I can consistently use the below prompt and it will show me the return is the project root, not the temporary directory.

Run pwd in /tmp and let me know what it returns.

I’m not sure what additional context would be good here, but here is my version info:

Version: 3.1.17 (Universal)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
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.4.0

Does this stop you from using Cursor

No - Cursor works, but with this issue