[Windows][26.908.40834] ChatGPT Work stuck in “Reconnecting… waiting for network” despite successful thread/start and turn/start #45099

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

26.908.40834

What subscription do you have?

ChatGPT Plus

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $([Environment]::Is64BitOperatingSystem ? 'x64' : 'x86')"

What issue are you seeing?

Summary

ChatGPT Work is consistently unusable in the Windows Codex/ChatGPT desktop app after a recent desktop app update and Windows update.

Normal ChatGPT conversations continue to work in the same application and on the same network, but ChatGPT Work tasks — including brand-new trivial tasks such as test — enter a repeated:

Reconnecting... waiting for network
Reconnecting 1/5
...
Reconnecting 5/5

loop and fail to complete.

A complete uninstall/reinstall of the desktop app did not resolve the issue.

The internal desktop logs strongly suggest this is not a general network failure. The Work thread and turn both start successfully, but the renderer subsequently loses synchronization with the conversation state.

Reproduction

1. Open the Windows Codex/ChatGPT desktop app.
2. Start a new ChatGPT Work task.
3. Enter a trivial prompt such as:
   test
4. The Work session initializes.
5. The UI enters repeated:
   Reconnecting... waiting for network
6. The task remains stuck.

Reproduction rate is effectively 100%.

Expected behavior

The new Work conversation should initialize and execute normally.

If a renderer/conversation synchronization issue occurs, the client should recover or rehydrate the thread state instead of displaying a network reconnect loop.

Actual behavior

The backend/app-server appears to successfully create the Work thread and start the turn, but the desktop renderer subsequently reports lifecycle events for an unknown conversation.

Key log evidence

The Work/browser-use backend starts successfully:

browser_use_iab_backend_startup_started
platform=win32
release=26.908.40834

followed by:

browser_use_iab_backend_startup_ready

The new Work conversation is successfully created:

Conversation created
threadStartKind=default

The actual model turn also starts successfully:

method=turn/start
durationMs=48
errorCode=null

This suggests the request is successfully reaching the local app-server and is not failing at initial network connectivity.

However, model/list repeatedly reaches the desktop client's hard timeout:

mcp_request_timeout
method=model/list
timeoutMs=4999

The response arrives only milliseconds later:

method=model/list
durationMs=5009
errorCode=null

but the renderer has already discarded the pending request and logs:

No promise for request ID

Immediately afterward, the renderer logs:

Received turn/started for unknown conversation

This occurs in both renderer contexts.

That sequence appears consistent with a conversation-state / renderer synchronization race rather than a genuine loss of network connectivity.

Additional DeviceCheck behavior

During the failed Work turn the app repeatedly logs:

DeviceCheck attestation unavailable
deviceCheckLatencyMs=null
durationMs=0
errorCode=1

This occurs multiple times during the failed initialization sequence.

I do not know whether this is causal or secondary, but it consistently occurs during the failure.

Pub/Sub behavior

The log also showed one:

chatgpt_pubsub_transport_closed

followed by:

chatgpt_pubsub_reconnect_scheduled

but the transport successfully reopened several seconds later:

chatgpt_pubsub_transport_opened

and resubscribed successfully.

This does not appear to explain the persistent Work failure.

Network diagnostics already completed

The following have been tested successfully:

• chatgpt.com:443 reachable
• ws.chatgpt.com:443 reachable
• DNS resolution succeeds
• TLS/Schannel negotiation succeeds
• IPv4 reaches OpenAI
• IPv6 reaches OpenAI
• POST https://chatgpt.com/backend-api/codex/responses returns 401 Unauthorized when called without authentication, confirming the backend route is reachable
• No WinHTTP proxy configured
• Windows user proxy disabled
• No PROXY / OPENAI / CODEX environment variable overrides detected

A bare WebSocket test reaches wss://chatgpt.com/ and receives HTTP 403 rather than timing out or failing TLS, indicating the host is reachable even though the unauthenticated synthetic WebSocket handshake is rejected.

Troubleshooting already attempted

• New Work thread
• Existing Work threads
• Trivial Work prompt (test)
• Full app restart
• Complete uninstall and reinstall
• TCP connectivity tests
• DNS tests
• TLS/Schannel tests
• WebSocket endpoint reachability tests
• IPv4 tests
• IPv6 tests
• Codex backend connectivity test
• Windows proxy inspection
• Environment variable inspection

Normal ChatGPT continues to work throughout.

Suspected failure boundary

The logs suggest a failure in the desktop renderer/state lifecycle around:

thread/start
→ conversation creation
→ turn/start
→ renderer conversation registration
→ incoming turn/started

The backend/app-server successfully starts the thread and turn, but the renderer subsequently receives:

