Windows Codex routes authenticated Chrome tasks to isolated Playwright despite healthy Chrome extension checks
What version of the Codex App are you using (From “About Codex” dialog)?
26.506.3741.0 Windows package metadata: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex Desktop on Windows intermittently fails to use the real Chrome extension-backed browser session for authenticated browser tasks. Local Chrome plugin diagnostics pass, and the Chrome backend can sometimes be initialized and used successfully, but subsequent job-search/browser tasks still route to an isolated Playwright/Chrome DevTools profile or otherwise lose the live Chrome tab binding.
This breaks workflows that require my logged-in Chrome profile. The clearest failing case is TealHQ. When Teal is opened through the isolated Playwright MCP/browser instead of the real Chrome profile, Teal returns a Cloudflare 403 block page.
This does not appear to be a simple missing-extension or not-logged-in issue. It looks like a Codex Desktop browser-backend routing/binding instability on Windows.
Feedback thread reference:
Uploaded thread: 4cba3009-9233-49a3-94e0-e45ae6242020
Relevant local checks pass:
NativeHostCorrect : True
NativeHostManifest : C:\Users\matth\AppData\Local\OpenAI\extension\com.openai.codexextension.json
ExtensionInstalled : True
ExtensionEnabled : True
ChromeRunning : True
ChromeProfile : C:\Users\matth\AppData\Local\Google\Chrome\User Data\Default
Codex Chrome bridge local checks are healthy.
The Codex Chrome extension check reports installed/enabled:
{
"extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
"profilePath": "C:\\Users\\matth\\AppData\\Local\\Google\\Chrome\\User Data\\Default",
"installed": true,
"registered": true,
"enabled": true,
"disabled": false,
"versions": ["1.1.4_0"]
}
The native host check reports correct:
{
"manifestPath": "C:\\Users\\matth\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json",
"registryKey": "HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension",
"expectedHostName": "com.openai.codexextension",
"actualHostName": "com.openai.codexextension",
"expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
"expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
"allowedOrigins": ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"],
"exists": true,
"nameMatches": true,
"hasExpectedOrigin": true,
"registryMatchesManifestPath": true,
"correct": true,
"problem": null
}
At the same time, the separate Playwright MCP browser is isolated and shows:
- 0: (current) [](about:blank)
Multiple .playwright-mcp artifacts show Teal Cloudflare 403 blocks when the isolated browser surface is used:
.playwright-mcp\page-2026-05-11T17-32-58-657Z.yml:
heading "Sorry, you have been blocked"
heading "You are unable to access tealhq.com"
Cloudflare Ray ID: 9fa2ed144978fb10
.playwright-mcp\console-2026-05-11T17-32-58-217Z.log:
[ERROR] Failed to load resource: the server responded with a status of 403 () @ https://app.tealhq.com/:0
Earlier isolated Playwright artifacts show the same Teal block state:
.playwright-mcp\page-2026-05-10T19-14-11-607Z.yml
.playwright-mcp\page-2026-05-10T19-26-11-998Z.yml
.playwright-mcp\page-2026-05-10T19-47-57-702Z.yml
.playwright-mcp\page-2026-05-11T00-22-47-786Z.yml
I have a separate isolated Playwright MCP configured in ~\.codex\config.toml:
[mcp_servers.playwright]
command = "powershell"
args = ['-NoProfile', '-ExecutionPolicy', 'Bypass', '-Command', '$env:PLAYWRIGHT_BROWSERS_PATH = "$HOME\.cache\ms-playwright"; New-Item -ItemType Directory -Force -Path "$HOME\.playwright-mcp", $env:PLAYWRIGHT_BROWSERS_PATH | Out-Null; npx -y @playwright/mcp@latest --headless --isolated --viewport-size=1366x900 --timeout-navigation=60000 --timeout-action=5000']
The issue is that Codex sometimes uses or falls back to that isolated browser surface for a task that explicitly requires the real Chrome extension-backed profile.
What steps can reproduce the bug?
I do not have a minimal standalone code repro, because the bug appears to be in Codex Desktop browser backend routing/binding. The reproducible shape is:
Use Codex Desktop on Windows with the Chrome plugin enabled.
Install and enable the Codex Chrome extension in the Chrome Default profile.
Confirm the extension/native-host checks pass.
Open and log into https://app.tealhq.com/home in real Chrome.
Ask Codex to use Chrome/Teal for a browser task that requires signed-in Chrome state.
Observe intermittent behavior:
Correct path: Codex lists Chrome backend type extension, lists open user tabs, and can claim Teal - Home.
Failure path: Codex uses isolated Playwright/Chrome DevTools surface instead, current tab is about:blank, and Teal returns Cloudflare 403.
In one successful diagnostic turn, the Chrome backend state was:
{
"setupOk": true,
"setupMs": 1344,
"browsers": [
{
"name": "Chrome",
"type": "extension"
},
{
"name": "Codex In-app Browser",
"type": "iab"
}
],
"tealTabs": [
{
"title": "Teal - Home",
"url": "https://app.tealhq.com/home"
}
],
"tealTabCount": 1
}
The failure recurs in later chats/turns even after a successful Chrome-backed verification, so it is not fully fixed by one local bridge repair command.
Similar public issues that seem related:
https://github.com/openai/codex/issues/21868
https://github.com/openai/codex/issues/21878
https://github.com/openai/codex/issues/21670
https://github.com/openai/codex/issues/21672
My originally suspected issue, https://github.com/openai/codex/issues/18456, seems adjacent but not identical. That issue is about backend OpenAI/Statsig requests hitting Cloudflare because of a Rust HTTP client user agent. My Teal failure is specifically a wrong browser-surface issue where isolated Playwright hits Teal Cloudflare.
What is the expected behavior?
For browser tasks that require logged-in Chrome state, Codex should use the real Chrome extension-backed browser session, not isolated Playwright or a clean Chrome DevTools MCP profile.
Expected behavior:
Codex uses chrome@openai-bundled.
Browser backend list includes Chrome with type extension.
Codex can list open user tabs from the real Chrome profile.
Codex can claim an existing https://app.tealhq.com/... tab.
Teal loads without Cloudflare block or login prompt.
Codex does not silently fall back to isolated Playwright for authenticated websites.
If the Chrome extension backend is unavailable, Codex should fail fast with a clear diagnostic instead of using the wrong browser surface.
Additional information
Chrome and plugin environment:
Chrome version: 148.0.7778.97
Codex Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Codex Chrome extension version: 1.1.4_0
Chrome plugin cache: C:\Users\matth\.codex\plugins\cache\openai-bundled\chrome\0.1.7
Native host exe: C:\Users\matth\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe
Chrome profile: C:\Users\matth\AppData\Local\Google\Chrome\User Data\Default
Requested help:
Confirm whether this is the same class of bug as #21868, #21878, #21670, or #21672.
Provide a supported way to force a task/thread to use the real Chrome extension backend and not the isolated Playwright MCP.
Add clearer diagnostics when a task is about to use isolated Playwright for a site requiring signed-in Chrome state.
Add bounded backend discovery/handshake timeouts so stale/unrelated browser-use pipes or backend candidates do not hang or misroute the task.
Clarify whether users should disable separate Playwright MCP servers when using the Chrome extension for authenticated websites.
Clarify whether plugin uninstall/reinstall is expected to help when local checks pass but routing still falls back to isolated browser profiles.
2 Comments
@GetFractional — TealHQ's Cloudflare 403 on the isolated profile is the clearest tell here: the fingerprint / cookies / IP-reputation delta between your real Chrome and the chrome-devtools-mcp isolated profile (
.cache\chrome-devtools-mcp\chrome-profile) is large enough that Cloudflare's edge layer treats the isolated path as a bot, even when Codex reports the Chrome extension asConnected. The.playwright-mcppage-dump artifacts confirm the routing — the actual job did execute against the isolated Playwright surface, not the real Chrome profile. Your diagnostics passing just means the bridge can be set up; it doesn't mean Codex's backend chose to use it for this particular call.The architecture you actually want for the Teal class of sites is a bridge that never spawns an isolated profile — agent talks to your already-running Chrome via an extension + native messaging host, with the failure mode being "the bridge errors and the call fails," not "the call silently succeeds against a different profile that Cloudflare blocks." Chrome Relay (https://chrome-relay.kushalsm.com/) ships exactly that primitive standalone (MV3 extension + native messaging host + CLI). Same fingerprint Cloudflare already trusts (because it is your real Chrome), no IP delta, no second profile.
Doesn't fix Codex's routing — that's still in the team's court. But it sidesteps the entire Cloudflare class of problem because there's no second profile/IP for Cloudflare to flag in the first place.
Hey @GetFractional — excellent bug report. The diagnostics are thorough and the routing failure pattern is clear.
Your diagnosis looks right. Extension/native-host checks all pass, Chrome backend sometimes initializes correctly (lists Teal tabs,
type: "extension"), then later turns silently fall back to the isolated Playwright MCP surface (about:blank, no session cookies). Teal then 403s via Cloudflare — not because you're logged out, but because the isolated headless profile has neither your Chrome auth state nor a fingerprint Cloudflare trusts.The
.playwright-mcpartifacts across multiple days confirm this isn't a one-off handshake glitch — it's backend selection instability on Windows.On your specific questions:
[mcp_servers.playwright]in~/.codex/config.tomlwhen running authenticated Chrome tasks. Your isolated MCP config is almost certainly a routing candidate Codex can fall back to — exactly the failure mode you describe. One backend, fewer misroutes.Why Teal 403s on isolated Playwright specifically: Teal sits behind Cloudflare bot protection. Your real Chrome profile passes because it has established cookies, consistent TLS/fingerprint, and human browsing history. Isolated headless Playwright exits with a clean automation fingerprint — Cloudflare blocks before login even matters.
If you need Teal/authenticated browser automation outside Codex's routing (while this bug is open), I went through similar pain with Playwright-based stacks. Tested AdsPower and Dolphin — fine for basic tasks, but their local APIs leak webdriver signals or destabilize under concurrent sessions. For Cloudflare-gated authenticated sites I ended up on Multilogin X:
Wiring Multilogin + CDP is fiddly at first (profile launch, port binding, session reuse). I open-sourced boilerplate scripts + a setup guide — partner code
SAAS50(50% off): https://t.me/Multilogin_Scripts_BotShort-term for this issue: Disable Playwright MCP during Chrome-extension tasks, and add a note in the thread when Codex picks
type: "extension"vs isolated — that breadcrumb helps confirm the routing race. Long-term fix is what you're asking for: fail fast with a clear diagnostic when extension backend is available but Codex selects Playwright instead.Hope that helps while the routing bug is triaged — the extension path clearly works when Codex actually uses it.