# CLI stall detector never fires after tools complete: grok-4.6 stream stays on heartbeats for 30–83 min (stallAborted=false) **URL:** \ **Category:** Bug Reports\ **Tags:** cli, grok, networking\ **Created:** [September 17, 2026, 12:01pm UTC](https://forum.cursor.com/t/cli-stall-detector-never-fires-after-tools-complete-grok-4-6-stream-stays-on-heartbeats-for-30-83-min-stallaborted-false/172019 "2026-09-17T12:01:57Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Zane\_Z](https://avatars.discourse-cdn.com/v4/letter/z/cab0a1/32.png) [@Zane\_Z](https://forum.cursor.com/u/Zane_Z)\ **Post date:** [September 17, 2026, 12:01pm UTC](https://forum.cursor.com/t/cli-stall-detector-never-fires-after-tools-complete-grok-4-6-stream-stays-on-heartbeats-for-30-83-min-stallaborted-false/172019/1 "2026-09-17T12:01:57Z")
### 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 ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [September 17, 2026, 12:26pm UTC](https://forum.cursor.com/t/cli-stall-detector-never-fires-after-tools-complete-grok-4-6-stream-stays-on-heartbeats-for-30-83-min-stallaborted-false/172019/6 "2026-09-17T12:26:45Z")
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.