Codex Desktop threads stuck in “Thinking” and cannot be stopped unless background process is force-killed

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

• #11000
• #12196
• #12017

Powered by Codex Action

Adding a +1 with a reproducible case from my machine. This still happens repeatedly for me when my Mac crashes or I force-close Codex mid-turn.

Environment:

• Codex app: 26.226.940 (build 720)
• Bundled codex CLI: 0.105.0
• macOS 26.2 (Darwin 25.2.0, arm64)

Affected thread:

• codex://threads/019c96d3-ec53-7a90-ab42-b171d31fd6b6
• Session file: ~/.codex/sessions/2026/02/26/rollout-2026-02-26T00-03-16-019c96d3-ec53-7a90-ab42-b171d31fd6b6.jsonl

What I see after restart/resume:

1. Thread resumes with streaming marker set unexpectedly:

• ... maybe_resume_success ... latestTurnStatus=completed markedStreaming=true (log ...-28670-..., line 82)
• later also latestTurnStatus=inProgress markedStreaming=true (log ...-96699-..., line 87)

1. New turn/start appears to succeed, but then the thread enters a desync loop:

• Turn does not match latest turn ... (line 133 and then spam)
• Received item/started for unknown conversation ... (line 203)
• Conversation state not found ... (line 218 and then spam)
• many Received broadcast but no handler is configured method=thread-stream-state-changed

1. Stop/interrupt is effectively unusable while stuck:

• method=turn/interrupt ... durationMs=89304 (and many 78–89s interrupts)

User-visible behavior:

• Thread stays in permanent “Thinking / Running requests”.
• Stop button does nothing or responds very late.
• Sending a new message in that thread just keeps thinking.
• New thread usually works; the stuck thread stays poisoned.

Current workaround:

• Force-kill Codex background process, then continue in a new thread.
• The original thread still often remains visually stuck forever.

If helpful, I can share the full relevant log files privately:

• ~/Library/Logs/com.openai.codex/2026/02/26/codex-desktop-6e191a37-5dbc-4777-8a2e-2f3f81c32b7c-28670-t0-i1-115819-0.log
• ~/Library/Logs/com.openai.codex/2026/02/26/codex-desktop-91c2e41e-637c-46ea-8807-98b7686262eb-96699-t0-i1-150449-0.log

Same problem. I have 2 threads stuck in thinking for over an hour each and I'm not able to stop them. I use MacOS Version: 26.226.940 (720).
Session ids: 019c9604-3b30-7060-b896-62fdb66c89b6, 019c9d84-c887-7121-93bb-62fb79f133bf

Same issue here.
Codex keeps thinking even if you restart the laptop.
But I found a workaround here

In following steps:

1. found the seesion save in your machine something like ~/.codex/sessions/2026/02/06/rollout-2026-02-06T15-48-22-019c31ec-6944-7d40-b369-4b917df0285c.jsonl
2. Find the last line with "type": "task_complete" from the end of the file, delete all lines below it, and save the file.
3. Reopen Codex and enter this session. You will see that "Thinking" is gone, and you can now input new commands normally.

Be careful to delete the lines if there are import data you want to save.

Same problem here, @counter2015's workaround doesn't seem to help me.

I had to archive the thread, that was the only thing that worked for me.

Another concrete macOS data point for this same “stuck in Thinking” family of bugs.

Environment:

• Codex App: 26.305.950 (build 863)
• macOS: 26.3.1 (25D2128)

Affected session IDs:

• 019cc156-9030-71b0-b9ab-4b0e18a674ae
• 019cb20c-c2df-7301-a298-7430070cb1c6

What I verified locally:

1. Session 019cc156-9030-71b0-b9ab-4b0e18a674ae

• Transcript file only has 8 lines total.
• It stops right after task_started + the user message.
• There is no assistant output, no tool call, and no completion event.
• In other words, the turn appears to have been created, but never actually progressed.

1. Session 019cb20c-c2df-7301-a298-7430070cb1c6

• This thread had many earlier successful turns.
• But on the newest turn (user message timestamp 2026-03-06T04:10:05Z), the transcript again stops immediately after the user_message event.
• No assistant/tool/completion events were recorded for that turn.
• So the old thread itself was not always broken; the latest resumed turn failed very early.

Related local log signal:

• ~/.codex/log/codex-tui.log contains repeated stream disconnected - retrying sampling request entries around this general period.
• I did not find the exact earlier failed to connect to websocket ... Operation timed out signature for these two IDs, so this may be a slightly different transport/resume-state failure mode.

Why this seems useful:

• In both cases, this does not look like “the model is just thinking for a long time”.
• The recorder only got as far as user_message, and then the turn never attached to normal downstream events.
• One case is a newly created thread; the other is a resumed existing thread.

If helpful, I can provide the exact local transcript file names that correspond to these two session IDs, but the session IDs alone may already be enough to correlate backend logs.

Same issue with session id :
019ccf1e-34fb-7040-9322-f6949d5a8fd5
019cc276-cf57-7f41-9241-3dcf756816e6

The most annoing part is that in the app there is even no /feedback command available to get the thread id at least. Have to get into the cli, /resume the session to get the id from /status afterwards.
019cc6dc-35db-76a1-ba58-8fb692abb216

same issues if the app crashed or closes while its still working and re open the app it just loops thinking cant stop it can send a message to steer it nothing works to make it stop so now my thread and convo is in garbage loop 019cca6d-c427-7980-953c-2f9217fe5916

A fix is rolling out in pre-release now and will be fully released later today (March 11)

the issue is still occurring its still thinking etc codex://threads/019cca6d-c427-7980-953c-2f9217fe5916

The release is still rolling out. The fix is in [26.309.31024](<https://github.com/openai/openai/actions/runs/22968072391/artifacts/5877000740>)

I have downloaded the latest Codex desktop app and this has solved it for me