Remote Windows task becomes conversation_inaccessible while host app-server remains alive

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

• Coordinating Mac: ChatGPT/Codex app 26.825.51511 (bundle 7377)
• Windows remote host: OpenAI.Codex 26.825.6671.0
• Bundled Codex/app-server on both: 0.151.0-alpha.7.2

What subscription do you have?

Paid ChatGPT subscription; the exact tier is not exposed to this diagnostic task.

What platform is your computer?

• macOS 27.0 (26A5421a)
• Microsoft Windows NT 10.0.26220.0, x64 OS/x64 process

What issue are you seeing?

A Codex task running on a paired Windows host repeatedly becomes inaccessible from the coordinating Mac even though the Windows Codex process, local app-server, network, and host remain continuously available.

The Mac app log reports remote control app-server stream sequence gap detected (code 4000). The Windows log independently records the coordinating task becoming inaccessible:

2026-08-31T00:52:45.210Z thread not loaded: <redacted-id>
2026-08-31T00:52:45.711Z HTTP 404; errorCode=conversation_inaccessible; can_retry=false

The same thread not loaded / conversation_inaccessible pair recurred around 03:07 and 04:09 UTC. Mac-side stream gaps recurred around 01:07, 02:13, 02:45, 03:18, and 04:05 UTC.

The Windows package was Status Ok, and one Windows Codex process remained alive for the entire period. There were no matching Windows crash, renderer-failure, sleep/resume, network-loss, authentication, HTTP 429, WebSocket, or timeout events. The only actual app-server disconnect happened later during an intentional package update/restart.

This makes the failures appear to be a backend control-plane/task-routing or Remote stream-recovery problem rather than host availability.

What steps can reproduce the bug?

1. Pair a Mac and Windows PC for Codex Remote under the same account/workspace.
2. Start or continue a long-running Codex task on the Windows host from the Mac.
3. Leave both apps running and both hosts awake and online.
4. Continue coordinating the task over several hours.
5. Intermittently, the Windows host/task becomes unavailable from the Mac. Retrying task/list/read operations may time out or return thread not loaded / conversation_inaccessible, even though the Windows process and app-server remain alive.
6. Quitting and reopening the Windows app restores access.

This is intermittent but occurred five times in one continuous session.

What is the expected behavior?

Remote stream gaps should recover without making an otherwise live task inaccessible. If a stream cursor must be reset, the Mac should transparently reload the task from the live Windows app-server instead of returning a non-retryable conversation_inaccessible response.

Additional information

• Both apps were current at the time of diagnosis.
• The previous Windows package version was neither registered nor running; references to it existed only in stale stored workspace paths.
• The evidence above is deliberately sanitized. Raw logs were reviewed locally and are not attached because they contain local paths and task identifiers.

Begin with the remote stream sequence-gap recovery and conversation_inaccessible/thread-not-loaded handling described in the Mac and Windows logs; no source files or tests are named. Reproduce the paired-host scenario over several hours, trace the task reload path, and verify that a live Windows app-server recovers access after a stream gap without a non-retryable error.