Agent fails with ERROR_EXTENSION_HOST_TIMEOUT on non‑English Windows — agent-exec PowerShell SID lookup has a quoting bug

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Every Agent request fails immediately with “Agent Execution Timed Out” (ERROR_EXTENSION_HOST_TIMEOUT / deadline_exceeded) on a French Windows installation. Network diagnostics are all green (SSL, HTTP/2, API, Agent stream), so this is not a connectivity issue.

The Developer Tools console shows the real cause: the built‑in agent-exec component runs a PowerShell one‑liner to translate well‑known SIDs (S-1-5-18 = SYSTEM, S-1-5-32-544 = Administrators) into localized account names. The SID is passed as a trailing argument after -Command, expecting it to land in $args[0]. PowerShell instead appends it to the command text, producing …).Value S-1-5-18, which is a parser error. The lookup never returns, the exec provider never initializes, and the workbench times out.

Steps to Reproduce

Use Windows with a non‑English system language (tested on French).

Install Cursor and open any local folder.

Open the Agent panel and send any prompt (e.g. “list the files in this folder”).

Observe the immediate “Agent Execution Timed Out” error.

Ctrl+Shift+P → Developer: Toggle Developer Tools → Console → see the repeated [Extension Host:agent-exec] PowerShell ParserError entries above.

Expected Behavior

agent-exec resolves the SIDs correctly regardless of Windows language (e.g. BUILTIN\Administrateurs, AUTORITE NT\Système on French Windows) and the Agent starts normally.

If the lookup fails, the Agent should fall back gracefully (or surface the real error) instead of hanging until deadline_exceeded with a misleading “extension host is not running” message.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.20.17 (user setup)
VS Code Extension API: 1.128.0
Commit: 0c32194e3fb5ffaced9fb36430b860ec301e1fc0
Date: 2026-09-12T03:16:10.634Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Additional Information

console output : ERR [Extension Host:agent-exec] Au caractère Ligne:1 : 118

  • … s[0]).Translate([System.Security.Principal.NTAccount]).Value S-1-5-18
  •                                                              ~~~~~~~~
    

Jeton inattendu «S-1-5-18» dans l’expression ou l’instruction.
+ CategoryInfo : ParserError: (:slight_smile: , ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken

ERR [Extension Host:agent-exec] Au caractère Ligne:1 : 118

  • … ).Translate([System.Security.Principal.NTAccount]).Value S-1-5-32-544
  •                                                          ~~~~~~~~~~~~
    

Jeton inattendu «S-1-5-32-544» dans l’expression ou l’instruction.
+ CategoryInfo : ParserError: (:slight_smile: , ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken

Does this stop you from using Cursor

Yes - Cursor is unusable

I had to roll back to Cursor 3.18 to be able to use it

Hi @Ruben_De_Araujo,

Thanks for the report. This should now be working for you if you upgrade back to 3.20 — please let us know if it isn’t. We’ll be further hardening this in our next patch of v3.20.

Now, it works sometimes with 3.20 but it is not robust. A copy request on 3.20 :

Request ID: e36614e5-4c84-4062-8cb5-de5c5f85f9f2
{“error”:“ERROR_EXTENSION_HOST_TIMEOUT”,“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 S6d (vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8453:39054)
at vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8453:47383
at async x6d.createExecInstance (vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8453:41251)
at async CSu (vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7026:42662)
at async Ck.execute (vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7245:4741)
at async s6d.execute (vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8453:15398)
at async a$i.execute (vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8453:6147)
at async Tw_.execute (vscode-file://vscode-app/c:/Users/Ruben/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:17885:1728)

Thanks @Ruben_De_Araujo

Are you still seeing these, or are they absent now?

I have this with 3.20, looks the same :

Can you check that you’re on 3.20.21 or higher? It should be fixed there!

Cursor Agent fails with exec-daemon timeout — better-sqlite3 ABI mismatch

I’m using Cursor 3.20.21 (User Setup) on Windows.

The Cursor Agent fails with:

The agent execution provider did not respond in time.

After checking the Cursor Agent worker logs, I found the actual error:

Error starting exec-daemon: The module
'...\cursor-agent\versions\2026.09.15-d2fe57e\node_modules\better-sqlite3\build\Release\better_sqlite3.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 127.
This version of Node.js requires NODE_MODULE_VERSION 137.

The embedded Agent Node.js is:

v24.5.0 ABI=137

The installed better-sqlite3 version is:

12.11.1

Its package metadata actually lists support for Node 24:

"node": "20.x || 22.x || 23.x || 24.x || 25.x || 26.x"

So the problem appears to be that Cursor Agent is running Node 24 / ABI 137, while the bundled native better-sqlite3 binary was compiled for Node 22 / ABI 127.

I also deleted the cached Agent CLI completely:

Remove-Item "$env:APPDATA\Cursor\User\globalStorage\anysphere.cursor-agent-worker\agent-cli" -Recurse -Force

After restarting Cursor, it downloaded the Agent again:

2026.09.15-d2fe57e

But the exact same ABI mismatch remained. The fresh download still contains the better_sqlite3.node compiled against ABI 127.

The worker repeatedly starts, authenticates successfully, and then fails at:

Starting worker...
Authenticating with API key...
Authenticated with API key
...
Error starting exec-daemon:
better_sqlite3.node ... NODE_MODULE_VERSION 127
This version of Node.js requires NODE_MODULE_VERSION 137

As a result, the worker exits and the Agent eventually reports:

The agent execution provider did not respond in time.

It looks like the current Cursor Agent package may contain a better-sqlite3 native binary built for Node 22 while the bundled runtime has been upgraded to Node 24.

Has anyone else encountered this with Cursor 3.20.21 / Agent 2026.09.15-d2fe57e on Windows?

Hi Colin,

I started using 3.20.21 today and it works well now.

You can close the chat.

Thank you.