Desktop thread can enter persistent conversation-state desync after request_user_input in Default mode

[ramarivera]

What issue are you seeing?

In Codex Desktop (macOS), a conversation can enter a persistent broken state after the assistant tries to call request_user_input while the session is in Default collaboration mode.

Observed behavior in one thread:

• Conversation ID: 019c3526-0054-7052-a09b-281d913fd8f7
• Date: February 6, 2026
• Session transcript: ~/.codex/sessions/2026/02/06/rollout-2026-02-06T23-50-08-019c3526-0054-7052-a09b-281d913fd8f7.jsonl

Relevant symptoms from app logs:

• Turn 1 does not match latest turn for conversation ...
• Received item/started for unknown conversation ...
• Conversation state for ... not found
• Received item/completed for unknown conversation ...
• [ErrorBoundary:LocalConversationPage] error(name=Error)

Example references:

• ~/Library/Logs/com.openai.codex/2026/02/06/codex-desktop-448bd53b-ffae-4e6e-8de1-ff4d3c994da7-54773-t0-i1-230019-0.log:128
• ~/Library/Logs/com.openai.codex/2026/02/06/codex-desktop-448bd53b-ffae-4e6e-8de1-ff4d3c994da7-54773-t0-i1-230019-0.log:162
• ~/Library/Logs/com.openai.codex/2026/02/06/codex-desktop-448bd53b-ffae-4e6e-8de1-ff4d3c994da7-54773-t0-i1-230019-0.log:163
• ~/Library/Logs/com.openai.codex/2026/02/06/codex-desktop-448bd53b-ffae-4e6e-8de1-ff4d3c994da7-54773-t0-i1-230019-0.log:138

Transcript shows the session is in Default mode where request_user_input is unavailable, but the assistant still emits multiple request_user_input calls, and those calls appear unresolved in the transcript.

What steps can reproduce the bug?

1. Start Codex Desktop conversation in Default collaboration mode.
2. Use a prompt that leads the assistant toward structured planning with multiple preference choices.
3. Let the assistant run.
4. In this case, the assistant issued multiple request_user_input calls even though Default mode states this tool is unavailable.
5. Continue interacting/retry/reopen thread.
6. The thread repeatedly falls into conversation-state errors (turn mismatch, unknown conversation, conversation state not found) and LocalConversationPage error boundary.

Prompt from the affected thread (PII already minimal):

so for the codex only instructions, not the main template, I want to add smth like:

Keep your memories about the proejct you are working on in `.codex/MEMORIES.md` ...
I want you to help me prompt it in the right way and susbscribe a structure for the md file ...

What is the expected behavior?

• In Default mode, assistant should not call request_user_input.
• If such a call is attempted, the UI/runtime should fail gracefully and keep thread state valid.
• Conversation should remain usable across retries/reopen/restart, without persistent state desync.

Additional information

• Environment: macOS, Codex Desktop
• Transcript metadata includes cli_version: 0.99.0-alpha.5
• This looked persistent for the same thread ID after restart attempts.
• There are also repeated workspace/git-origin warnings in logs, but the conversation-state failures are the main blocker.

🤖 This content was generated with AI assistance using GPT-5.3 Codex.

[github-actions]

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

• Session/thread crash after model suggests questions #10944

Powered by Codex Action

[vuyelwadr]

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