›_ Codex Issues
Codex Issues / #10952

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

Open 💬 2 comments Opened Feb 6, 2026 by ramarivera
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 6 months ago

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

  • #10944

Powered by Codex Action

vuyelwadr · 6 months ago

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