Bug Report: Chat messages intermittently fail to send because the in-app browser route is unavailable

Summary

Chat inside the OpenAI Codex/ChatGPT Windows desktop app intermittently appears frozen or unresponsive.

When the issue occurs, the message remains in the composer and is never submitted. Sending the same message again after the in-app browser route recovers works normally. This indicates that the model or ChatGPT backend is not hanging; the desktop app is losing the message before submission.

Local application logs repeatedly report:

No ChatGPT browser route is available for browser session

The evidence points to a race condition in the in-app browser (IAB) session-routing lifecycle.

Environment

• OS: Windows
• Application package: OpenAI.Codex
• Executable process: ChatGPT.exe
• Package builds observed in affected logs:
  • 26.901.6511.0
  • 26.903.8094.0
• Chat surface: embedded ChatGPT Chat in the Windows desktop app
• Multiple Codex tasks may be active concurrently
• The failure also occurs without MCP tools, plugins, or local connectors

User-visible behavior

1. A prompt is entered in Chat.
2. The Send button is clicked.
3. No response begins.
4. The prompt sometimes remains in the composer as an unsent draft.
5. There is no visible error explaining that submission failed.
6. Retrying later may send the same prompt successfully.
7. Once submission succeeds, ChatGPT responds normally in approximately 10 seconds.

Expected behavior

Clicking Send should either:

• submit the message exactly once, or
• display a clear error and preserve the draft if submission is impossible.

The app should not silently discard or delay the Send action because an internal browser route is temporarily unavailable.

Actual behavior

The app attempts to access the browser session before a valid route/listener has been registered.

Repeated log entry:

[browser-use-iab-api] IAB_LIFECYCLE iab backend info request failed
errorMessage="No ChatGPT browser route is available for browser session <conversation-id>"
request=getInfo

In affected sequences, the route is registered only after the failed requests. Logs show the following lifecycle pattern:

No ChatGPT browser route is available
created browser use host
syncing browser use active state
registered debugger listener

The browser-use host may be created using a transient identifier such as:

client-new-thread:<uuid>

while the failing request uses the durable Codex conversation ID. This suggests a temporary identity/rebinding mismatch.

Quantitative evidence from one affected application run

• Missing ChatGPT browser-route errors: 585
• ResizeObserver loop completed with undelivered notifications: 3,334
• Browser-use hosts created: 66
• Debugger listeners registered: 74
• Debugger listeners unregistered: 37

Failures commonly occur in bursts rather than as isolated errors.

Stale browser-tab evidence

The application’s internal browser registry reported as many as:

appBrowserTabCount=9

although only one browser tab was visible to the user.

The internal registry also retained several thread/browser-use entries after visible tabs had been closed. This suggests stale or hidden IAB tabs and routes are accumulating.

Scope isolation

The following observations exclude several alternative causes:

• The same Chat request succeeds after the route is registered.
• Ordinary Chat prompts without MCP tools or plugins reproduce the problem.
• The failure can occur before any request reaches ChatGPT.
• The prompt remains in the composer, showing that submission was not completed.
• No corresponding application-process crash was observed.
• Renderer processes remained responsive.
• The issue is therefore not specific to a local MCP server, tunnel, connector, port, or model-generation failure.

Likely root cause

A race condition exists between:

1. browser-use session creation,
2. transient-to-durable conversation ID rebinding,
3. debugger-listener registration,
4. browser route lookup, and
5. Chat message submission.

Concurrent active tasks and accumulated hidden browser tabs appear to increase the likelihood of the race.

A secondary renderer problem is also present: repeated ResizeObserver errors may cause UI jank, but they do not fully explain the missing browser route.

Impact

• Chat appears dead even though the backend is available.
• User prompts may remain unsent without a visible error.
• Retrying can cause uncertainty about duplicate submission.
• Automated Chat validation becomes unreliable.
• Restarting the application only provides temporary recovery.
• The problem becomes more frequent when several Codex tasks use browser sessions concurrently.

Temporary workaround

Fully restarting the desktop application clears the in-app browser registry and usually restores Chat temporarily.

Reducing concurrent in-app browser/browser-use sessions also reduces recurrence, but this is not an acceptable permanent solution because the application supports parallel tasks.

Requested fix

Please consider the following application-level protections:

1. Register the browser route before exposing the session as active.
2. Make transient client-new-thread:* to durable conversation-ID rebinding atomic.
3. Queue or retry getInfo and Send operations while route registration is pending.
4. Never silently lose a Send action.
5. Display a recoverable error when route acquisition times out.
6. Dispose stale hidden browser tabs and obsolete session routes.
7. Deduplicate concurrent route-creation attempts.
8. Add lifecycle telemetry that correlates the transient thread ID, durable conversation ID, browser tab ID, route key, and web contents ID.
9. Prevent ResizeObserver error loops from degrading the primary renderer.

Relevant log location

C:\Users\<user>\AppData\Local\Codex\Logs\

A sanitized affected log can be provided. Conversation content, account identifiers, and unrelated local data should be removed before submission.