Tool calls broken when using Remote Dev Containers (win11/WSL2)_

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Since yesterday, the agent can’t make any successful tool calls anymore to my code.
Whenever it tries to do any tool calls (reading files, executing commands, writing edits etc) the agent gets stuck and the tool call fails after a timeout.

The CLI agent inside of WSL works fine.
Running the same prompt when connected to WSL, but not inside of a dev container works fine as well.

Steps to Reproduce

  • Connect to WSL from cursor
  • Open a project that has a dev container
  • Choose ‘Reopen in contianer’ when asked to
  • Ask the agent to make a code change
  • All tool calls fail after a timeout

Expected Behavior

  • Connect to WSL from cursor
  • Open a project that has a dev container
  • Choose ‘Reopen in contianer’ when asked to
  • Ask the agent to make a code change
  • Agent successfully makes tool calls

Operating System

Windows 10/11

Version Information

Version: 3.9.16 (user setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
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

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. The environment and steps really helped.

This looks like a known issue on our side, not something wrong with your Dev Container config. In a nested setup like WSL → Reopen in Container, the agent execution provider doesn’t start in the remote extension host, so tool calls wait for a timeout and then fail with ERROR_EXTENSION_HOST_TIMEOUT. Chat keeps working, which is why only file reads, commands, and edits break. We’re also tracking the same symptom in a related thread: [WSL Remote] anysphere.cursor-agent-exec never registers — every agent prompt times out (ERROR_EXTENSION_HOST_TIMEOUT) in remote-WSL windows only; works locally and via cursor-agent CLI

There’s no fix yet, and I can’t share an ETA. The working workarounds for now, which it sounds like you already found:

  • Use the cursor-agent CLI directly inside WSL.
  • Work in WSL directly without Reopen in Container until we fix this.

I’ve reported this internally as a separate case for nested WSL → Dev Container. I’ll post an update in the thread when I have one.

8

Just FYI in my case there is no nesting at all. I’m just trying to connect to WSL from Agent UI

image
image884×573 18.3 KB

9

Hey @Marcin_Ceglarek ! Tarun here from the engineering team.

Can you please share your logs, I am unable to reproduce from my end.

ctrl + shift + p > Export logs > select Remote - WSL and main and share it here please!

11

Hi Tarun, thanks for reaching out… Problem is there is no ‘export logs’ in agentic UI

image
image826×441 16.3 KB

12

I did some more testing and when i created workspace in WSL in IDE (gemini one) the ubuntu starts with small letter, when create workspace from Agent Window, it appear with capital Ubuntu and this one is not working … maybe this is something to check

image

13

Connected to broken workspace via IDE and collected logs:

remote-wsl-cursor.log (11.8 KB)

15

Hey, quick update on this bug. We found the root cause and the fix is already merged internally. It covers both cases from the thread: nested WSL → Reopen in Container (@Elwin), and @Marcin_Ceglarek’s case with capital Ubuntu vs lowercase from the Agent Window. That one was a separate casing bug in the registry keys.

One important note: the fix isn’t in a public build yet, so I can’t share an exact version or ETA. Updating to the current stable won’t fix it today. As soon as the fix ships, we’ll post here with the version number.

Until then, the workarounds are the same: use the cursor-agent CLI inside WSL, or work in WSL directly without Reopen in Container.