Skip to content

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

Open

Description

@wmmalcolm

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?

  1. Start a Codex Desktop task on macOS.
  2. Ask Codex to use the Browser plug-in / in-app browser for local UI validation, public-site review, documentation browsing, or skills-directory inspection.
  3. Codex attempts to open or control Browser.
  4. Codex Desktop freezes or becomes unable to accept input.
  5. Force quit Codex and restart to recover.
  6. 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:

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

  1. added
    appIssues related to the Codex desktop app
    on Jun 29, 2026
  2. xlc commented on Jul 3, 2026

    @xlc

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions