[Windows] Browser Use lists correct Chrome tabs but cannot request permission / verify saved browser permissions

Summary

Browser Use on Windows can discover the correct Chrome profile and list its existing ChatGPT tab, but attempting to access/read the tab fails before page content is returned:

Browser Use could not complete this action because a browser security check was unavailable. Reason: Browser Use could not request permission. Browser use cannot access https://chatgpt.com because saved browser permissions could not be verified.

This appears related to #42466 and #41334, but the observed reason is saved browser permissions could not be verified, rather than a confirmed administrator policy denial.

Environment

Windows desktop app package: OpenAI.Codex 26.924.2738.0
Bundled official Chrome/browser plugin: 26.924.22138
Browser: Google Chrome with official ChatGPT extension 1.26.901.11451
Reproduced September 27, 2026 (Korea time)

Reproduction

Open Chrome using the user's intended profile and open https://chatgpt.com.
Initialize the official browser-client via the provided Node tool.
Select the confirmed Chrome profile and list user tabs.
The existing ChatGPT tab is returned correctly.
Attempt to claim/read that tab through the documented browser API.
The permission-verification error above is returned; no page content is available.

Checks completed

An initially selected different Chrome connection returned zero tabs. That profile-selection mistake was corrected, but the permission failure persists on the confirmed profile.
Official extension diagnostic: installed and enabled.
Official native-host diagnostic: correct=true; registered manifest, host name and expected extension origins match.
The cached browser-client and app-bundled browser-client have matching SHA256 hashes.
User-reported restart attempts did not resolve access.
Switching away from and back to the affected Codex conversation, then retrying the same Chrome profile/tab, did not resolve access.
An earlier in-app browser navigation to ChatGPT also returned the same saved-permissions verification error.

Correlated log evidence (not a proven cause)

Desktop logs for the affected conversation, around 2026-09-26 23:28–23:31 UTC, repeatedly contain:
No ChatGPT browser route is available for browser session [redacted]

We have not established that this routing error causes the Chrome permission-verification failure. No claim is made that profile mismatch was the root cause of the remaining failure.

Expected behavior

Complete the saved-permission check and present a normal, actionable approval prompt if needed. If verification cannot run, identify the failing component and provide a supported recovery path.

Please distinguish an actual permission denial from an unavailable permission check. Is there a known Windows fix for this build, or a supported way to repair conversation/browser routing and reload saved permissions without broadening access or deleting history?

No browser security controls were bypassed. No cookies, credentials, private business data, raw logs, local usernames, or conversation identifiers are included in this report.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

In-app Browser Use enters stale policy-verification state until desktop app restart #47334

Powered by Codex Action

Sharing a verified macOS cause of this same saved-permissions error, diagnosed with Codex. I have not reproduced or verified this fix on Windows, but it may give maintainers another concrete path to check.

Environment: macOS desktop app 26.924.22138, bundled browser plugin 26.924.22138, Chrome extension 1.26.901.11451.

Symptoms: Chrome tabs could be listed, but actual page access failed with “saved browser permissions could not be verified.” The built-in browser also failed. It persisted across new chats and separate projects. Reinstalling the extension, restarting, changing permission settings, and rebuilding the plugin cache did not resolve it.

Finding: ~/.codex and ~/.codex/browser were ordinary directories, but ~/.codex/browser/sessions was a symbolic link to an old automation directory. The global browser config was valid and readable. Issue #35310 supplied the diagnostic lead. The installed native reader contains Codex TOML directory must not be a symlink, and the installed permission-checking code maps saved-state read failures to this generic error. We did not capture the suppressed underlying exception from the live process, so the internal failure mechanism is inferred from that code and the controlled test below.

Controlled before/after test:

Opening https://example.com through Chrome failed with the exact saved-permissions error.
Backed up the sessions symlink and replaced it with a real local directory containing all 50 existing session permission files, unchanged. SHA-256 checks verified every copied file. The original target was preserved; no allow/deny entries or global approval settings were changed.
Immediately afterward, without restarting the app, the same Chrome request succeeded. Codex read the page, clicked “Learn more,” and read the destination at IANA. The built-in browser independently passed the same read-and-click test.
Post-test checks confirmed the 50 session file hashes and global config hash remained unchanged.

A read-only check for this particular layout is:

ls -ld ~/.codex ~/.codex/browser ~/.codex/browser/sessions

This is a fix for the symlink case we tested, not a claim that every instance of this error has the same cause. There was no need to delete the Codex home directory or weaken permissions.

It would help if the error exposed the rejected directory and underlying reader reason. Tests covering a symlinked browser/sessions directory independently of a symlinked CODEX_HOME may catch this variant.

Adding a Windows confirmation of a related junction/symlink case.

Environment:

Windows application package: 26.924.2738.0
Desktop release and bundled Browser/Chrome plugins: 26.924.22138
App server: 0.158.0-alpha.2.1

Symptoms: Both Chrome and the built-in browser connected successfully and could create/read about:blank, but navigation to https://example.com/ failed with saved browser permissions could not be verified. A full desktop-app restart and a new local, projectless chat did not resolve it.

Finding and outcome: My .codex home was a Windows directory junction pointing to another drive. Ordinary reads of the target directory and browser configuration succeeded. The issue was resolved after addressing the .codex junction/symlink setup.

This adds a Windows case involving the Codex home directory itself, alongside the macOS browser/sessions symlink case reported above and the related investigation in #35310.

The diagnostic trace identified persistent browser-permission snapshot refresh as the failing layer, but the original host-side exception was wrapped and was not captured. The junction-related resolution is confirmed for my setup; the precise native rejection mechanism, and whether other Windows reports share this cause, remain unverified.

It would help if Browser Use surfaced the underlying configuration read/refresh error and the rejected path, and if tests covered Windows junctions/reparse points in the browser-permission directory chain.

Update (2026-09-28 KST): After the user reconfigured browser control and opened a fresh ChatGPT tab, the official Chrome connection still listed the intended profile and returned that tab. Claiming/reading the tab through the documented browser API failed before any page content was returned, with the same Browser Use could not request permission / saved browser permissions could not be verified error. This reconfirms that extension communication and tab discovery work while the saved-permission check remains unavailable. No security controls were bypassed, and no private site URLs, credentials, or session data were accessed or included. We have not established the root cause.

Adding another Windows built-in browser reproduction.

Environment observed during reproduction

Windows desktop package: OpenAI.Codex 26.924.2738.0
Desktop release / bundled browser runtime: 26.924.22138
Tested through both the documented browser-client API and browser-scoped Computer Use inside the app. No external browser was needed to reproduce this.

Observed behavior

Browser discovery succeeds and identifies the in-app backend.
An existing, manually opened Wikipedia tab is listed with its correct title and URL.
Attempting to read that existing tab fails before page content is returned.
Creating a tab and navigating to the public browser documentation fails identically. Local development pages also failed.
The error is:

Browser Use could not complete this action because a browser security check was unavailable. Reason: Browser Use could not request permission. Browser use cannot access [origin redacted] because saved browser permissions could not be verified.

Recovery attempts that did not resolve it

Explicit user approval for all in-app browser use.
Full desktop-app restart, then a full computer restart.
Switching to another existing conversation and reopening the affected conversation.
Reinitializing the browser connection after restart.
Manually opening a page before the agent tries to read it.
Using the supported browser-scoped Computer Use tool.
The user reports Settings → Browser loads normally. They also report apparent success in another chat, but actual browser-tool access there has not been independently verified; we cannot yet establish that this is conversation-specific.

Read-only filesystem observation relevant to the comments above
The default user-profile .codex directory is a Windows directory junction targeting another drive. The browser and browser/sessions children themselves are ordinary directories. No junctions, permission files, approval policies or browser history were changed. This matches a reported configuration here, but we have not performed a controlled before/after repair, so it is not a confirmed root cause for this reproduction.

Correlated desktop logs
Logs report No ChatGPT browser route is available for browser session [redacted]. Other entries associate a saved conversation identifier with a client-new-thread:[redacted] browser owner/route. That association persisted after the recovery attempts. We have not established whether it causes the saved-permission failure or is a separate routing symptom.

