›_ Codex Issues
Codex Issues / #36333

Windows app freezes during recurring heartbeat when in-app browser tab finalization times out

Open 💬 6 comments Opened Jul 31, 2026 by salthani
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The Codex Windows app repeatedly becomes unresponsive when a recurring thread heartbeat uses the in-app browser. Pausing the heartbeat stops the repeated freezes.

The browser can discover, claim, and verify the intended existing tab, but releasing the browser binding can hang until the bounded browser call times out and the Node-backed browser-control kernel resets.

Environment

  • Codex for Windows package: OpenAI.Codex 26.721.11231.0
  • OS: Windows 11 Pro, version 10.0.26200, build 26200
  • Automation type: thread heartbeat
  • Schedule: every 2 minutes on weekdays
  • In-app browser: 5-7 existing tabs
  • Automation has now been paused

Reproduction

  1. Open several tabs in the Codex in-app browser, including a TradingView chart.
  2. Create a lightweight recurring thread heartbeat every two minutes.
  3. On each heartbeat, run a local gate first. Most wakes finish in under one second without browser access.
  4. On an eligible wake, call browser.user.openTabs().
  5. Claim the matching descriptor with browser.user.claimTab(descriptor).
  6. Read the claimed tab URL/title to verify identity.
  7. Call browser.tabs.finalize() with an 8-second timeout.

Observed behavior

  • openTabs() returned the intended existing tab.
  • claimTab(descriptor) succeeded.
  • URL/title verification succeeded.
  • browser.tabs.finalize() timed out after 8 seconds.
  • Tool result: js execution timed out; kernel reset, rerun your request.
  • The Windows app subsequently showed “Codex is not responding” during repeated automation use.
  • Earlier, passing a user-tab ID into browser.tabs.get() returned Tab not found; switching to the supported descriptor-based claimTab() fixed claiming but not the finalization hang.
  • Task Manager screenshots showed normal overall machine load, so this did not appear to be system-wide CPU or memory exhaustion.

Relevant UTC timestamps from one reproduction:

  • Tab claim/verification attempt: 2026-07-31 around 14:16-14:17 UTC
  • Finalization timeout recorded: 2026-07-31 14:17:52 UTC

Expected behavior

  • Browser tab finalization should complete promptly and release the binding.
  • A lightweight recurring heartbeat should not make the Codex Windows UI unresponsive.
  • If cleanup fails, the browser operation should fail cleanly without hanging or requiring the browser-control kernel to reset.

Impact

Recurring browser-backed monitors are not reliable on Windows because cleanup can hang, and a frequent heartbeat amplifies the problem. The only safe mitigation was to pause the automation and use a persistent circuit breaker.

Additional notes

  • The automation was read-only and never placed or modified orders.
  • Browser calls were limited to 8 seconds, total intended browser work to 12 seconds, with no retries.
  • Credentials and private market-data values are intentionally omitted.
  • Session logs and screenshots can be provided privately if needed.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 27 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35425
  • #35210
  • #36278

Powered by Codex Action

salthani · 27 days ago

Retest update: after disabling VPNs, the existing TradingView tab was discovered, claimed, and verified successfully. Cleanup also completed immediately when using the documented form browser.tabs.finalize({ keep: [{ tab, status: "handoff" }] }). The earlier timeout occurred after calling finalize() without the required options, so that specific cleanup timeout may have been client misuse rather than a backend defect. The two-minute monitor has been reactivated cautiously with the corrected finalization rule. I am leaving the issue open temporarily because the broader repeated Windows-app freeze still needs observation under the corrected workflow.

salthani · 27 days ago

Second reproduction update: the two-minute heartbeat was reactivated only after a bounded health check succeeded with VPNs disabled. The exact TradingView tab was discovered, claimed, verified, and released successfully using browser.tabs.finalize({ keep: [{ tab, status: "handoff" }] }). Despite that corrected workflow, the Codex Windows app froze again during subsequent recurring operation. The automation has been paused again.

Network checks at the time showed: Windows user proxy disabled, no PAC URL, WinHTTP direct access, no proxy environment variables, no Tailscale Exit Node, and default internet routes remained on Wi-Fi/Ethernet. Tailscale was still running only as an overlay/MagicDNS participant. This makes the earlier bare finalize() call and ordinary VPN/proxy routing insufficient to explain the repeated freeze.

No cookies were deleted and no credentials or private market-data values are included in this update.

salthani · 27 days ago

Reproduction update — freeze persists after network and browser-state cleanup

The Codex for Windows freeze recurred again after eliminating the suspected local causes:

  • Codex app version: 26.721.11231.0 (Windows x64)
  • Windows user proxy: disabled; no PAC configured
  • WinHTTP proxy: direct access
  • VPN: no VPN exit route in use (Tailscale had no exit node; normal internet routes remained on the local network adapter)
  • DNS: no active system-wide secure-DNS override on the current internet interface; normal DNS used the local router
  • Built-in-browser cookies: deleted for all sites through Settings → Browser → Browsing data → Delete cookies; the app confirmed Browser cookies cleared
  • The same hang/freeze still occurred afterward

A retry to reactivate the two-minute heartbeat monitor stalled inside the app. The saved automation file remained status = "PAUSED", and the pending update was terminated, so the monitor was not left active.

This makes VPN/proxy/DNS configuration and stale built-in-browser cookies unlikely to be the root cause. The recurring trigger continues to correlate with the two-minute heartbeat/automation workflow in Codex for Windows.

salthani · 27 days ago

Exact affected version

Verified directly from the installed Windows package and local executable:

  • Codex desktop: OpenAI.Codex 26.721.11231.0
  • Architecture: x64
  • Bundled/local Codex CLI: codex-cli 0.146.0-alpha.3.1

This is the version pair on which the recurring freeze and stalled two-minute heartbeat reactivation were reproduced.

salthani · 27 days ago

Mobile-hotspot A/B test — OpenAI Support case 12474714

I ran the requested different-network test using a mobile hotspot.

  • The existing two-minute heartbeat was reactivated without changing its prompt, schedule, target task, or read-only/order-safety rules.
  • Reactivation completed immediately at 2026-07-31 18:18:51 Asia/Qatar (UTC+03:00) / 15:18:51 UTC.
  • Codex remained responsive during the test; the previous reactivation hang did not recur.
  • However, the task record contains no scheduled heartbeat turns during the active test window, despite expected due times at 18:20, 18:22, 18:24, and 18:26 Asia/Qatar. Therefore, the hotspot avoided the reactivation hang but did not demonstrate successful end-to-end wake delivery.
  • I manually paused the automation at 18:27:41 Asia/Qatar / 15:27:41 UTC. Its saved state is confirmed as PAUSED.

Interpretation: the original network/WebSocket path may contribute to the hang, but this test also exposes a potentially separate scheduler/wake-delivery issue. A longer hotspot test or specific wss://ws.chatgpt.com handshake diagnostics may be needed to separate those two behaviors.