Received turn/started for unknown conversation

The ~5 second model/list timeout may be contributing to the race because responses repeatedly arrive a few milliseconds after the 4999 ms timeout and are then discarded with:

No promise for request ID

Requested investigation

Please investigate desktop release 26.908.40834 for a regression involving:

• Work thread creation / renderer hydration ordering
• handling of turn/started for conversations not yet registered by the renderer
• model/list 4999 ms timeout behavior
• No promise for request ID after late responses
• repeated Windows DeviceCheck attestation failures
• mapping renderer/conversation-state failures to the misleading Reconnecting... waiting for network UI

A likely client-side improvement would be to buffer/reconcile turn/started events for conversations that have not yet finished renderer hydration instead of dropping them or treating them as transport failures.

I can provide full sanitized logs if needed.

What steps can reproduce the bug?

1. Open the Windows ChatGPT/Codex desktop app.
2. Start a brand-new ChatGPT Work task.
3. Enter a trivial prompt such as:
   test
4. Wait for the Work session to initialize.
5. The UI enters:
   Reconnecting... waiting for network
   and cycles through retry attempts such as 1/5 through 5/5.
6. The Work task remains stuck and does not complete.
7. Repeat with another new Work thread. The issue reproduces consistently.

The internal logs show that the Work request itself successfully progresses through thread creation and turn start:

method=thread/start
errorCode=null

followed by:

method=turn/start
errorCode=null

However, immediately around this process, model/list repeatedly hits the desktop client's hard timeout:

mcp_request_timeout
method=model/list
timeoutMs=4999

The response arrives only milliseconds later, for example:

method=model/list
durationMs=5009
errorCode=null

but the renderer has already discarded the pending request and logs:

No promise for request ID

Shortly afterward the renderer logs:

Received turn/started for unknown conversation

This occurs in both renderer contexts.

The same failed Work attempt also repeatedly logs:

DeviceCheck attestation unavailable
deviceCheckLatencyMs=null
durationMs=0
errorCode=1

No session ID, token limit issue, or context-window saturation is involved. The bug reproduces with a brand-new thread and a one-word prompt.

The same failed turn also repeatedly logs:
DeviceCheck attestation unavailable
deviceCheckLatencyMs=null
durationMs=0
errorCode=1

What is the expected behavior?

A new ChatGPT Work conversation should initialize normally and execute the requested turn.

After `thread/start` and `turn/start` succeed, the renderer should correctly associate subsequent `turn/started` events with the newly created conversation.

If conversation hydration or renderer registration is delayed, the client should buffer or reconcile the incoming turn event rather than discard it.

The UI should only show `Reconnecting... waiting for network` for an actual transport/network problem, not for an internal conversation-state synchronization failure.

### Additional information

This appears to be a desktop-client state/race regression rather than a general connectivity failure.

Network checks already completed successfully:

- `chatgpt.com:443` reachable
- `ws.chatgpt.com:443` reachable
- DNS resolution succeeds
- TLS/Schannel succeeds
- IPv4 connectivity succeeds
- IPv6 connectivity succeeds
- `POST https://chatgpt.com/backend-api/codex/responses` reaches OpenAI and returns the expected unauthenticated `401 Unauthorized`
- No WinHTTP proxy configured
- Windows user proxy disabled
- No `PROXY`, `OPENAI`, or `CODEX` environment-variable overrides detected

The desktop logs show that Work successfully reaches both `thread/start` and `turn/start` with `errorCode=null`.

The most suspicious sequence is that `model/list` repeatedly takes just over the application's 4999 ms timeout. The renderer times out first, then receives the successful response a few milliseconds later and logs:

`No promise for request ID`

Shortly afterward it logs:

`Received turn/started for unknown conversation`

This suggests a race between conversation creation/hydration and the arrival of turn lifecycle events.

There are also repeated:

`DeviceCheck attestation unavailable ... errorCode=1`

messages during the failed Work turn. This may be related or contributory.

A brief ChatGPT pub/sub disconnect was also observed, but it automatically reconnected, resubscribed, and fetched missed messages successfully, so it does not appear to explain the persistent failure.

Troubleshooting already attempted:

- Brand-new Work threads
- Existing Work threads
- Trivial prompts
- Full app restart
- Complete uninstall/reinstall
- DNS tests
- TCP 443 tests
- TLS/Schannel tests
- WebSocket endpoint reachability tests
- IPv4 tests
- IPv6 tests
- Codex backend reachability test
- Proxy inspection
- Environment-variable inspection

Normal ChatGPT remains functional throughout.

The failure began immediately after a recent Windows update and Codex/ChatGPT desktop app update.

I can provide full sanitized logs if useful.