Some resumed sessions fail consistently with stream disconnected before completion, while others remain stable

Open 💬 8 comments Opened Apr 24, 2026 by vzd3v

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.124.0

What subscription do you have?

Pro+ ($200)

Which model were you using?

gpt-5.5

What platform is your computer?

Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-90-generic x86_64)

What terminal emulator and version are you using (if applicable)?

tmux

What issue are you seeing?

Summary

Some Codex sessions work normally for long periods, while others repeatedly fail with:

stream disconnected before completion: An error occurred while processing your request

This does not appear to be random. The failures seem to correlate with the specific project a session is working in and with which sessions I resume via /resume. In other words, some session/project states remain stable, while others become consistently error-prone.

Example error

■ stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID bbc68e3b-9045-45f7-a140-b662ff14e6c4 in your message.

What steps can reproduce the bug?

Work across multiple projects and multiple Codex sessions.
Resume existing sessions via /resume.
Observe that some resumed sessions remain stable.
Observe that other resumed sessions fail repeatedly with stream disconnected before completion.
The same failing sessions tend to keep failing, while the stable ones remain stable.

What is the expected behavior?

Resumed sessions should behave consistently regardless of project/session history.
If a session state is invalid or corrupted, Codex should detect and recover from it instead of repeatedly failing at stream time.
Session stability should not depend on hidden project/session state that persists across resumes.

Additional information

_No response_

View original on GitHub ↗

8 Comments

tijanistyle-alt · 2 months ago

Same

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#18676
#18723
#19386

Powered by Codex Action

Brezn610 · 2 months ago

I use codex extension in curosr, and i met the same problem as you.

etraut-openai contributor · 2 months ago

Please use /feedback after this occurs. This will upload your logs and session details. Then post the thread ID here so we can look up your uploaded details. This will help us diagnose. Thanks!

Brezn610 · 2 months ago

@etraut-openai Thanks — I reproduced the issue again and used /feedback as you asked.
Uploaded thread: 019dbf94-76f1-7e61-9553-6740dbb8f95a
If you need anything else from my side (Cursor version, Codex extension build string, or additional logs), tell me what to attach.

Brezn610 · 2 months ago

@etraut-openai One more note after comparing related issues:

This issue seems closer to #18931 and #19397 than to #19433.

#18931 describes long existing threads opening as a blank panel while short threads load normally in Cursor / VS Code forks, which matches my main symptom.
#19397 describes long threads failing to hydrate after reload, with the UI empty and logs showing Received broadcast but no handler is configured method=thread-stream-state-changed, which also matches my logs.
#19433 may be related at a broader session/resume level, but its failure mode is different: it is a Codex CLI issue with stream disconnected before completion, while my issue happens in the Cursor-hosted Codex extension during thread opening/hydration, before a new prompt is submitted.

The additional logs I see include:

nt.chat.registerChatSessionItemProvider is not a function
Received broadcast but no handler is configured method=thread-stream-state-changed
dropping overload response for connection ConnectionId(0): outbound queue is full

pombredanne · 2 months ago

I have a similar issue that started only since today's switch to gpt-5.5 (from gpt-5.4-pro) all in xhigh and fast FWIW. thread ID 019dc51b-1aef-7b11-9455-7e27ce4cdf07 with OpenAI Codex (v0.125.0) Using high does not change things

pombredanne · 2 months ago

The sessions are stable with 5.4-pro, unstable with 5.5