[Windows desktop] Goal chat remains active but Stop/Continue fail with thread_not_found while thread/read succeeds

Environment

• Windows 11, build 10.0.26200, AMD64.
• Installed desktop MSIX package: OpenAI.Codex_26.908.4834.0_x64 (from the installed package path; About-dialog version was not captured).
• Bundled app-server version reported in the desktop log: 0.154.0-alpha.6.2.
• A long-running local Goal task with multiple continuations.
• Incident observed on 2026-09-13; log window below is UTC (local time UTC+05:30).

User-visible issue

The user reports that the backend stopped responding for the active chat, while the chat window continued to appear active, and they could not forcefully close/stop the chat through the app. The exact close control used was not captured.

The logs independently confirm that the same visible task could still be read, but repeated turn/start and turn/interrupt requests failed with JSON-RPC -32600 and failureReason=thread_not_found. This is therefore a loss of task control/state consistency, not just a long-running model call.

Redacted diagnostic timeline

Every below refers to the same thread. These are reduced field extracts from the desktop log; raw logs and the full conversation are not attached.

Representative failure:

2026-09-13T09:54:15.084Z error [electron-message-handler] Request failed
conversationId=<affected-thread> durationMs=4
error={"code":-32600,"message":"thread not found: <affected-thread>"}
failureReason=thread_not_found method=turn/interrupt
pendingCountAfter=0 priority=critical queueWaitMs=0
rendererWindowAppearance=primary rendererWindowFocused=true
rendererWindowVisible=true source=turn timeoutMs=0

A new desktop launch is logged at 10:00:22 UTC, and a local app-server connection is recorded as connected at 10:00:25.156 UTC. The affected rollout file still exists locally and the conversation subsequently became usable. This does not establish the exact user recovery action or the root cause.

Observed sequence / reproduction status

1. Work in a long-running local Goal task with repeated continuations.
2. The user encounters an apparent backend/non-progress state while the chat UI continues to appear active.
3. Attempts to stop the task fail; attempts to start/continue the same task also fail.
4. Desktop logs show successful thread/read interleaved with failed turn/start and turn/interrupt for the same ID.

This is an observed incident, not a deterministic reproduction. I have not deliberately recreated a freeze or changed internal databases to test it. The logs show responses from the app-server; they do not prove a total backend crash, a network outage, or ongoing model execution after a stop request.

Expected behavior

• Reconcile the visible running state with the actual loaded/active task state.
• Stop should interrupt the actual active task, or clearly report that it is already stopped/unloaded and offer recovery.
• A task that remains readable should not stay trapped behind failed start/interrupt operations without a usable recovery path.
• Closing/stopping a task should remain usable when the backend task state is missing.

Impact and related reports

The user lost a dependable way to distinguish progress from a stuck state and to stop the chat. Additional billing/quota impact was not established.

Possibly related: #42604 (Goal history/state desync and failed interrupt on macOS) and #45187 (Windows desktop resumed-chat state problems in the same package generation). This report adds a Windows incident with successful thread/read calls interleaved with failed start and interrupt. No shared root cause is asserted.

Only the redacted diagnostic details above are included. No project source, prompts, credentials, local usernames, full thread IDs or raw diagnostic archive is being published.

No source files or tests are named. Start at the desktop electron-message-handler paths for thread/read, turn/start, and turn/interrupt, then reproduce or instrument the state transition that permits reads while control operations return thread_not_found. Done means the visible task state is reconciled and stop or recovery remains usable when the task is missing.