[Windows] Agent Shell tool silently no-ops (exit 0, empty output, no side effects) when workspace path contains "#"

[RayC (Ray)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Windows, when the workspace root path contains a # character, the Agent/Composer Shell tool fails silently for every command. Each command returns exit code 0 with empty stdout/stderr in ~40 ms and produces no side effects (no process spawned, no files created). The integrated (human) terminal in the same workspace runs the identical commands perfectly. Opening the same files via a directory junction whose path has no # fixes the problem instantly.

Environment

• Cursor version: 3.10.11
• OS: Windows 11 (10.0.26200)
• Shells tested (all fail identically): Windows PowerShell (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe), Command Prompt (cmd.exe), Git Bash (D:\Program Files\Git\bin\bash.exe)
• Run Mode: Run Everything (unrestricted)
• Legacy Terminal Tool: tried both ON and OFF — no change

Steps to Reproduce

1. On Windows, create/open a workspace whose root path contains a #, e.g. D:\path\#project.
2. In an Agent chat, ask it to run any command, e.g. echo test.
3. Observe the Shell tool result.
4. For comparison, open a New Terminal in the same workspace and run echo test manually.

Expected Behavior

The Agent Shell tool spawns the shell, runs the command, captures stdout/stderr, and returns the real exit code — the same result the integrated terminal produces (test, exit 0, ~500 ms).

Operating System

Windows 10/11

Version Information

Version: 3.10.11 (user setup)
VS Code Extension API: 1.125.0
Commit: 4ef9fe3d055f8c4523179a090f14eb835bc3c940
Date: 2026-07-03T04:44:14.398Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Every Model

Additional Information

Log Evidence

• Approval/permission stage looks completely normal for every command:
  • Shell permissions: auto-approved shell command ... approvalMode:"unrestricted", mergedPolicyType:"insecure_none", allCommandsPreapproved:true
  • Shell stream: approval gate allowed command ... effectivePolicyType:"insecure_none"
• BUT after approval there is no execution:
  • renderer.log has no [ShellExec] Created session ... on LocalProcess host entry for these commands.
  • ptyhost.log for the session is empty — no PTY activity at all.
• Sandbox is (correctly) unavailable on Windows, which may be relevant to the execution-path selection:
  • [shell-exec:sandbox] [isSandboxHelperSupported] win32: returning false (proxy-only, no filesystem sandbox)
  • [ExtHostShellExec] Sandbox support detected: false, platform: win32
• The per-terminal state files under .cursor/projects/<id>/terminals/*.txt show only header/footer metadata (pid, cwd, command, exit_code: 0, elapsed ~40 ms) with an empty body between them.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Colin]

Hi @RayC,

Thanks for reporting this!

I tried to reproduce the issue using folders containing # in the directory path—both when # appeared in a parent directory and when it was part of the directory opened directly in Cursor. In every case, shell commands ran successfully without failure.

Could you confirm whether your workspace path is as simple as D:\path\#project? Also, does it matter where the # appears in the path—at the beginning, in the middle, or at the end? If you’re able to share an example that more closely reflects your actual setup, I’d be happy to investigate further and attempt to reproduce the issue on my end.

Does the issue occur in a brand-new workspace as well, or is it isolated to a specific workspace? Testing in a fresh workspace would help us determine whether the problem is workspace-specific or more broadly reproducible.

Thanks!