Windows Codex app: Browser plugin can attach to tab, but DOM/screenshot APIs fail because codex app-server cannot start

Resolved 💬 5 comments Opened May 1, 2026 by CheddarNines Closed Aug 4, 2026

💡 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)?

OpenAI.Codex 26.429.2026.0, bundled codex.exe reports FileVersion/ProductVersion 0.128.0-alpha.1

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Windows desktop app's in-app Browser plugin partially works, but its main inspection features fail.

Codex can attach to the selected in-app browser tab and read the tab URL/title. However, DOM snapshot, screenshot, and visible DOM APIs all fail with:

failed to start codex app-server: The system cannot find the path specified. (os error 3)

Observed successful browser calls:

tab.url()
tab.title()

Observed failing browser calls:

tab.playwright.domSnapshot()
tab.playwright.screenshot({ fullPage: false })
tab.dom_cua.get_visible_dom()

Related local evidence:

Get-Command codex resolves to:

C:\Program Files\WindowsApps\OpenAI.Codex_26.429.2026.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Running codex --version from integrated PowerShell fails with:

Program 'codex.exe' failed to run: Access is denied

Running codex app-server --help from integrated PowerShell fails with:

Program 'codex.exe' failed to run: Access is denied

Running the packaged node_repl.exe directly also fails with:

Program 'node_repl.exe' failed to run: Access is denied

What steps can reproduce the bug?

Install/open Codex Windows desktop app from Microsoft Store.
Enable/use the bundled Browser plugin.
Open the in-app Browser.
Navigate to a page in the in-app Browser.
In Codex, initialize the Browser plugin runtime with backend: "iab".
Select the current browser tab.
Confirm these calls work:

tab.url()
tab.title()

Then call any of:

tab.playwright.domSnapshot()
tab.playwright.screenshot({ fullPage: false })
tab.dom_cua.get_visible_dom()

Minimal reproduction snippet used inside Codex Node REPL:

if (!globalThis.agent) {
const { setupAtlasRuntime } = await import("C:/Users/dan/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/scripts/browser-client.mjs");
const backend = "iab";
await setupAtlasRuntime({ globals: globalThis, backend });
}
await agent.browser.nameSession("Browser bug evidence");
if (typeof tab === "undefined") {
globalThis.tab = await agent.browser.tabs.selected();
}

const out = {};
out.url = await tab.url();
out.title = await tab.title();

try {
await tab.playwright.domSnapshot();
out.domSnapshot = "ok";
} catch (e) {
out.domSnapshot = String(e && e.message ? e.message : e);
}

try {
await tab.playwright.screenshot({ fullPage: false });
out.screenshot = "ok";
} catch (e) {
out.screenshot = String(e && e.message ? e.message : e);
}

try {
await tab.dom_cua.get_visible_dom();
out.visibleDom = "ok";
} catch (e) {
out.visibleDom = String(e && e.message ? e.message : e);
}

nodeRepl.write(JSON.stringify(out, null, 2));

Observed output:

{
"url": "[redacted authenticated Salesforce sandbox URL]",
"title": "Profile - My ADA profile - ADA Portal Original",
"domSnapshot": "failed to start codex app-server: The system cannot find the path specified. (os error 3)",
"screenshot": "failed to start codex app-server: The system cannot find the path specified. (os error 3)",
"visibleDom": "failed to start codex app-server: The system cannot find the path specified. (os error 3)"
}

I do not know the session id, token limit usage, or context window usage.

What is the expected behavior?

The Browser plugin should be able to start the required codex app-server/helper process and return DOM snapshots, screenshots, and visible DOM data from the selected in-app browser tab.

At minimum, the following should work after attaching to the selected in-app browser tab:

tab.playwright.domSnapshot()
tab.playwright.screenshot({ fullPage: false })
tab.dom_cua.get_visible_dom()

Additional information

This appears related to Windows desktop/MSIX package execution issues where bundled executables under C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\... are visible but cannot be launched from the integrated PowerShell/helper context.

Local evidence:

where.exe codex returns:
C:\Program Files\WindowsApps\OpenAI.Codex_26.429.2026.0_x64__2p2nqsd0c76g0\app\resources\codex
C:\Program Files\WindowsApps\OpenAI.Codex_26.429.2026.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Get-Command codex shows:
Path: C:\Program Files\WindowsApps\OpenAI.Codex_26.429.2026.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
Version: 0.128.0.0
FileVersion: 0.128.0-alpha.1
ProductVersion: 0.128.0-alpha.1

Integrated PowerShell results:

