Codex stopping before goal is complete

Resolved 💬 2 comments Opened May 15, 2026 by halfprice06 Closed Jun 10, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

pro

Which model were you using?

5.5 xhigh

What platform is your computer?

macos

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

_No response_

Codex doctor report

What issue are you seeing?

stopping before goal is complete, acknowledging goal is not complete, but stopping for some other reason

<img width="975" height="736" alt="Image" src="https://github.com/user-attachments/assets/2adc74d9-0901-4192-9353-412793f5fcba" />

What steps can reproduce the bug?

Uploaded thread: 019e21cb-7ecd-7b72-9243-f7ad4f095aab

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

etraut-openai contributor · 3 months ago

Thanks for the bug report.

From the logs, it looks like the thread was deactivated and the goal automatically paused. I'm trying to determine what sequence of events could cause this to happen. The log doesn't contain enough history for me to construct it exactly.

Some background details which may be useful in diagnosing this... Active threads are managed by the core harness and exposed through an "app server" layer. The TUI talks to the app server. One or more clients can connect to an app server and ask for a thread to be loaded. This is what happens when you /resume in the TUI, for example. When a client asks a thread to be loaded, it is implicitly "subscribed" to the thread's events. Any changes to that thread send back update events to the client. When a client is done using a thread, is "unsubscribes". The app server keeps that thread loaded and active for 30 minutes after the last client unsubscribes. At that point, it unloads the thread, and that causes a goal to be paused. That's what I'm seeing in your logs, which is not what I'd expect.

The fact that your screenshot shows "29m" is quite suspicious here and matches up with the 30 min unsubscribe timeout. Could be a coincidence.

Do you happen to recall the sequence of things you did in the TUI that led to this condition? It looks from your log that you created this session a couple of days before you created this goal, so it's not a new session. Did you resume this session shortly before creating the goal?

etraut-openai contributor · 2 months ago

Closing because of lack of response.