Cursor-cli error WritableIterable is closed

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Error: Something went wrong. Please try again.
WritableIterable is closed

â­âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ®
â â
â About Cursor CLI â
â â
â CLI Version 2026.07.09-a3815c0 â
â Model Auto â
â OS linux (x64) â
â Terminal unknown â
â Shell bash â

Steps to Reproduce

I don’t know. I had it working for about 12 o 14 hours until this error happened.
I was using “auto” as model. Not sure how useful is this.

Operating System

Linux

Version Information

cursor-agent about

About Cursor CLI

CLI Version 2026.07.09-a3815c0
Model Auto
Subscription Tier Team
OS linux (x64)
Terminal unknown
Shell bash

OS debian 11.11 amd64

For AI issues: which model did you use?

auto

For AI issues: add Request ID with privacy disabled

â Last Request ID 9aa7cbe4-8612-42af-9a0a-e3037685a54c â

Conversation id 2fd873ae-5ddd-4774-a187-600840b301b5

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the report with full details. The reqId and conversation id really helped.

Good news: based on the logs, this error on our side did not cause any data loss. The backend handled the whole request cleanly, and all inference calls succeeded. WritableIterable is closed is a transient stream teardown on the client side that can sometimes show up after very long sessions. In your case it was about 12 to 14 hours of continuous use. The CLI shows a generic Something went wrong instead of a clearer retryable message.

What to do: just rerun the request, or resume the session with cursor-agent resume. No reconfiguration is needed.

This is a known bug and we are tracking it. I can’t share an exact fix timeline, but it’s a one-off transient issue, not a permanent break. If it starts happening regularly, not once every many hours but often, message here and we’ll take a closer look.

7

@dean Hi,

I also poisoned a session somehow, and now face the WritableIterable is closed error constantly on /btw

The bad state persists after exit and --resume.

It doesn’t happen on a fresh session.

Copied request id 84fe5164-864e-48cd-b5ef-39b8f329bb17

$ agent --version
2026.07.16-899851b

iTerm2 2026-07-17 13.36.01
iTerm2 2026-07-17 13.36.01452×198 8.7 KB

8

Hey, thanks for the report. Your case is different from the original one in this thread. In that thread the error was transient, it happened once after a long session and was fixed by resume or retry. In your case it is persistent. The session got into a bad state, the error repeats on /btw and still happens after exit and --resume, while a fresh session works fine.

You already found a quick workaround, start a new session. Sadly, it is probably not possible to recover the specific corrupted session, its state was saved locally in a broken form.

To help us find the bug, can you share a couple details?

  • What were you doing right before the session broke? Crash, cancel, network drop, killing the process, anything like that. Any pattern helps.
  • Does the error happen only on /btw, or also on normal prompts in that session?
  • Your OS.

One more request. So this persistent variant does not get mixed with the original transient bug, please start a separate thread for it. You can paste the same details there. That makes it easier to track separately.

9

This has become a frequent issue for me on macOS (25.6.0) & Debian (6.12.74+deb13+1-cloud-arm64) using cursor-cli (2026.07.23-e383d2b) with a Teams subscription & usually following a background task or subagent that seems to get abandoned.

10

Hey, thanks for the report. What you’re describing is a different case, not the transient one this thread started with. For the original author, the error showed up once after a long session and was fixed by resume or retry. In your case (same as @erich-clickup above) it’s persistent: the session gets into a bad state, the error repeats on /btw, and it survives exit and --resume. From what you said, it happens after a background task or subagent gets stuck, that’s a helpful clue.

The quick workaround is the same: start a new session. Sadly, you probably can’t recover the specific broken session since its state is already saved locally in a corrupted form.

So we don’t mix this persistent variant with the original transient bug, please start a separate thread for it (you can copy your details there). It’ll be easier to track separately. In that new thread, please also add:

  • The Request ID from the session where the error reliably repeats (Privacy Mode needs to be off).
  • Does the error happen only on /btw, or also on normal prompts in the same session?
  • What exactly the agent was doing right before it broke, what background task or subagent it was, and how it got lost (did it hang by itself, did you cancel it, did the process crash, did the network drop)?

Let me know once you’ve created the thread and we’ll jump in.