codex --version -> Access is denied
codex app-server --help -> Access is denied
direct packaged node_repl.exe --version -> Access is denied

The app itself opens and basic Codex shell commands work, so this is not a total app launch failure. The failure appears specific to launching packaged helper/app-server executables needed by Browser inspection features.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

#20354
#20206
#20048
#19423
#19298

Powered by Codex Action

CheddarNines · 3 months ago

This does appear to be a duplicate of #20354 / #20206 / #20048 / #19423 / #19298.

One useful extra data point from my report: this still reproduces on the newer Microsoft Store package OpenAI.Codex 26.429.2026.0, bundled codex.exe FileVersion/ProductVersion 0.128.0-alpha.1, on Microsoft Windows NT 10.0.26200.0 x64.

Same shape:

Browser Use IAB can read selected tab URL/title.
tab.playwright.domSnapshot(), tab.playwright.screenshot({ fullPage: false }), and tab.dom_cua.get_visible_dom() fail with:

failed to start codex app-server: The system cannot find the path specified. (os error 3)

Packaged WindowsApps codex.exe and node_repl.exe fail from integrated PowerShell with Access is denied.

Closing this as duplicate.

KeroZelvin · 3 months ago

I am seeing a related failure on Windows Codex Desktop after repair, reboot, uninstall/reinstall, sandbox cache cleanup, and reboot again.

Codex app package observed after reinstall:
OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0

Browser plugin behavior:

setupAtlasRuntime({ backend: "iab" }) succeeds
agent.browser.tabs.new() succeeds
tab.url() / tab.title() on about:blank succeed
tab.goto("http://192.168.4.202:3000/") fails

Error:

failed to start codex app-server: The system cannot find the path specified. (os error 3)

Node REPL environment probe:

nodeRepl.cwd = D:\Git\redacted
nodeRepl.tmpDir = C:\Users\redacted\AppData\Local\Temp
process.cwd() = /
PATH = null
CODEX_HOME = null
APPDATA = null
LOCALAPPDATA = null
USERPROFILE = null
Local remediation tried:

Closed/reopened Codex
Killed lingering Codex / node_repl / command-runner processes
Windows app Repair
Full Windows reboot
Uninstalled/reinstalled Codex Desktop
Removed stale C:\Users\redacted\.codex\.sandbox-bin\codex.exe version 0.116.0-alpha.10
Rebooted again after cache cleanup
After cleanup, .sandbox-bin only contains:

codex-command-runner-0.128.0-alpha.1.exe
The issue still reproduces. It looks like the Browser Node REPL/app-server launch context is missing the normal Windows environment variables, which prevents codex app-server from starting.

https://openai.com/ fails the same way.

Result:

about:blank tab creation: works
navigation to https://openai.com/: fails
error: failed to start codex app-server: The system cannot find the path specified. (os error 3)
tab remains: about:blank
The REPL environment is still the same broken state:

process.cwd() = /
PATH = null
CODEX_HOME = null
APPDATA = null
LOCALAPPDATA = null
USERPROFILE = null
So this is definitely not specific to http://192.168.4.202:3000/ or the LAN/server. Any browser navigation through the Browser plugin is blocked by the app-server startup/runtime issue.

ahostbr · 3 months ago

Cross-linking a local workaround that fixed this same Windows Codex Desktop / Browser Use failed to start codex app-server: ... (os error 3) failure here: https://github.com/openai/codex/issues/19562#issuecomment-4356858649

On my machine, %LOCALAPPDATA%\OpenAI\Codex\bin was expected/on the Desktop path but missing. The helper binaries already existed at:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin

Creating a junction from the expected path to the packaged helper-bin path fixed Browser Use / in-app browser control:

$target = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin"
$link = "$env:LOCALAPPDATA\OpenAI\Codex\bin"

if (!(Test-Path $target)) { throw "Target not found: $target" }

New-Item -ItemType Directory -Force -Path (Split-Path $link) | Out-Null
if (!(Test-Path $link)) {
    New-Item -ItemType Junction -Path $link -Target $target
}

After adding the junction and retrying in Codex Desktop, Browser Use could attach to the selected in-app browser tab, navigate to external pages, read DOM snapshots, click links, and continue navigating.

This may not cover every Windows Browser Use failure, but it looks relevant when the IAB backend can initialize/list tabs and then navigation/DOM/screenshot work fails with failed to start codex app-server: ... (os error 3).

CheddarNines · 3 months ago

Update with clean Windows 11 VM reproduction + workaround testing

I reproduced the Browser Use failure on a clean Hyper-V Windows 11 VM, then tested the workaround suggested by @ahostbr.

