Cursor Parallel Agents in WSL devcontainers misresolve worktree paths and @context

[John_Munson]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Parallel Agents in Cursor appear to have a broken internal file/context resolution layer when used in a WSL2 + dev container environment. The agents’ non-terminal file access path (used for @mentioned context, file search, and worktree setup discovery) produces ENOENT errors with malformed/double-prefixed worktree paths, even though the files exist and are readable from the terminal inside the same worktree.

This results in:

• Failure to reliably ingest @mentioned file context.
• Spurious attempts to locate files that are already present.
• Worktree setup logs incorrectly reporting that .cursor/worktrees.json is missing in both the root workspace and the worktree, despite the file existing in both locations.
• Agents falling back to terminal cat to read files successfully.

This looks like a tooling/path normalization bug in Cursor’s parallel-agent worktree integration, not a model reasoning issue.

Steps to Reproduce

Environment:

• Windows host
• WSL2
• Dev container
• Cursor Parallel Agents enabled
• Repo mounted at /workspace
• Git worktrees created by Cursor under /root/.cursor/worktrees/...

1. Ensure a valid worktree setup config exists at:

   • /workspace/.cursor/worktrees.json

   Example:

   {
     "setup-worktree": [
       "pnpm install --frozen-lockfile",
       "cp $ROOT_WORKTREE_PATH/.env.local .env.local"
     ]
   }
   

2. Confirm Cursor creates worktrees:

   git worktree list
   

   Example output:

   • /workspace ... [dev-branch]
   • /root/.cursor/worktrees/<container-id>/<id> ... (detached HEAD)

3. Create a small probe file in repo root:

   • /workspace/cursor_probe.txt with contents:

     CURSOR_PROBE_12345
     

4. Run a Parallel Agent prompt such as:

   • “Please respond with the contents of this file: @cursor_probe.txt”

5. Observe agent trace:

   • The agent attempts internal reads/search and hits ENOENT with malformed worktree paths.
   • It may log that the “Search files model provided non-existent directory.”
   • It eventually resorts to a terminal command:

     cat cursor_probe.txt
     

     which succeeds.

6. Open Output → “Worktrees Setup” and observe logs similar to:

   checking config ... 
   worktreeConfigFile: file:///root/.cursor/worktrees/.../<id>/.cursor/worktrees.json
   rootConfigFile: file:///workspace/.cursor/worktrees.json
   no config file found in worktree or root, skipping
   

7. Manually verify both files exist after the run:

   ls -la /workspace/.cursor/worktrees.json
   ls -la /root/.cursor/worktrees/<...>/<id>/.cursor/worktrees.json
   

   Both exist.

Expected Behavior

• Parallel Agents should correctly resolve workspace and worktree paths inside the dev container.
• @mentioned files (e.g., @cursor_probe.txt) should be reliably read and injected into agent context without requiring terminal fallbacks.
• The worktree setup checker should correctly detect:
  • /workspace/.cursor/worktrees.json
  • <worktree>/.cursor/worktrees.json
    and run setup rather than incorrectly reporting missing config.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.1.50 (system setup)
VSCode Version: 1.105.1
Commit: 56f0a83df8e9eb48585fcc4858a9440db4cc7770
Date: 2025-12-06T23:39:52.834Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26100

For AI issues: which model did you use?

Models observed during testing:

• Composer 1
• Sonnet 4.5

However, this does not appear to be a model reasoning error. The model’s behavior is consistent with missing context: it attempts to read a file that should have been available via Cursor’s context system and only succeeds when given direct terminal access. The failure mode is deterministic and path/FS-related (ENOENT with malformed paths, false-negative config detection), pointing to Cursor’s parallel agent infrastructure rather than the model.

Additional Information

Key observations that narrow root cause:

• Git and worktrees appear correct inside the container:

  pwd -> /workspace
  git rev-parse --show-toplevel -> /workspace
  git worktree list -> shows Cursor worktrees under /root/.cursor/worktrees/...
  

• Files exist inside the worktree:

  ls -la components/prompt/prompt-input.tsx
  

• The agent’s terminal operates correctly inside the worktree.
  The agent’s internal file/context resolver appears to be the failing component.

• Worktree setup logs incorrectly claim missing config even when both exist:

  • /workspace/.cursor/worktrees.json
  • /root/.cursor/worktrees/.../<id>/.cursor/worktrees.json

• The environment is a layered path/mount scenario:

  • Windows + WSL2 + dev container
  • Worktrees located at /root/.cursor/worktrees/...
  • Workspace root at /workspace

Hypothesis:

• A bug in Cursor’s parallel-agent internal path normalization or indexing layer in remote devcontainer-on-WSL scenarios, potentially producing double-prefixed worktree paths and causing ENOENT/false-negative config detection.
• Possibly a race in initialization, but the repeated malformed path symptoms suggest a path resolver defect more than timing alone.

This report should be sufficient to reproduce and triage.

Does this stop you from using Cursor

Yes - Cursor is unusable

[John_Munson]

It’s worth noting that I did some further testing after posting this and there is one positive thing that I can confirm…

This issue does not exist when just using WSL, rather than WSL + devcontainers.

However, I cannot confirm whether or not the issue is isolated purely to the unique combination of WSL + devcontainers, or if it is triggered by devcontainer usage in general.

Regardless, I do hope this issue gets addressed because, whether I’m developing on Windows or macOS, I typically appreciate a container-based workflow. There’s a number of reasons for this, but the main one is simply keeping my environments clean and isolated.

[Colin]

Hey @John_Munson !

I think you’re right that this is the same issue reported here:

Worktrees Setup not working in WSL

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug The Worktrees Setup feature doesn’t work when Cursor is running inside WSL. When I start an agent chat in Worktree mode within WSL, the setup process fails to find the configuration file even though it exists. In the IDE logs, I see this: [worktree-setup] checking config {"composerId":"36f27267-93fa-4616-85c9-47e238febff6","worktreePath":"/home/erickluis00/.cursor/worktrees/acessopro__WSL__ubuntu-22.04_/1W1Q0","rootWork…

It looks like the team will work on this soon. Hopefully, we have it fixed for you soon!