›_ Codex Issues
Codex Issues / #19570

After upgrading Codex Desktop today, two Codex local runtime features are broken.

Open 💬 4 comments Opened Apr 25, 2026 by thenie1221
💡 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)?

Codex Desktop package: OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0 App version from logs: 0.125.0-alpha.3

What subscription do you have?

plus

What platform is your computer?

_No response_

What issue are you seeing?

After upgrading Codex Desktop today, two Codex local runtime features are broken.

Environment:

  • Windows
  • Codex Desktop log shows app.version=0.125.0-alpha.3
  • Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1
  • Workspace: E:\job-picc\ebs-shop-backend\ebs-trade-service

Issue 1: bundled workspace dependencies fail to install
Steps:

  1. Call load_workspace_dependencies()
  2. It returns: No bundled workspace runtime dependencies are configured yet. Call install_workspace_dependencies() to install them.
  3. Call install_workspace_dependencies()
  4. It fails with: Failed to install workspace dependency runtime.

Issue 2: Browser Use in-app browser cannot navigate to external URL
What works:

  • setupAtlasRuntime({ backend: "iab" }) succeeds
  • agent.browser.nameSession(...) succeeds
  • agent.browser.tabs.new() succeeds and creates about:blank

What fails:

  • tab.goto("https://www.bing.com/search?q=bilibili")

Error:
failed to start codex app-server: 系统找不到指定的路径。 (os error 3)

Notes:

  • In-app browser is open, current URL is not navigated/about:blank.
  • System global Node works: C:\Program Files\nodejs\node.exe, v22.22.2.
  • System Python alias was disabled; no global Python is currently resolved.
  • This does not look project-specific. It looks like Codex Desktop app-server / bundled dependency runtime path is broken after upgrade.

What steps can reproduce the bug?

Steps to reproduce:

  1. Start Codex Desktop on Windows.
  2. Open a Codex session with the Browser Use plugin enabled.
  3. Run the workspace dependency check:

load_workspace_dependencies()

Actual result:
No bundled workspace runtime dependencies are configured yet. Call install_workspace_dependencies() to install them.

  1. Run:

install_workspace_dependencies()

Actual result:
Failed to install workspace dependency runtime.

  1. Test Browser Use in the in-app browser with:

const { setupAtlasRuntime } = await import("C:/Users/admin/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis, backend: "iab" });
await agent.browser.nameSession("repro");
globalThis.tab = await agent.browser.tabs.new();
await tab.goto("https://www.bing.com/search?q=bilibili");

Actual result:
failed to start codex app-server: 系统找不到指定的路径。 (os error 3)

Expected result:

  • install_workspace_dependencies() should install/configure the bundled workspace runtime successfully.
  • Browser Use should be able to navigate the in-app browser to an external HTTPS URL.

Environment:

  • OS: Windows
  • Codex Desktop package: OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0
  • App version from logs: 0.125.0-alpha.3
  • Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1

Notes:
This started after upgrading Codex Desktop. The Browser Use plugin can initialize and create an about:blank tab, but external navigation fails when Codex tries to start the app-server. This does not appear to be project-specific.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19562
  • #19450
  • #19298
  • #19477
  • #19423

Powered by Codex Action

neill-k · 4 months ago

87f0a397-6f2c-4804-b829-4945a088dae1

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).

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop local runtime recovery: https://github.com/zemeng5208/winbridge-recovery

This report is useful because two local runtime-dependent features broke together after the Desktop upgrade: bundled workspace dependency installation and Browser Use external navigation. That makes stale/missing user-side runtime/helper state worth checking before treating the failures as unrelated.

WinBridge v3.1.1 resolves the current installed AppX package/runtime first, validates user-owned CLI/Node REPL/helper paths and stale version/hash references, verifies the official bundled resources, and can reconstruct inconsistent local runtime state through staged copies with SHA-256 checks and rollback data. The linked workaround in this issue family — restoring the expected %LOCALAPPDATA%\OpenAI\Codex\bin path from the already installed official package/cache — is exactly the type of recovery the tool is intended to make safer and version-aware.

It will not claim to repair a separate workspace-runtime product incompatibility if the local helper paths are already healthy, and it does not modify WindowsApps ownership/ACLs or bypass sandbox/policy.