Shell/terminal sandbox fails to start on WSL2 — Failed to mount ".git/hooks" read-only: No such file or directory

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On WSL2, the agent/terminal command sandbox fails to start. Every command aborts during sandbox setup with an ENOENT while trying to bind-mount the workspace’s .git/hooks directory read-only:

Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: IO error: Failed to mount "/home/<user>/<parent>/<project>/.git/hooks" read-only: IO error: No such file or directory (os error 2)

The directory actually exists and is a normal, readable directory owned by the current user, so this looks like a sandbox path-resolution problem inside the sandbox mount namespace on WSL2, not a real filesystem issue.

Verified / ruled out:

  • .git/hooks exists as a normal directory (drwxr-xr-x), owned by the user; parent .git and project dir are normal dirs too.
  • Not a symlink (readlink -f resolves to the real path; ls -ld shows no ->).
  • Repo is healthy — git fsck shows only normal dangling objects, no corruption.
  • No git hook manager (no husky/overcommit/lefthook, no core.hooksPath override).
  • Reloading the window does not help.
  • Updating to the latest Cursor version does not help.
  • Editor file reads work fine; only the sandboxed shell fails.

Steps to Reproduce

  1. On Windows + WSL2, open a git-backed project stored on the WSL2 ext4 filesystem (under /home/…, not /mnt/c) in Cursor.
  2. Ask the agent to run any shell command (e.g. echo OK), or run one in the sandboxed terminal.
  3. The command aborts immediately at “Step 4/7 (mount denies)” with the error above.
  4. Every subsequent command fails the same way.
  5. /!\ Note: starting a brand-new chat directly in Agent mode works fine. The failure only occurs when the chat is started in Ask mode and then used (or switched to Agent) — the broken state persists for the rest of that chat session.

Expected Behavior

The sandbox mounts .git/hooks read-only (its hooks-protection step) and the command executes normally, since .git/hooks exists and is accessible.

The sandbox mount configuration appears to be computed once at chat/session creation based on the initial mode and is not recomputed on mode switch. Chats started in Agent mode build a working sandbox; chats started in Ask mode get a broken .git/hooks read-only mount that persists even after switching to Agent mode (reload/update do not clear it).

Operating System

Windows 10/11

Version Information

Version: 3.10.20 (system setup)
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
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?

N/A — this is an infrastructure/sandbox issue, not model-dependent. It fails for any command regardless of model.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Thanks for the incredibly thorough report and diagnostics. You’ve got it right: this is a bug on our side, not anything wrong with your repo. .git/hooks is one of the paths the sandbox mounts read-only as a protection step, and on WSL2 that mount is failing even though the directory is perfectly fine - so your git fsck clean, no-hook-manager, and not-a-symlink checks are all correct, and none of that is the cause.

Until the fix lands, you can unblock yourself by running shell commands outside the sandbox:

  1. Open Settings → Agents → Approvals & Execution.
  2. Pick a Run Mode that doesn’t sandbox shell commands - Run Everything (no sandbox), or Allowlist with sandboxing turned off.

Since the sandbox is a safety layer, only do this in repos you trust. More detail here: Run Modes & Sandboxing.

Your Ask-mode vs Agent-mode observation is a genuinely useful clue - I’ve passed all of this along and we’re tracking it. I’ll update here when there’s progress.

Thanks for that @mohitjain

I’m not super confident with disabling the sandbox so far. Too many horror stories out there :slight_smile:

Let me know if you find a fix. I’ll use the agent mode in between