Clean VM environment

Fresh Windows 11 24H2 Hyper-V Gen 2 VM
Fully updated Windows install
Local admin account, no Microsoft account dependency for the lab user
Codex Desktop installed from Microsoft Store
Visual C++ Redistributables x64 + x86 installed
This was needed to resolve an initial Codex crash:

code=3221225781 / 0xC0000135

Python 3.14.4 installed system-wide:

C:\Program Files\Python314\python.exe

Git 2.54.0.windows.1
Node.js 24.15.0 LTS
npm 11.12.1
Project folder:

C:\Projects\codex-browser-smoke-test

Initial Browser Use smoke test

Target:

a public facing page on the web

Test conditions:

Read-only Browser Use test
Approved node_repl MCP tool js for the chat
Did not use Playwright, curl, requests, Invoke-WebRequest, or any fallback browser method
Did not modify system settings, PATH, registry, firewall, services, browser settings, etc.

Initial result:

failed to start codex app-server: The system cannot find the path specified. (os error 3)

Browser Use failed before navigation. No URL/title/screenshot/DOM/visible DOM could be collected.

Tested @ahostbr workaround

I tested the workaround described by @ahostbr: creating a junction from the expected helper-bin path to the packaged helper-bin path.

The packaged helper binaries existed here:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin

The expected path was missing:

%LOCALAPPDATA%\OpenAI\Codex\bin

I created the junction manually in normal, non-admin PowerShell:

$target = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin"
$link = "$env:LOCALAPPDATA\OpenAI\Codex\bin"

if (!(Test-Path $target)) { throw "Target not found: $target" }

New-Item -ItemType Directory -Force -Path (Split-Path $link) | Out-Null
if (!(Test-Path $link)) {
    New-Item -ItemType Junction -Path $link -Target $target
}

The junction was created successfully.

Result after junction workaround, restricted/sandboxed mode

After the junction, the failure changed, but Browser Use still did not work under the normal restricted/sandboxed mode.

New error:

node_repl kernel exited unexpectedly

node_repl diagnostics: {"kernel_pid":1608,"kernel_status":"exited(code=1)","kernel_stderr_tail":"windows sandbox failed: runner error: CreateProcessAsUserW failed: 5","reason":"stdout_eof","stream_error":null}

After a full VM reboot, the restricted/sandboxed test still failed with essentially the same Windows sandbox/process-launch error:

node_repl kernel exited unexpectedly

node_repl diagnostics: {"kernel_pid":10564,"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: runner error: CreateProcessAsUserW failed: 5","reason":"stdout_eof","stream_error":null}

There was also an additional sandbox-related failure while reading the local project file:

windows sandbox: CreateProcessWithLogonW failed: 1056

Full access / full computer control diagnostic test

I then ran the same read-only Browser Use smoke test with temporary full computer control/full access enabled for that diagnostic session.

Result: PASS

Browser Use successfully:

initialized
navigated to a live site https://tXXXXXXXXXes.com/
read final URL
read page title
captured screenshot
captured DOM snapshot
captured visible DOM
inspected linked stylesheet URLs

Observed page title:

The page title matched the test page (a Joomla site)

Linked stylesheet URLs included:

/media/system/css/joomla-fontawesome.min.css?19cb5f
/media/templates/site/cassiopeia/css/template.min.css?19cb5f
/media/templates/site/cassiopeia/css/global/colors_standard.min.css?19cb5f
/media/templates/site/cassiopeia/css/vendor/joomla-custom-elements/joomla-alert.min.css?0.4.1
/media/templates/site/cassiopeia/css/user.css?19cb5f

No Browser Use errors occurred in full-access mode.

Current interpretation

The @ahostbr junction workaround appears relevant and changed the failure mode from:

failed to start codex app-server: The system cannot find the path specified. (os error 3)

to a later Windows sandbox/process-launch failure:

CreateProcessAsUserW failed: 5

However, in my test it was not sufficient by itself under normal restricted/sandboxed mode.

The successful full-access test strongly suggests the remaining failure is related to the Windows/Codex sandbox boundary rather than the target website, network, Node.js installation, Python setup, or the VM itself.

Important caveat: I did not separately test full-access mode without the junction workaround, so I cannot say with 100% certainty whether the junction is required for the full-access success (It very likely is needed based on the first error).
What I can say is:

Clean VM reproduced os error 3.
The junction workaround changed the failure mode.
Restricted/sandboxed Browser Use still failed after the workaround and reboot.
Full-access Browser Use passed after the workaround.
The remaining blocker appears to involve the Windows sandbox/process launch path.