Intermittent Chrome plugin Node REPL kernel reset after successful setup and page control

Summary

This is another js execution timed out; kernel reset, rerun your request report, but it is not a pure setup failure.

The Chrome plugin can successfully connect, open an authenticated website, read DOM snapshots, and click links. Then, during an attachment/download-related interaction, the Node REPL can still hang hard enough to reset the kernel. A few minutes later the same plugin path can work again without reinstalling anything.

The current error message is basically a shrug in exception form: it destroys the JS kernel and gives no clue whether the browser client, Chrome extension, native messaging host, page navigation, or download event listener actually hung.

Environment

• OS: Windows x64
• Codex App package: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
• Codex App version: 26.609.4994.0
• Chrome: 149.0.7827.103
• Chrome plugin bundle: openai-bundled/chrome/26.609.41114
• Extension host process was observed running from the bundled Chrome plugin path

What happened

In Codex Desktop using the official Chrome plugin:

1. Connected to the Chrome extension runtime successfully.
2. Opened an authenticated website and completed login.
3. Opened a materials page.
4. Read the materials page DOM successfully.
5. Clicked an attachment link and attempted to wait for/download the file.
6. The JS execution timed out and reset the kernel:

``text
js execution timed out; kernel reset, rerun your request
``

1. No file appeared in the Downloads folder.
2. After reconnecting, Chrome had navigated to the attachment detail page.
3. Attempting to inspect that detail page also timed out once.
4. Later, without reinstalling or changing the extension, the same Chrome plugin path worked again:

• opened the same materials page and read the DOM in about 2-3 seconds,
• clicked the same attachment detail link successfully in about 259 ms,
• navigated back successfully,
• clicked into another page and back successfully.

This has happened multiple times before on this machine. Sometimes it only lasts briefly; other times it persists for a while.

Why this is frustrating

When the extension works, it works. When it fails, it fails in a way that looks like the whole browser-control stack fell into a black box.

A generic kernel reset is not a diagnostic. It makes the user guess between:

• Node REPL runtime hang
• Chrome extension handshake problem
• native messaging host / pipe issue
• page navigation timeout
• download event listener hang
• stale extension-host.exe
• site-specific heavy authenticated page behavior
• network/proxy/ambient probe issue

That is too much ambiguity for a tool that otherwise has enough local state to give a more bounded failure.

Expected behavior

The Chrome plugin should not let a single browser/download/navigation operation hang until the Node REPL kernel is reset.

At minimum, it should:

1. Put bounded timeouts around extension/native-host/browser operations.
2. Preserve enough error context to say which layer hung.
3. Avoid resetting the entire JS kernel when a page download event or navigation wait hangs.
4. Surface whether the active tab, extension host, or native messaging channel is still alive.
5. Recover stale extension-host/native-pipe state automatically when possible.

Related issues

This seems related to, but not identical to:

• #21705
• #21704
• #21698
• #21713
• #22849

Those mostly describe setup/openTabs/backend initialization failures. This report is about an intermittent failure after setup and successful page control, especially around authenticated attachment navigation/download handling.