Sign up
View stargazersSign up

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

openedOct 6, 2026byDdrrius

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

shell
1$ 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="
2issuer=C=US, ST=California, O=Zscaler Inc., OU=Zscaler Inc., CN=Zscaler Intermediate Root CA (zscalerthree.net) (t)
3No ALPN negotiated
4
5# Provider event log, run.completed:
6{"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.

JJulius MarmingeOct 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

  • 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 #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 #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.

JJoseAcevesGon21d ago
Synced from GitHub

Another case with the same root cause, and a broader trigger than TLS inspection.

Environment: Windows 11, T3 Code desktop 0.1.0 (the 0.1.2 release notes have no change here), Cursor provider using cursor-agent-sdk.local. The network requires an explicit HTTP proxy (HTTPS_PROXY / NODE_USE_ENV_PROXY=1 set). The proxy does not inspect TLS.

Evidence:

  • Direct TCP to api2.cursor.sh:443 times out (ETIMEDOUT).
  • Through the proxy (CONNECT api2.cursor.sh:443 → 200), TLS negotiates ALPN h2 with the real Amazon RSA 2048 M04 certificate. So ALPN is fine here.
  • The bundled SDK's h2 transport opens sessions with http2.connect(authority, options), which doesn't honor HTTPS_PROXY/NODE_USE_ENV_PROXY. Agent runs try to connect directly and hang.
  • Provider event log: every Cursor run either got no interaction updates and was cancelled after 2–12 min, or ended with run.completed … "status":"error","error":{"message":"Connection failed repeatedly"} after 748 s.

Why this matters for the fix: in Electron's Node, the SDK only uses HTTP/1.1 when Cursor.configure({ local: { useHttp1ForAgent: true } }) is called, so any user behind a mandatory proxy can't use the Cursor provider. Node 24's HTTP/1.1 stack honors NODE_USE_ENV_PROXY, so the fix suggested above should cover this case too.

Possible narrow fix: call Cursor.configure({ local: { useHttp1ForAgent } }) once at startup. Turn it on when the Cursor provider setting is enabled, when network.useHttp1ForAgent in ~/.cursor/cli-config.json is true, or automatically when HTTPS_PROXY is set and NODE_USE_ENV_PROXY=1.