[Bug]: Cursor provider fails behind a TLS-inspecting proxy because the SDK always uses HTTP/2

[drrius]

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

1. Use a network whose proxy inspects TLS and negotiates no ALPN, such as Zscaler with SSL inspection on *.cursor.sh. To check, run echo | openssl s_client -connect api2.cursor.sh:443 -servername api2.cursor.sh -alpn h2,http/1.1. It prints No ALPN negotiated and a Zscaler issuer.
2. 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.

[juliusmarminge]

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

• This looks like an integration gap with @cursor/sdk 1.0.35, which 0.0.46-nightly.20261005.2702 bundles. I didn't reproduce it on a Zscaler network, but the logged run.completed error matches the SDK, and T3 never turns on its HTTP/1.1 switch.
• In 1.0.35 the agent transport uses HTTP/1.1 only when the backend URL is http:, when Cursor.configure({ local: { useHttp1ForAgent: true } }) has been called (configureCursorSdk), when running under Bun, or when the account's server Http2Config disables HTTP/2. Otherwise it uses HTTP/2.
• T3 never calls Cursor.configure. makeCursorAgentOptions in apps/server/src/orchestration-v2/Adapters/CursorAdapterV2.ts sets no network option, and 1.0.35's LocalAgentOptions has no useHttp1ForAgent field. The flag is read only inside configureCursorSdk, so passing it on Agent.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.
• That produces the logged expected h2 session, but ALPN protocol failed to negotiate, thrown by the SDK's own h2 session client when ALPN doesn't negotiate h2.
• Why it regressed: the version-selection rule is the same in 1.0.31, but 1.0.31 used @connectrpc/connect-node and doesn't contain this ALPN error. 1.0.35 dropped that dependency. The only Cursor-related change between .2676 (SDK 1.0.31) and .2702 is chore(deps): bump cursor sdk and astro to clear vulnerable transitives #16214, which matches your timeline. The CLI working on the same network with network.useHttp1ForAgent: true also suggests your account isn't in a server-forced HTTP/2 mode, so the local flag would take effect.
• Workaround: there's no in-app one (1.0.35 has no CURSOR_USE_HTTP1 env var). Exempting *.cursor.sh from SSL inspection is the only option for now.
• The thread showing only "Provider turn failed." is a separate issue: makeProviderFailure keeps 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 from network.useHttp1ForAgent in ~/.cursor/cli-config.json, from a Cursor provider setting, or both.

A maintainer will decide on the fix direction.