[Windows][Chrome extension] attach/executeCdp race causes "Debugger is not attached" and browser action timeout

Open 💬 0 comments Opened Jul 23, 2026 by wingA1

What version of the Codex App are you using?

  • Codex App: 26.715.10079.0
  • Chrome plugin package/runtime: 26.715.72359
  • Chrome extension: 1.2.27221.15725
  • Native host: com.openai.codexextension

What subscription do you have?

ChatGPT Plus

What platform are you using?

  • Windows 11 x64
  • Google Chrome 150.0.0.0

What issue are you seeing?

Browser actions through the Codex Chrome extension intermittently time out after about 30 seconds. In one reproducible case, the requested click did not execute and the page remained unchanged.

Direct Chrome debugger operations from the extension Service Worker work correctly (chrome.debugger.attach, Page.getFrameTree, and chrome.debugger.detach). Native Messaging transport is connected and request/response IDs are preserved.

Using DevTools Logpoints only (no behavior changes), I captured a race between the Native Messaging methods attach and executeCdp for the same tab.

Relevant trace

Target tab: 891675004

1784786338260  NATIVE_IN   id=native-host:4:34875  method=attach
1784786338395  NATIVE_IN   id=native-host:4:35095  method=executeCdp
1784786338402  NATIVE_OUT  id=native-host:4:34875  result=<success>
1784786338402  NATIVE_OUT  id=native-host:4:35095  error="Debugger is not attached to the tab with id: 891675004."

The executeCdp request arrived 135 ms after the attach request, but 7 ms before the attach request completed. It was therefore executed while the debugger attachment was still in flight.

The corresponding JSON-RPC messages were:

{
  "tag": "NATIVE_IN",
  "ts": 1784786338260,
  "id": "native-host:4:34875",
  "method": "attach",
  "keys": ["id", "jsonrpc", "method", "params"],
  "hasResult": false,
  "hasError": false
}
{
  "tag": "NATIVE_IN",
  "ts": 1784786338395,
  "id": "native-host:4:35095",
  "method": "executeCdp",
  "keys": ["id", "jsonrpc", "method", "params"],
  "hasResult": false,
  "hasError": false
}
{
  "tag": "NATIVE_OUT",
  "ts": 1784786338402,
  "id": "native-host:4:35095",
  "keys": ["jsonrpc", "id", "error"],
  "hasResult": false,
  "hasError": true,
  "errorMessage": "Debugger is not attached to the tab with id: 891675004."
}

Steps to reproduce

  1. Open an authenticated page in normal Chrome and connect through the Codex Chrome extension.
  2. Let Codex discover and claim the existing tab.
  3. Request a page-level action, for example clicking a unique button.
  4. Observe the action call time out after about 30 seconds.
  5. In the failing run, the page does not change because the underlying CDP command never executes.
  6. Inspect the extension Service Worker Native Messaging traffic and observe executeCdp arriving before the prior attach request has completed.

Expected behavior

For each tab, executeCdp should not run until the debugger is attached successfully.

The host/app-server should await the successful attach response before sending executeCdp, or the extension should serialize these operations per tab and await an in-flight attach promise.

Actual behavior

attach and executeCdp are processed concurrently. executeCdp can reach chrome.debugger.sendCommand while attachment is still in progress, causing:

Debugger is not attached to the tab with id: <tabId>.

The upper browser action then waits and eventually reports a timeout instead of surfacing this immediate underlying error.

Suggested fix

  • Serialize attach and executeCdp per tabId.
  • Maintain/reuse a per-tab in-flight attach promise or the existing per-tab lock.
  • Ensure every executeCdp awaits that promise before calling chrome.debugger.sendCommand.
  • Optionally, for the exact Debugger is not attached error only, re-run attach and retry the original CDP command once.
  • Surface the underlying attach/CDP error immediately rather than converting it into a later generic timeout.

Additional information

This appears related to the broader deep-control bridge symptoms reported in #30841, but this report includes a concrete Windows trace that identifies an attach / executeCdp ordering race.

View original on GitHub ↗