Cursor Agent CLI stuck on "Reconnecting" in interactive mode — worker receives httpVersion: "1.1" but agent endpoint requires HTTP/2

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Cursor Agent CLI stuck on “Reconnecting” in interactive mode — worker receives httpVersion: “1.1” but agent endpoint reqfter upgrading Cursor to 3.2.21, the Cursor Agent CLI (cursor-agent) is unable to complete any chat in interactive mode. The terminal UI immediately shows a spinner with Reconnecting (attempt N, Xs) and never
recovers, no matter how long you wait.

The root cause has been traced: the interactive mode spawns a worker-server child process, and that worker is passed httpVersion: “1.1” inside AGENT_CLI_WORKER_OPTIONS. However, the Cursor agent endpoint
(agentn.global.api5.cursor.sh) uses Connect-RPC / gRPC over HTTP/2 — confirmed by response headers (Grpc-Status, Connect-Content-Encoding). The worker cannot establish a working connection over HTTP/1.1, so it
silently fails and enters a restart loop (the CLI abandons the broken worker, spawns a new one, and this repeats). This is what causes the persistent “Reconnecting” spinner.uires HTTP/2

Steps to Reproduce

  1. Set up proxy (Clash Verge with TUN mode, or any HTTP proxy at 127.0.0.1:7897)
  2. Export proxy env vars: export HTTPS_PROXY=http://127.0.0.1:7897
  3. Run: cursor-agent agent “hello” from any project directory
  4. Observe the spinner: ⠣⠄ Reconnecting (attempt 1, 2s)
  5. It never connects. Press Ctrl+C to exit.
  6. Verify --print mode works: cursor-agent --print “hello” (succeeds)

Expected Behavior

The interactive agent should connect and stream a response, just like --print mode does.

Screenshots / Screen Recordings

pc_20260504171135_297_280.png
pc_20260504171135_297_280.png972×584 28.4 KB

Operating System

MacOS

Version Information

Cursor IDE: 3.2.21
cursor-agent CLI: 2026.05.01-eea359f (also reproduced on 2026.04.30-4edb302)
Bundled Node.js: v24.5.0

For AI issues: which model did you use?

Reproduced with both opus-4.6-max-thinking and gpt-5.4-medium. Model choice does not affect the bug.

For AI issues: add Request ID with privacy disabled

The --print mode succeeds and returns a valid request ID (e.g., request_id: a615f187-…). Interactive mode never reaches the server, so no request ID is generated.
Worker log excerpt:
[info] runServer socketPath=…/worker.sock
AGENT_CLI_WORKER_OPTIONS={“httpVersion”:“1.1”,…}

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey, thanks for the detailed write-up.

This is a known issue and it’s being tracked in a big thread here: Cursor cli --connection lost, reconnecting. Right now interactive mode has two broken paths:

  • HTTP/2: streams get dropped (NGHTTP2_ENHANCE_YOUR_CALM)
  • HTTP/1: the payload grows and hits the 50MB limit (Append data exceeds maximum size of 52428800 bytes)

In your case there’s also a proxy angle. HTTP/2 streaming in the CLI uses native http2.connect(), which global-agent doesn’t patch. It only patches HTTP/1.1 via http.request and https.request. So when HTTPS_PROXY is set, streaming just bypasses the proxy and tries to reach AWS directly, which probably fails for you via Clash TUN. That explains why --print works (different path) but interactive doesn’t.

Current workarounds:

  • Headless mode: cursor-agent -p "prompt" works, like you noticed. Not a replacement for interactive, but it helps for one-shot tasks.
  • No system proxy: if you can temporarily disable Clash or HTTPS_PROXY and send traffic directly, interactive usually works.
  • Set useHttp1ForAgent: true in ~/.cursor/cli_config.json. This may go through the proxy, but it will hit the 50MB limit on non-trivial repos. Worth trying only if your project is very small.

If you can, please share the request ID from a successful --print run (the a615f187-...). That helps link your case to server logs.

A proper fix is being worked on by the team, but there’s no ETA yet. I’ll post back once there’s a version update.

6

unhandledRejection: [internal] Stream closed with error code NGHTTP2_ENHANCE_YOUR_CALM {“stack”:“ConnectError: [internal] Stream closed with error code NGHTTP2_ENHANCE_YOUR_CALM\n at i.from (/Users/allen/.local/share/cursor-agent/versions/2026.05.01-eea359f/index.js:2:102752)\n at d (/Users/allen/.local/share/cursor-agent/versions/2026.05.01-eea359f/index.js:2:46658)\n at Promise.reject (/Users/allen/.local/share/cursor-agent/versions/2026.05.01-eea359f/index.js:2:58633)\n at ClientHttp2Stream. (/Users/allen/.local/share/cursor-agent/versions/2026.05.01-eea359f/index.js:2:56998)\n at ClientHttp2Stream.emit (node:events:507:28)\n at ClientHttp2Stream.emit (node:domain:489:12)\n at emitErrorNT (node:internal/streams/destroy:170:8)\n at emitErrorCloseNT (node:internal/streams/destroy:129:3)\n at process.processTicksAndRejections (node:internal/process/task_queues:90:21)”,“error”:{“name”:“ConnectError”,“rawMessage”:“Stream closed with error code NGHTTP2_ENHANCE_YOUR_CALM”,“code”:13,“metadata”:{},“details”:[],“cause”:{“code”:“ERR_HTTP2_STREAM_ERROR”}}}

While reconnecting, I also encountered this error. Does it have any impact?

7

This is the same issue I described above. NGHTTP2_ENHANCE_YOUR_CALM is the HTTP/2 path failure. The server closes the stream because the worker connection bypasses the proxy and hits a broken route through Clash TUN. So this doesn’t add any separate impact, it’s just a more detailed view of the same error in the logs during the retry loop.

No extra action is needed. It’s all part of the same bug. When we have an update on the fix, we’ll post it here.