Codex Desktop freezes when using Browser plug-in / in-app browser; repeated app-server handshake timeout loops

Open 💬 2 comments Opened Jun 29, 2026 by wmmalcolm

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex Desktop 26.623.70822 observed in current Chrome/Computer Use plugin/runtime context; About Codex dialog value not independently verified in this run.

What subscription do you have?

Unknown from local diagnostics; user is a heavy Codex Desktop power user. Please treat subscription value as not verified from this bug report.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

I am a heavy Codex Desktop user on macOS using local repositories, Chrome, Browser/in-app browser, Computer Use, skills, MCP tools, and long-running project threads. The Browser plug-in / in-app browser repeatedly freezes Codex instead of failing gracefully. The user reports this has happened at least 8 times.

Current behavior:

Codex attempts to use Browser / in-app browser.
The app freezes or becomes unable to accept input.
Recovery requires force quitting Codex and restarting.
Local logs show repeated app-server initialize handshake timeout loops in recent sessions.

Local evidence observed on this machine:

/Users/Library/Logs/com.openai.codex/2026/06/29/codex-desktop-8224ff2b-3d87-4828-91be-9bfea8758b58-657-t0-i1-013931-0.log: 12,510 occurrences of Codex app-server initialize handshake timed out.
/Users/Library/Logs/com.openai.codex/2026/06/28/codex-desktop-7122a343-d39a-4031-9d27-69e4012ff09a-45701-t0-i1-000342-0.log: 12,425 occurrences.
/Users/Library/Logs/com.openai.codex/2026/06/27/codex-desktop-326f7189-ddb3-470e-97b8-4eeac7a1e69c-74013-t0-i1-013204-0.log: 11,684 occurrences.

I do not have one clean stack trace that explicitly says "Browser plug-in caused freeze." The user-visible symptom is reproducible; the local evidence shows repeated app-server handshake/reconnect storms around recent Codex sessions.

What steps can reproduce the bug?

Start a Codex Desktop task on macOS.
Ask Codex to use the Browser plug-in / in-app browser for local UI validation, public-site review, documentation browsing, or skills-directory inspection.
Codex attempts to open or control Browser.
Codex Desktop freezes or becomes unable to accept input.
Force quit Codex and restart to recover.
Repeat: user reports this has happened at least 8 times.

Concrete workflows where Browser/in-app browser is part of the user's normal Codex usage include local UI verification, public-site review, SharePoint/dashboard validation, Obsidian download/setup guidance, and agent skills directory review.

What is the expected behavior?

Browser failures should fail closed without taking down the main Codex app.

Expected behavior:

Browser launch/control should time out cleanly.
The composer and current thread should remain usable.
App-server reconnect loops should have bounded retries and a visible diagnostic state.
The app should provide recovery actions such as "detach Browser," "retry Browser," "switch to Chrome," or "export diagnostics."
Browser tasks should never put the entire Codex app into a total input lock-out.

Additional information

Related public issues already visible in openai/codex on 2026-06-29:

#30602 - Codex Desktop on macOS becomes completely unable to accept input; only Force Quit restores it.
#30605 - In-app browser screenshot capture times out when Codex app is minimized.
#30608 - macOS Computer Use damaged and verification hangs after 26.623.70822 update.
#30623 - Remote Control-created target thread hits Chrome Browser Use enterprise-policy block while target-local thread passes.
#30562 - Browser/Chrome plugins installed and runtime present, but node_repl js tool is not exposed.
#30558 - Codex App crashes/hangs when opening local HTML with the built-in browser on Windows.
#30542 - Codex Desktop freezes while running new-worktree environment setup command.

Suggested labels: bug, app, browser, performance, app-server, macOS.

This report was prepared from a local review and has not attached raw logs to avoid over-sharing local data. I can provide a redacted diagnostic bundle if that would help.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

#30602
#30178
#30558
#30429

Powered by Codex Action

xlc · 1 month ago

Adding another data point from a Codex Desktop in-app Browser run on macOS.

Context:

Browser surface: Codex In-app Browser via the bundled Browser plugin.
Task: manual staging QA flow, clicked an app-side GitHub login link.
Before the click, the in-app browser could navigate to the staging login page and read DOM state.
Screenshot capture had already timed out twice with Timed out running CDP command "Page.captureScreenshot" for tab 1.

Observed failure after initiating login:

The browser-control call that clicked Continue with GitHub timed out before returning the post-click URL/state.
After reconnecting the Browser runtime, agent.browsers.list() still returned Codex In-app Browser.
The backend looked present/reachable, but tab-level calls hung:
browser.tabs.list() timed out after 5s
browser.tabs.selected() timed out after 5s
browser.tabs.new() timed out after 8s
Because tab APIs hung, the agent could not verify whether OAuth returned to staging or whether /admin was reachable.

Why this may be useful:

This is a narrower symptom than screenshot timeout alone: the IAB backend was discoverable, but tab discovery/selection/creation became unresponsive after a browser/login flow. It matches the broader issue here that Browser control should fail closed with bounded recovery instead of wedging the task/browser-control path.

I intentionally omitted local paths, session ids, cookies, and app logs from this comment.