I am experiencing persistent disconnects and crashes when using the cursor-agent CLI inside an integrated terminal environment (Orca PTY).
Issue Description
When the CLI enters brief idle periods between steps, the integrated terminal PTY buffer throttles I/O streams. This leads to missing HTTP/2 heartbeats, causing the CLI’s NAL stall detector to trigger LostConnection.
Open cursor-agent CLI inside an integrated terminal (Orca PTY).
Run a prompt and leave the CLI idle for >6 seconds between agent steps.
Observe stream freeze and NAL stall detector triggering LostConnection.
Observe the CLI attempt 3 retries and fail with WritableIterable is closed.
Expected Behavior
The CLI should handle PTY background freezes gracefully with transparent stream reconnection/recovery instead of failing retries and throwing RetriableError: WritableIterable is closed.
Operating System
MacOS
Version Information
cursor-agent CLI 2026.09.23-86fc751
For AI issues: which model did you use?
auto-smart
For AI issues: add Request ID with privacy disabled
624854b2-bb58-433f-ade6-3981283531e2
Additional Information
The issue occurs specifically within Orca’s integrated terminal PTY. Pressing ‘Enter’ manually during a stall forces the PTY buffer to flush and wakes up the stream.
Thanks for flagging this. Based on the code, what you’re describing is plausible. The CLI draws its interface by writing to the terminal. If the host terminal stops reading that output (for example, when an Orca tab is in the background), those writes can pause the CLI process entirely, the connection to our servers goes quiet, and after a few reconnect attempts the turn ends with “WritableIterable is closed”. That would also explain why pressing Enter wakes it back up. I’ve flagged this to the team so the CLI can recover from these pauses instead of giving up.
That said, I haven’t been able to reproduce it so far. When I minimize Orca and come back a while later, the agent is still running and I don’t see the “WritableIterable is closed” error. If you have any more details, such as specific prompts or steps, that would really help us reproduce it.
Thanks for the fast response and for confirming the exact underlying cause!
Here is one more key reproduction detail that makes this 100% reproducible:
Follow-up Prompt Stall: When the agent finishes a step and asks a follow-up question (or sits waiting for input), typing a follow-up prompt and hitting Enter often won’t send the prompt immediately.
Unblocking via Enter: The text just stays stuck in the input stream. Hitting Enter a second time flushes the PTY input/output buffer, forces the command through, and wakes the agent back up.
Tab Switching in Orca: This occurs most frequently after switching tabs in Orca or leaving the prompt idle between steps. The stdout/stdin reader pauses, creating backpressure that blocks both output rendering and new input submission.
This confirms that the PTY reader completely pauses during idle gaps or background tab states in Orca. Having the CLI gracefully unblock/recover from these write pauses will solve it completely.
Hey @Shawn.e, thanks for the extra detail, it helped narrow this down.
We think this is tied to a hook that runs after each agent “thinking” step (the afterAgentThought hook). When one is set up, the turn can finish before the hook reports back, and the CLI then retries a few times and shows “WritableIterable is closed”.
Could you check whether you have any hooks configured?
Look in ~/.cursor/hooks.json and in .cursor/hooks.json inside your project.
Check whether one of them lists afterAgentThought. If your company manages Cursor hooks for you, your admin may have set one up.
As a workaround, removing the afterAgentThought entry (or temporarily renaming hooks.json) should stop the error. If that helps, please let us know, and also tell us roughly how long that hook’s script takes to run.
Hey @Colin , turns out the freezes were just a local issue with my ~/.cursor/hooks.json not handling the CLI well. Renaming it fixed it completely. All good now!