Windows Desktop: immediate submit after opening a stored thread can show Error submitting message #30710

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

Codex Desktop Windows app package: OpenAI.Codex 26.623.9142.0.

Bundled CLI/core visible from the installed Codex runtime: codex-cli 0.130.0-alpha.5.

What subscription do you have?

ChatGPT Pro ($100 plan).

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64, Codex Desktop app.

What issue are you seeing?

Tags: app, app-server, session, windows-os, Desktop, turn/start, thread/resume, notLoaded, Error submitting message.

When reopening a long/stored Desktop thread on Windows and submitting a prompt immediately, the composer can fail with "Error submitting message". Fully restarting Codex Desktop clears the condition.

This appears to be a narrower race than the generic sidecar stall reports: the thread exists on disk, but the runtime may still be in a stored/not-loaded state when the Desktop client sends turn/start.

What steps can reproduce the bug?

1. Use Codex Desktop on Windows with an existing long/stored thread that is not currently loaded in the app-server runtime.
2. Open the thread.
3. Immediately submit a prompt before the thread visibly finishes loading/resuming.
4. Observe that the composer can show "Error submitting message".
5. Quit/restart Codex Desktop.
6. Reopen the same thread and submit again; the failure can clear after restart.

Observed pattern:

• the thread is still readable/alive,
• restart clears the submit failure,
• the failure is most likely at the turn/start vs thread/resume boundary rather than model/provider execution.

What is the expected behavior?

Desktop should not submit turn/start against a stored-but-not-yet-loaded thread without a recoverable path.

Expected behavior could be one of:

• disable or queue composer submit until thread/resume completes,
• call/wait for thread/resume before turn/start, or
• receive a structured app-server error that lets the client retry after resume instead of showing generic "Error submitting message".

Additional information

Related issues:

• Desktop: "Error submitting message" — turn/start times out (30s) while app-server sidecar stalls silently for minutes #27395 is closely related because it covers Desktop "Error submitting message" around turn/start and app-server sidecar behavior.
• Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it #23644 is closely related because restart clears stale conversation/session state.
• Windows app: opening a modified local file interrupts the active turn #30704 is related only as a broader Windows Desktop live-state issue; its direct symptom is active-turn interruption from opening a local file, so it does not look like the primary duplicate.

I also posted a detailed analysis and patch outline on #27395:
#27395 (comment)

Root-cause hypothesis from the public app-server code:

TurnRequestProcessor::load_thread resolves a thread id and then calls thread_manager.get_thread(thread_id). For turn/start, if Desktop races ahead before thread/resume has loaded the stored thread into the runtime, the app-server can return an unstructured thread not found-style failure even though the rollout exists on disk.

A small contract improvement would be to return a structured retryable invalid-request error for this boundary, for example:

{
  "code": -32600,
  "message": "thread not loaded or not found: <thread_id>; call thread/resume and wait for it to complete before turn/start",
  "data": {
    "thread_error_code": "thread_not_loaded",
    "retry_method": "thread/resume",
    "blocked_method": "turn/start"
  }
}

That would give Desktop a precise signal to wait/retry after resume instead of surfacing a generic composer error.

Potential test coverage:

1. create a fake stored rollout,
2. start app-server without calling thread/resume,
3. send turn/start for that stored thread id,
4. assert the full JSON-RPC error object includes thread_error_code=thread_not_loaded, retry_method=thread/resume, and blocked_method=turn/start.

Per docs/contributing.md, external code PRs are invitation-only. I am opening this as a bug report with reproduction details and a high-level fix outline rather than an unsolicited PR.