This prevents automated review/testing of local application candidates even though manual browsing and tab discovery work. Could maintainers provide a supported recovery path for junction-backed Codex homes, preserving all saved allow/deny decisions, and expose the underlying permission-read failure instead of this generic message?

No security controls were bypassed. Local paths, usernames, drive targets, conversation/tab identifiers, private project details, credentials and raw logs are omitted.

Adding another Windows reproduction on the same release, with a junction-backed Codex home and a separately broken Chrome native-host path. The user explicitly requested this report. No private site URLs, local usernames, project details, credentials, browser contents, conversation identifiers, or raw logs are included.

Environment

Windows x64, Microsoft Store package OpenAI.Codex 26.924.2738.0.
Running desktop release 26.924.22138, build 11645.
Bundled Browser plugin 26.924.22138.
Bundled CLI 0.158.0-alpha.2.1.
Official Chrome extension 1.26.901.11451, installed and enabled in the selected profile.

Built-in browser: observed failure

The user can open a public website manually. The documented browser API successfully lists that existing tab and its title/URL. Reading accessibility state or requesting the state plus a screenshot fails with:

Browser Use could not complete this action because a browser security check was unavailable. Reason: Browser Use could not request permission. Browser use cannot access [origin redacted] because saved browser permissions could not be verified.

The origin appears as allowed in the settings UI, in the general configuration, and in the saved browser origin allowlist. A full user-performed app restart followed by fresh browser initialization did not resolve it. No screenshot/page content was returned.

Read-only filesystem checks confirm that %USERPROFILE%\.codex is a Windows directory junction to a real directory on another drive. The target's browser directory is an ordinary directory and its config.toml can be read normally. The permission store has not been moved, edited, or reset. This matches the layout reported in #48573 (comment) and #35310, but we have not performed a controlled repair and cannot claim the junction is the proven cause here.

Separate Chrome connection problem

Selecting Chrome returns Browser is not available: chrome, including while Chrome is running. The extension is installed/enabled, and the HKCU native-host registration and manifest exist. However, the manifest points to a nonexistent absolute executable:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

The user reinstalled the Chrome extension. They also clicked Reinstall extension in the desktop app's Google Chrome settings, which opened the already-installed official extension's store page. A subsequent check still found the native-host executable absent. Plugin loading diagnostics also report missing or invalid plugin.json for chrome@openai-bundled.

One diagnostic caveat: the bundled Node checker initially reported a missing registry key while subprocess execution was restricted. A direct PowerShell registry read confirmed that the key exists. We discarded that missing-key conclusion; the nonexistent executable is the confirmed observation.

Requested recovery guidance

Could maintainers provide a supported way to use an existing junction-backed Codex home via its real directory, preserving all saved permissions and data, and a supported recovery path for the missing bundled Chrome host when the UI's reinstall action only opens the extension store? Please expose the underlying permission-snapshot error so these failures can be distinguished.

Related: #49247 has the same desktop package and both visible errors. #22114 describes missing/incomplete Chrome plugin caches, but file-lock corruption has not been established on this installation.

No safety checks were disabled, no browser permission entries were broadened, and no native-host files or registrations were manually replaced.

Follow-up to my earlier Windows diagnostic: I found and repaired a separate bundled-marketplace configuration problem, but browser recovery is NOT yet confirmed.

Desktop package: 26.924.2738.0. Bundled plugins: 26.924.22138.

After explicitly setting CODEX_HOME to the existing physical data directory and restarting, both the process and user environment reflect that directory. Chrome selection still returns Browser is not available: chrome.

New evidence:

Desktop reconciliation repeatedly fails with marketplace 'openai-bundled' is already added from a different source; remove it before adding this source.
The saved marketplaces.openai-bundled.source retained the old extended-length path through the default home junction. Desktop now requests the physical path to its own generated .tmp/bundled-marketplaces/openai-bundled directory.
The bundled CLI's normal marketplace/plugin listing omitted the bundled plugins. Repeating the read-only listing with only that source overridden to the exact Desktop-requested path returned Browser, Chrome, and Computer Use. Persisting that one path correction, with a backup, restored the normal listing.
The current Chrome plugin cache was incomplete: its plugin manifest and native executable were missing. The old latest junction targeted an absent prior generation.
The app-bundled CLI's standard plugin add chrome@openai-bundled --json succeeded using Desktop's local generated marketplace. The restored manifest, browser client/service, and native executable match the local source by SHA-256.

Remaining issue: the registered Native Messaging manifest still points to the old latest path, which the plugin installer removed. Chrome remains unavailable while waiting for Desktop to reconcile its native-host registration. The official extension checker confirms the extension is installed and enabled. I have not manually installed the native host, changed its manifest/registry, patched binaries, changed browser permissions, or bypassed browser security controls.

This source-registration conflict matches #26366 and may explain why repeated extension reinstall attempts could not repair this installation. It is additional evidence about provisioning, not proof of the cause of the original saved-permissions error. Please consider migrating/canonicalizing the Desktop-owned marketplace source when CODEX_HOME changes and validating the native-host target after plugin repair.

Windows reproduction confirmed.

Environment

Windows 11 Pro
Codex Desktop: 26.924.2738.0
Codex CLI updated to 0.158.0

Observed behavior

Browser Use works normally on https://example.com.
https://script.google.com is detected correctly and Codex can identify the tab URL/title.
When page-content access is requested, Codex asks for permission normally.
After explicit user approval, the request fails with:

saved browser permissions could not be verified

The issue persists after restarting Codex and is not resolved by using another/new Codex chat.

codex doctor reports healthy local state/auth databases and working WebSocket connectivity. No script execution or page modification occurs before the Browser Use permission check fails.

This appears to be another Windows reproduction of the permission-verification failure described in this issue.

Confirmed Workaround

Affected setup: Windows, Codex Desktop 26.924.2738.0, bundled browser plugin 26.924.22138.
Fix stale ~\.codex\plugins\cache\openai-bundled\chrome\latest so it points to the current 26.924.22138 plugin directory.
Run the bundled scripts\installManifest.mjs using the current CUA node.exe / node_repl.exe and plugin app-server codex.exe. This regenerates extension-host-config.json and the native-messaging host registration.
Back up and rebuild both chrome-native-hosts-v2.json files with one current schema-v2 entry, using the current browser client/service, extension host, CUA Node runtime, Codex home, AppX resources path, and current browser-client.mjs SHA-256.
Restart Codex Desktop first, then Edge.
Confirmed result: Edge extension connects normally; Codex can enumerate, open, read, and interact with existing Edge tabs; internal browser also works.
The .codex junction/symlink did not need to be removed.

Adding a Windows reproduction that is still present on release 26.928.31416. This report covers repeated failures while testing and recording a local web app on October 1, 2026. I reviewed the recent Codex chats and checked the installed versions and directory layout.

Environment

Windows 11 Pro, x64, OS build 26300.
Microsoft Store package: OpenAI.Codex 26.928.3736.0.
Running desktop release: 26.928.31416, build 12553, release channel prod. The app's update check reports up_to_date.
Bundled Browser and Computer Use plugin caches: 26.928.31416. The Browser runtime used in the affected chats is from that version.
Running app-server executable reports codex-cli 0.159.2.
Installed browsers: Chrome 154.0.8037.58, Edge 154.0.4258.48. The main reproduction below uses the built-in browser and does not require either external browser.

Observed behavior

The documented Browser runtime initializes, selects the in-app browser, and can list tabs/create a tab. Attempting to navigate to http://localhost:8080 fails with:

Browser use cannot access http://localhost:8080 because saved browser permissions could not be verified.

A separate request to https://example.com returns the same saved-permissions error. Repeating both requests still fails. This is therefore not limited to the local web app.

The failure occurred across several chats, including a fresh chat created specifically to retry the recording. It blocks UI testing and demo recording. The local frontend, API and workers had separately been started and checked; completed application-generated videos existed, but Codex could not record the UI.

Recovery attempts

Reinstalled the project dependencies.
Uninstalled and reinstalled the Browser plugin.
Restarted the desktop app multiple times.
Restarted the computer multiple times.
Reinitialized the documented Browser runtime after restart.
Reopened the existing chat and tried a fresh chat.
Explicitly tagged the Browser plugin and retried.
Tested a public site to rule out a localhost-only failure.

The reinstall and repeated restart attempts are user-reported. The affected chats document fresh-chat, runtime reinitialization, post-restart and public-site retries. None restored browser access.

An earlier chat also reported an unavailable Edge connection bridge. Standalone Playwright could launch Edge and Chrome on a blank page, but this did not establish that Codex Browser permissions were repaired.

Read-only diagnostic findings

The default %USERPROFILE%\.codex is a Windows directory junction to a physical directory on another drive. The physical Codex home, browser, and browser/sessions are ordinary directories. This matches the directory layout discussed above, but we have not performed a controlled before/after repair and cannot attribute the failure to the junction.

The affected chats also captured desktop logs containing No ChatGPT browser route is available for browser session [redacted]. Browser owner/host entries retained a client-new-thread:[redacted] identifier while the app route referenced a saved chat. This persisted after a restart. The relationship between this routing observation and permission verification remains unproven.

I read the reports of symlink/junction repairs, stale native-host registration, and the Edge workaround that retained the junction. Those suggest several possible causes; that workaround has not been applied or verified on this installation.

Could maintainers provide a supported recovery procedure for this newer release that preserves saved permissions and chat data, and expose the underlying permission-read or routing exception?

This report omits local usernames, drive targets, chat/tab IDs, credentials, private app content and raw logs. No browser security checks were bypassed during this investigation.

Follow-up to my earlier report: built-in browser access is now verified working after repairing the Codex home/marketplace paths and the incomplete Chrome plugin installation, then restarting the desktop app.

Environment remains Windows 11 Pro x64, desktop release 26.928.31416, build 12553, Store package 26.928.3736.0, and bundled CLI 0.159.2.

Additional findings

CODEX_HOME was unset. The default %USERPROFILE%\.codex was a directory junction to an existing physical directory on another drive.
The desktop logs repeatedly reported marketplace openai-bundled is reserved and cannot be added from this source, followed by bundled_plugins_reconcile_failed. Normal plugin listing still showed the bundled plugins, so listing alone did not establish that desktop reconciliation was healthy.
Chrome plugin 26.928.31416 was listed as installed/enabled, but its cache lacked .codex-plugin/plugin.json, the browser client/service, installation script, and Windows host executable. Those files existed in the desktop-generated bundled marketplace source.
Chrome extension 1.26.901.11451 was installed and enabled. Its native-messaging registry key existed, but the referenced manifest file was missing.
The saved host registry contained an old 26.818.61809 entry with several nonexistent executable/runtime/resource paths.

Repair performed

Backed up the configuration, saved native-host registration files, incomplete Chrome cache, and previous user environment value.
Ran the bundled CLI's normal plugin add chrome@openai-bundled --json against the existing desktop-generated marketplace. This restored the missing files. SHA-256 checks confirmed that the restored manifest, browser client/service, installation script, and host executable matched the bundled source.
Set the Windows user-level CODEX_HOME to the existing physical Codex data directory.
Changed only marketplaces.openai-bundled.source in config.toml to the canonical physical path for that same generated marketplace. The stored Windows path includes the \\?\ prefix. A parsed configuration comparison confirmed that no other setting changed.
Fully quit and reopened the desktop app.

A diagnostic child process using the physical home first cleared the reserved-source rejection but reported a conflict with the old saved marketplace source. After correcting the source, plugin marketplace add succeeded with alreadyAdded: true.

The original home junction was retained. No data was relocated or deleted, browser permission decisions were not edited, and no native-host installer script or registry rewrite was run manually.

Verified after restart

The running process now uses the physical CODEX_HOME.
Desktop logs show the bundled marketplace added successfully and bundled_plugins_reconcile_completed.
The app regenerated the missing native-host manifest. The official checker reports correct: true, and its executable exists.
The app generated a current 26.928.31416 host entry using the physical home and existing client/host paths. The old entry remains; it was not manually purged.
Through the supported in-app browser interface, Codex opened and read https://example.com, clicked “Learn more,” and read the destination at IANA. The previous saved-permissions error did not occur.

Chrome was closed during verification, so live Chrome extension control is not yet verified. The local application servers were also stopped, so localhost UI testing has not been repeated.

This is a successful recovery for this installation using several related repairs; it does not isolate which change fixed the built-in permission check. It supports investigating junction/physical-path consistency and bundled plugin provisioning together. The app should expose the underlying permission-read error and validate native-host targets and plugin-cache completeness during reconciliation.

Local usernames, actual drive targets, chat/tab identifiers, credentials, private app content, and raw logs are omitted.

Additional reproduction on Windows 10 Pro 22H2 (build 19045.6466), Codex Desktop package 26.1002.7124.0, official bundled Chrome/browser components 26.1002.52244.

Verified behavior

cua.getState() successfully lists connected Chrome profiles and existing tabs.
Binding an existing AppSheet tab with cua.getTab(...) fails before returning page content.
A separate public-site test using cua.createBrowserTab(browserId, "https://example.com") fails with the same permission-verification error. This is not limited to the authenticated business site.

Exact error for the public-site test:

Browser Use could not complete this action because a browser security check was unavailable. Reason: Browser Use could not request permission. Browser use cannot access https://example.com because saved browser permissions could not be verified. Please try again later. This failure may be temporary.

Checks and recovery attempts

User authorized browser access; user reports the problem persists in a new Codex chat.
Windows sandbox configuration is currently [windows] sandbox = "unelevated".
An earlier, distinct elevated-sandbox failure was helper_unknown_error: setup refresh had errors. Its log showed an ACL update for node_repl.exe failing with Windows sharing violation os error 32. Browser inventory now succeeds, while page permission verification still fails; these should not be treated as one proven root cause.
Codex data and Chrome user data are on an H: NTFS drive via junctions. The junction destinations exist, and config reads through the original and destination paths have identical hashes.
Windows AppData itself and the running Chrome executable remain on C:.
The Chrome native-messaging registry entry, its manifest file, and its referenced host executable exist. This is a file/registry existence check, not a complete native-host protocol validation.
Desktop logs include MCP startup/handshake failures, including cua_repl, but no matching detailed explanation of the current saved-browser-permission failure was found in the logs inspected. No causal conclusion is claimed.

Expected: verify saved permission or present an actionable approval prompt. Please provide a supported recovery path and clarify which component is unavailable, rather than only advising a retry later.

No security checks were bypassed. No raw logs, cookies, tokens, personal profile names, private app URLs/IDs, or conversation IDs are attached. Submitted on behalf of the affected user with their explicit authorization.

Navigation Menu

Repository navigation

[Windows] Browser Use lists correct Chrome tabs but cannot request permission / verify saved browser permissions #48573

Summary

Environment

Reproduction

Checks completed

Correlated log evidence (not a proven cause)

Expected behavior

Environment

Built-in browser: observed failure

Separate Chrome connection problem

Requested recovery guidance

Confirmed Workaround

Environment

Observed behavior

Recovery attempts

Read-only diagnostic findings

Additional findings

Repair performed

Verified after restart

Verified behavior

Checks and recovery attempts

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows] Browser Use lists correct Chrome tabs but cannot request permission / verify saved browser permissions #48573

Description

Summary

Environment

Reproduction

Checks completed

Correlated log evidence (not a proven cause)

Expected behavior

Activity

github-actions commented on Sep 26, 2026

AdamSpore commented on Sep 27, 2026

routerpipe-byte commented on Sep 27, 2026

soju1982game1-cpu commented on Sep 27, 2026

byronbuzz commented on Sep 28, 2026

jorgeparedes93 commented on Sep 29, 2026

Environment

Built-in browser: observed failure

Separate Chrome connection problem

Requested recovery guidance

jorgeparedes93 commented on Sep 30, 2026

elsfamily-bit commented on Sep 30, 2026

byronbuzz commented on Sep 30, 2026

Confirmed Workaround

M0inUddin commented on Oct 1, 2026

Environment

Observed behavior

Recovery attempts

Read-only diagnostic findings

M0inUddin commented on Oct 1, 2026

Additional findings

Repair performed

Verified after restart

ts-951663 commented on Oct 8, 2026

Verified behavior

Checks and recovery attempts

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions