Repository navigation
Codex Desktop freezes when using Browser plug-in / in-app browser; repeated app-server handshake timeout loops #30624
Description
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:
- Codex Desktop on macOS becomes completely unable to accept input (total lock-out); only Force Quit restores it #30602 - Codex Desktop on macOS becomes completely unable to accept input; only Force Quit restores it.
- In-app browser screenshot capture times out when Codex app is minimized #30605 - In-app browser screenshot capture times out when Codex app is minimized.
- [macOS] Codex Computer Use damaged and verification hangs after 26.623.70822 update #30608 - macOS Computer Use damaged and verification hangs after 26.623.70822 update.
- Remote Control-created target thread hits Chrome Browser Use enterprise-policy block while target-local thread passes #30623 - Remote Control-created target thread hits Chrome Browser Use enterprise-policy block while target-local thread passes.
- Windows 26.623: Browser/Chrome plugins installed and runtime present, but node_repl js tool is not exposed #30562 - Browser/Chrome plugins installed and runtime present, but node_repl js tool is not exposed.
- Codex App crashes/hangs when opening local HTML with the built-in browser on Windows #30558 - Codex App crashes/hangs when opening local HTML with the built-in browser on Windows.
- Codex Desktop freezes while running new-worktree environment setup command #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.
Activity
github-actions commentedon Jun 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xlc commentedon Jul 3, 2026
Adding another data point from a Codex Desktop in-app Browser run on macOS.
Context:
Timed out running CDP command "Page.captureScreenshot" for tab 1.Observed failure after initiating login:
Continue with GitHubtimed out before returning the post-click URL/state.agent.browsers.list()still returnedCodex In-app Browser.browser.tabs.list()timed out after 5sbrowser.tabs.selected()timed out after 5sbrowser.tabs.new()timed out after 8s/adminwas 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.