Skip to content

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

Closed
Closed
Codex Desktop threads stuck in “Thinking” and cannot be stopped unless background process is force-killed#12852
Labels
appIssues related to the Codex desktop appbugSomething isn't working

Description

@Upper-Hank
Upper-Hank
opened on Feb 26, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.224.1209

What subscription do you have?

Business

What platform is your computer?

Darwin 24.5.0 arm64 arm

What issue are you seeing?

I encountered an issue where two existing threads were stuck in a permanent “Thinking” state.

Restarting the application did not fix the issue. Clicking the “Stop” button had no effect. Trying to insert new prompts into the same threads also resulted in infinite “Thinking”.

But creating a completely new thread worked normally. The model responded without any issues.

The issue was only resolved after force-killing the background Codex process using:

ps aux | grep codex
kill -9 <PID>

After force-killing the process:
• The “Stop” button disappeared
• The input arrow became available again
• New prompts could be added to the affected threads
• The model responded normally
• The original stuck message still visually shows “Thinking” indefinitely

Image

What steps can reproduce the bug?

Session id: 019c9747-e085-72f3-9168-878dc58fe99b & 019c9785-e8b9-77b3-821a-834bb88e139d

What is the expected behavior?

No response

Additional information

No response

Activity

  1. Upper-Hank
    added
    appIssues related to the Codex desktop app
    on Feb 26, 2026
  2. github-actions
    added
    bugSomething isn't working
    on Feb 26, 2026

  3. github-actions commented on Feb 26, 2026

    @github-actions
    github-actionsBot
    on Feb 26, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. vuyelwadr commented on Feb 26, 2026

    @vuyelwadr
    vuyelwadr
    on Feb 26, 2026

    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)
    2. 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
    3. 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

  5. emrebalak commented on Feb 27, 2026

    @emrebalak
    emrebalak
    on Feb 27, 2026

    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

  6. counter2015 commented on Feb 28, 2026

    @counter2015
    counter2015
    on Feb 28, 2026

    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.

  7. johanhaleby commented on Mar 2, 2026

    @johanhaleby
    johanhaleby
    on Mar 2, 2026

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

  8. johanhaleby commented on Mar 3, 2026

    @johanhaleby
    johanhaleby
    on Mar 3, 2026

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

  9. Astro-Han commented on Mar 6, 2026

    @Astro-Han
    Astro-Han
    on Mar 6, 2026

    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.

    2. 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.

  10. neech commented on Mar 8, 2026

    @neech
    neech
    on Mar 8, 2026

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

  11. nos1609 commented on Mar 9, 2026

    @nos1609
    nos1609
    on Mar 9, 2026

    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

  12. vgcman16 commented on Mar 9, 2026

    @vgcman16
    vgcman16
    on Mar 9, 2026

    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

  13. gpeal commented on Mar 11, 2026

    @gpeal
    gpeal
    on Mar 11, 2026
    Contributor

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

  14. gpeal
    closed this as completedon Mar 11, 2026

  15. vgcman16 commented on Mar 11, 2026

    @vgcman16
    vgcman16
    on Mar 11, 2026

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

  16. gpeal commented on Mar 11, 2026

    @gpeal
    gpeal
    on Mar 11, 2026 – with Linear
    Contributor

    The release is still rolling out. The fix is in 26.309.31024

  17. CodingSitePhobic commented on Mar 12, 2026

    @CodingSitePhobic
    CodingSitePhobic
    on Mar 12, 2026

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions