Chrome plugin: tab.goto() causes native pipe closed / kernel reset, blocking navigation and web automation
Open 💬 4 comments Opened May 20, 2026 by 265kg22t77-cmyk
💡 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)?
26.153.40821
What subscription do you have?
plus
What platform is your computer?
Windows, PowerShell environment Chrome version: 148.0.7778.168 Codex Chrome Extension: 1.1.4_0 Extension ID: hehggadaopoacecdllhhajmbjkdcmajg Chrome profile: 用户1
What issue are you seeing?
The Codex Chrome plugin can connect to Chrome and perform basic tab operations, but it cannot complete actual browser automation because navigation causes the native messaging pipe to close.
Working:
- Connects to the Codex Chrome Extension successfully.
- Lists existing Chrome tabs.
- Reads tab title and URL.
- Creates a managed
about:blanktab. - Lists managed tabs.
- Cleans up managed tabs with
browser.tabs.finalize({ keep: [] }).
Broken:
- Calling
tab.goto('https://example.com/')on a managed tab causes the Node REPL kernel to reset. - Calling
tab.goto('http://127.0.0.1:8765/...')also causes the same failure. - The error bypasses normal JS
try/catch.
Observed error:
node_repl kernel unhandled rejection: native pipe is closed; kernel reset.
This blocks the Chrome plugin from doing the main tasks I need:
Opening web pages
Searching the web
Reading search results
Filling forms
Opening Gmail or other webmail
Completing multi-step browser workflows
Environment checks pass:
Chrome is running.
Codex Chrome Extension is installed and enabled.
Native host manifest exists and is correct.
Registry native messaging host path matches the manifest.
So this does not look like an authorization issue or a website-specific issue. It looks like a Chrome Extension / native messaging / browser-client navigation stability issue.
### What steps can reproduce the bug?
1. Start Codex with the Chrome plugin enabled.
2. Connect to Chrome through the plugin.
3. Verify that basic tab listing works:
```js
const { setupBrowserRuntime } = await import('file:///C:/Users/Admin/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs');
await setupBrowserRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get('extension');
await browser.nameSession('Chrome capability test');
const openTabs = await browser.user.openTabs();
console.log(openTabs);
This succeeds.
4.Create a managed tab:
globalThis.tab = await browser.tabs.new();
console.log(await tab.title(), await tab.url());
This succeeds and returns an about:blank tab.
5.Try to navigate the managed tab:
await tab.goto('https://example.com/');
await tab.playwright.waitForLoadState({ state: 'domcontentloaded', timeoutMs: 15000 });
The Node REPL kernel crashes/resets with:
node_repl kernel unhandled rejection: native pipe is closed; kernel reset.
Additional observations:
6.The same issue happened when navigating to a localhost page:
http://127.0.0.1:8765/chrome-test-form.html
Trying to claim chrome://newtab/ failed with:
Chrome internal tab 1709557289 cannot be claimed
Using CUA keyboard actions to press Ctrl+L, type a URL, and press Enter returned without an error, but the tab stayed on about:blank.
### What is the expected behavior?
The Chrome plugin should be able to navigate a managed tab to normal web pages such as `https://example.com/`, then allow Playwright/DOM operations on that page.
Expected workflow:
1. Create or claim a controllable Chrome tab.
2. Navigate to a URL.
3. Wait for the page to load.
4. Read DOM content.
5. Fill forms.
6. Click buttons.
7. Continue multi-step workflows such as search, web forms, or email drafting.
If navigation fails, it should fail as a normal catchable JavaScript exception instead of closing the native pipe and resetting the Node REPL kernel.
### Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I checked the potential duplicates #22794 and #22849. #22849 is very similar, but I did not see a visible workaround or closure reason. I also found #22114, which suggests fully closing Chrome and extension-host.exe before restarting Codex/reinstalling the Chrome plugin. I will try that workaround and report whether it changes the behavior.
Update after cleanup:
I found that
extension-host.exewas previously being relaunched by Quark Browser, a Chromium-based browser, even after Chrome was closed:quark.exe -> cmd.exe -> extension-host.exe
After closing Quark and killing the stale native messaging chain, I restarted Codex and Chrome.
The behavior changed:
tab.goto('https://example.com/')actually opens the page in Chrome.Example Domainhttps://example.com/However, the automation call still does not complete normally:
tab.goto()JS execution times out and resets the kernel.So the current behavior is closer to #22794: Chrome can open a page, but page control and screenshots time out after navigation.
I can reproduce a very similar failure on macOS Apple Silicon with current Codex Desktop.
Environment:
What works:
What fails:
Observed behavior:
This does not look like a Chrome extension installation problem in my case: the native messaging host manifest validates, the extension-host process is running, and the Chrome backend is listed by
agent.browsers.list(). The failure appears to be specifically in the navigation/control path after the extension backend is connected.Additional related observation: before launching Chrome,
agent.browsers.list()only showed the in-app browser andagent.browsers.get("extension")returnedBrowser is not available: extension. After launching Chrome, the extension backend appeared, but navigation still hangs as described above.