CLI stall detector never fires after tools complete: grok-4.6 stream stays on heartbeats for 30–83 min (stallAborted=false)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Two consecutive turns in the same Cursor CLI session hung after local tools had already finished. The UI stayed on Working. The stream kept exchanging heartbeats only: no model text, no new tools, no turnEnded.

The client’s heartbeat-only stall watchdog never fired (stallAborted=false) because inbound server heartbeats are counted as meaningful activity. This is not a dead TCP connection.

Hang 1: ~30 minutes until I submitted a new message (new_message_submitted; not retried).
Hang 2: ~83 minutes of heartbeats-only, then HTTP/2 CANCEL (0x8); client retried as a transport error and resume succeeded.

Hung process: cursor-agent 2026.08.25-3e8eec8. Same heartbeat handling is in installed 2026.09.15-d2fe57e, so updating the CLI does not fix this. Model: grok-4.6.

Steps to Reproduce

Not a one-click repro. Happened twice in one interactive CLI session on grok-4.6 after a tool round completed:

  1. Run cursor-agent on macOS, model grok-4.6.
  2. Local shell/read tools complete (afterShellExecution / postToolUse return).
  3. After that, the stream only receives heartbeat. UI stays Working.
  4. Hang 1: wait ~30 min, then submit a new user message; abort with stallAborted=false, Error not retryable.
  5. Hang 2: wait ~83 min, then ConnectError: http/2 stream closed CANCEL (0x8), Stream ended without turnEnded. Client resumeAction recovered.

Expected Behavior

If the server sends only heartbeats and no tokens/tools, the heartbeat-only stall detector should abort and retry after about 90s (3x the default 30s fail timeout). The user should not have to wait tens of minutes or interrupt by hand.

Fix: on heartbeat, reset(“inbound_message”, “heartbeat”, false) so heartbeats are not treated as meaningful activity.

Operating System

MacOS

Version Information

cursor-agent 2026.08.25-3e8eec8 (process that hung)
Also checked 2026.09.15-d2fe57e: same heartbeat reset() default
macOS 15.7.7 arm64

For AI issues: which model did you use?

grok-4.6

For AI issues: add Request ID with privacy disabled

Conversation: c2e187ea-59e6-4421-a2c7-498a45932493
Hang 1: 1668608b-69cc-4f15-b6bc-9c605adbd5e9
Hang 2: ba275f9c-825c-4853-aca2-40c839f753dc
Resume of hang 2: c41a111c-c2ec-4a2d-9ad0-39a7a425e67e

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @Zane_Z, thanks for the detailed report.

You’ve read the heartbeat handling correctly: right now a server heartbeat also resets the “meaningful activity” timer, so the heartbeat-only watchdog never trips, and a turn where the server stops making progress after a tool round can sit on Working until you interrupt it. This is a known issue we’re already tracking, and I’ve added your report.

A first fix had to be pulled back because it also aborted turns that were legitimately waiting on the client side (a shell command running quietly for a while, or an approval prompt left open). The version now in progress keeps the ~90s backstop but holds it while a local tool or prompt is outstanding.

There isn’t a setting that turns the backstop on in the meantime. If a turn goes quiet like this, sending a new message or pressing Ctrl+C and resuming is the fastest way out, and the checkpoint resume you saw on the second hang is the expected recovery path.

One thing that would help if it happens again: which tool ran last before the stream went heartbeat-only (shell, read, or a file edit), and whether you have hooks configured for that tool. We’re separately looking at why the server sometimes stops after a completed local tool result, and that detail narrows it down.