Remote SSH on jailed hosts not working - older (working!) version no longer supported!

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After connecting to a Remote SSH host that is running ISPConfig jailkit.

Steps to Reproduce

Connect to a Remote SSH with chroot jailkit and the agent times out on “Waiting for extension host”

Screenshots / Screen Recordings

image (2).png
image (2).png511×173 4.77 KB

Operating System

Windows 10/11

Version Information

Version: 3.0.13 (system setup)
VSCode Version: 1.105.1
Commit: 48a15759f53cd5fc9b5c20936ad7d79847d914b0
Date: 2026-04-07T03:05:17.114Z
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: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

All models

For AI issues: add Request ID with privacy disabled

Request ID: 98869cd9-000a-4982-935e-0a12e8bdbb6e
{“error”:“ERROR_CUSTOM”,“details”:{“title”:“Agent Execution Timed Out”,“detail”:“The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.”,“isRetryable”:false,“shouldShowImmediateError”:true,“additionalInfo”:{},“buttons”:[{“label”:“Reload Window”,“reloadWindow”:{}}],“planChoices”:}}
Agent Execution Timed Out [deadline_exceeded]
ConnectError: [deadline_exceeded] Agent Execution Timed Out
at vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:53345:23460
at async hg_.createExecInstance (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:53345:20015)
at async lqy (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:43738:623141)
at async $4.execute (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:43959:14688)
at async Vhd.execute (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:53345:1749)
at async bK_.execute (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:56367:4966)
at async C0d.buildComposerRequestContext (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:56377:4190)
at async C0d.streamFromAgentBackend (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:56377:6906)
at async C0d.getAgentStreamResponse (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:56377:17161)
at async ZOe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:44075:19892)
at async Gl (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:55360:4891)

Additional Information

The last version that was working fine for us was v2.3.35.
We were using the older version, however, starting today this was no longer possible as we are now receiving a message that it’s no longer supported.

This affects my entire team (8 users).

Why stop support for the older version when there is no working solution for this bug ??

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey @Cezar_Dumitrescu I remember your previous thread Stuck at “Waiting for extension host”. It sucks that the issue is back.

Since then, we shipped a fix for the no Landlock V3 agent timeout case late March. It adds a Bubblewrap fallback, but it looks like in a chroot or jailkit setup it still doesn’t work. The chroot jail likely blocks the access needed even to detect that sandboxing isn’t available.

Can you check a couple things on the remote host inside the jail?

  1. bwrap --version is Bubblewrap available at all?
  2. ls -la /proc/self/status do you have access to /proc?

This will help us understand why the fallback isn’t working on v3.0.13.

I passed this to the team. Your setup chroot or jailkit plus kernel 5.4 is an edge case the current fix didn’t cover. I can’t promise an exact ETA, but your report helps raise priority, especially since 8 users are blocked and the old workaround with v2.3.35 isn’t available anymore.

Let me know what you find.

8

Hi @deanrie

I don’t have bubblewrap or access to /proc - sorry :frowning:

$ bwrap --version
bash: bwrap: command not found

$ ls -la /proc/self/status
ls: cannot access '/proc/self/status': No such file or directory
9

Hey @Cezar_Dumitrescu, thanks for checking. No bwrap and no /proc confirms what we suspected, the chroot jail blocks both sandbox paths.

To be honest, even if bwrap were installed, it probably wouldn’t help. Bubblewrap itself needs /proc to set up namespaces, and sftp chroot and bubblewrap don’t really work together. The chroot SSH session also doesn’t have the privileges bubblewrap needs to start. So this was more of a diagnostic step than a real workaround.

The one option on your side is mounting /proc inside the jail:

mount -t proc proc /path/to/jail/proc

This usually needs root access on the host and might conflict with the jail security policy, so it’s worth checking with your server admin.

If that’s not possible, the fix needs to come from our side. Cursor should detect the chroot environment earlier and gracefully skip sandboxing instead of hanging. I shared this with the team with the exact failure scenario. No ETA yet, but 8 users blocked by the same issue helps us prioritize.

I’ll update this thread when there’s news.

10

Hi @deanrie

Thank you for the support - please keep us updated. We’re unable to modify the jail security policy unfortunately.

I would like to add that we have been using Cursor with these types of servers perfectly fine until v2.4 I believe.

11

Hi @deanrie - any update on this bug?

12

Hey Cezar, to be honest there’s no real progress since the last update. The ticket is still in the tracker, but it hasn’t moved up in the queue. I can’t share an ETA for the fix yet.

Since you’ve got 8 users blocked and there’s no workaround on the jail side, I’ll ping the team again to raise the priority. As soon as there’s real movement or an ETA, I’ll reply here. I won’t bug you with no-news updates.

I know this situation is really frustrating, especially since the old version no longer works. Thanks for your patience.