Repository navigation
[Bug]: Cursor provider fails behind a TLS-inspecting proxy because the SDK always uses HTTP/2 #16435
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Use a network whose proxy inspects TLS and negotiates no ALPN, such as Zscaler with SSL inspection on
*.cursor.sh. To check, runecho | openssl s_client -connect api2.cursor.sh:443 -servername api2.cursor.sh -alpn h2,http/1.1. It printsNo ALPN negotiatedand a Zscaler issuer. - Start any turn on a Cursor provider instance. A delegated task fails the same way.
Expected behavior
The turn runs. The Cursor CLI and IDE work on the same machine and network, because the CLI sets "network": { "useHttp1ForAgent": true } in ~/.cursor/cli-config.json and the IDE sets "cursor.general.disableHttp2": true.
Actual behavior
The turn fails after about 20 seconds, and the thread shows only "Provider turn failed." The provider event log has the real error (see Logs). All 13 Cursor runs on 2026-10-06 failed this way, on grok-4.7, grok-4.6, and gemini-3.1-pro.
Cause: @cursor/sdk 1.0.35 picks HTTP/1.1 for the agent transport only when the backend URL is http:, the host passes local.useHttp1ForAgent in the SDK config, the SDK runs under Bun, or Cursor's server config forces it for the account (Http2Config FORCE_ALL_DISABLED or FORCE_BIDI_DISABLED). Otherwise it uses HTTP/2. The T3 server runs the SDK under Electron's Node and never passes useHttp1ForAgent. The provider settings have no option for it, and the SDK does not read ~/.cursor/cli-config.json.
Suggested fix: pass local: { useHttp1ForAgent } to the SDK config. Take the value from network.useHttp1ForAgent in ~/.cursor/cli-config.json, from a setting on the Cursor provider instance, or both. Showing the SDK's error message instead of "Provider turn failed." would also help, and #16146 looks like it covers that.
Impact
Blocks work completely
Version or commit
0.0.46-nightly.20261005.2702 (Cursor turns worked on 0.0.46-nightly.20261005.2676, but #16214's SDK bump picks HTTP versions the same way, so the cause of the change is unclear)
Environment
macOS on Apple silicon (Darwin 25.5.0), T3 Code (Nightly) desktop app, bundled @cursor/sdk 1.0.35, Cursor provider (grok-4.7), Zscaler with SSL inspection; Cursor CLI 2026.10.01-e373342 works on the same network
Logs or stack traces
$ echo | openssl s_client -connect api2.cursor.sh:443 -servername api2.cursor.sh -alpn h2,http/1.1 2>/dev/null | grep -E "ALPN|issuer="
issuer=C=US, ST=California, O=Zscaler Inc., OU=Zscaler Inc., CN=Zscaler Intermediate Root CA (zscalerthree.net) (t)
No ALPN negotiated
# Provider event log, run.completed:
{"type":"run.completed","result":{"status":"error","error":{"message":"[unknown] [unavailable] expected h2 session, but ALPN protocol failed to negotiate"},"model":{"id":"grok-4.7"},"durationMs":19397}}Screenshots, recordings, or supporting files
No response
Workaround
None inside T3. Outside T3, IT can exempt *.cursor.sh from SSL inspection.
Activity
juliusmarminge commentedon Oct 6, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks @drrius for the detailed report and for pinning down the nightly where it broke, that narrowed this down a lot.
What I found
@cursor/sdk1.0.35, which0.0.46-nightly.20261005.2702bundles. I didn't reproduce it on a Zscaler network, but the loggedrun.completederror matches the SDK, and T3 never turns on its HTTP/1.1 switch.http:, whenCursor.configure({ local: { useHttp1ForAgent: true } })has been called (configureCursorSdk), when running under Bun, or when the account's serverHttp2Configdisables HTTP/2. Otherwise it uses HTTP/2.Cursor.configure.makeCursorAgentOptionsinapps/server/src/orchestration-v2/Adapters/CursorAdapterV2.tssets no network option, and 1.0.35'sLocalAgentOptionshas nouseHttp1ForAgentfield. The flag is read only insideconfigureCursorSdk, so passing it onAgent.create({ local })would be ignored. The SDK also doesn't read~/.cursor/cli-config.json, and desktop runs on Electron's Node, so the Bun default doesn't apply.expected h2 session, but ALPN protocol failed to negotiate, thrown by the SDK's own h2 session client when ALPN doesn't negotiateh2.@connectrpc/connect-nodeand doesn't contain this ALPN error. 1.0.35 dropped that dependency. The only Cursor-related change between.2676(SDK 1.0.31) and.2702is chore(deps): bump cursor sdk and astro to clear vulnerable transitives #16214, which matches your timeline. The CLI working on the same network withnetwork.useHttp1ForAgent: truealso suggests your account isn't in a server-forced HTTP/2 mode, so the local flag would take effect.CURSOR_USE_HTTP1env var). Exempting*.cursor.shfrom SSL inspection is the only option for now.makeProviderFailurekeeps that default unless given an explicit message. Open PR fix(server): failed Cursor turns show Cursor's reason #16146 covers surfacing Cursor's reason.Likely fix area
One option is calling
Cursor.configure({ local: { useHttp1ForAgent } })once, before any Cursor agent is created (chat turns and Cursor text generation), since the setting is process-wide rather than per-agent. The value could come fromnetwork.useHttp1ForAgentin~/.cursor/cli-config.json, from a Cursor provider setting, or both.A maintainer will decide on the fix direction.