Skip to content

Windows MSIX: Dots connected-computer tasks lack browser and session tools; generated app-tools working directory points outside virtualised app data #49562

Open
Open
Windows MSIX: Dots connected-computer tasks lack browser and session tools; generated app-tools working directory points outside virtualised app data#49562
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingcomputer-usedotsIssues involving setting up ChatGPT dots or managing their ongoing work.mcpIssues related to the use of model context protocol (MCP) serversremotewindows-osIssues related to Codex on Windows systems

Description

@n-pinkerton
n-pinkerton
opened on Sep 30, 2026

Expected behaviour

A dot connected to an authorised, online Windows PC can expose the supported browser and local Codex session tools in its local tasks. The same computer's ordinary desktop-local task can initialise those tools.

Environment

ChatGPT Pro personal account. Windows x64. ChatGPT MSIX OpenAI.Codex 26.928.2636.0; internal build 26.928.21956; bundled Codex CLI 0.159.2. Independent CLI 0.159.0. Edge extension installed and enabled; browser extension works from a separate existing setup task. Current official Windows download and Store report no newer available package. This is a personal account; the enterprise local-access guide names 26.929 as its minimum, while the consumer Dots guide gives no explicit desktop minimum.

Observed behaviour

  1. The dot's original personal-computer connection is authorised and online. Local shell/file access works, including a fresh marker read.
  2. Edge is installed and enabled in Settings > Computer use, but absent from the affected task's mention menu. Browser and unified-computer-use plugins are enabled. Repeatedly checking the toggle is not a remedy.
  3. The original desktop log repeatedly records both cua_repl and codex_app starting then failing within approximately 0.5 seconds on hostId=durable. It reports only 'MCP server failed to start.' A desktop-local control task records both as ready. The dot's own cloud browser is a different working environment.
  4. Generated codex_app .mcp.json specifies this cwd:
    %APPDATA%\Codex\web\Codex\executor-plugins\codex-app-tools
    The configured directory was absent. The files actually existed at:
    %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\executor-plugins\codex-app-tools
    An ordinary cmd.exe directory check of the configured path reproduced 'The system cannot find the path specified.' The physical directory contains server.mjs and scripts/launch_codex_app_tools_mcp.cmd. This proves a generated path fault; it does not independently establish the browser failure's cause.
  5. During an approved idle maintenance window, a direct executable launch created the nominal directory but used a separate app-data location and registered a second, unauthorised computer connection. That launch was rolled back to registered Windows package activation. The original authorised connection returned online; the duplicate was not authorised or used for work.
  6. After restoring the original activation, the dot created one fresh bounded read-only diagnostic on that original connection. It reported zero exposed cua_repl and codex_app tools, no Node REPL, and no supported browser or session inventory tools. It performed no fallback launch, shell diagnostics, configuration changes or agent messages. This did not verify a repair.
  7. The bundled Node runtime runs successfully with --version, including from the packaged app directory. A failed Node executable launch is not reproduced here.

Redacted original log examples

2026-09-30T09:34:50.392Z info mcp_server_startup_status_updated hostId=durable server=cua_repl status=starting
2026-09-30T09:34:50.392Z info mcp_server_startup_status_updated hostId=durable server=codex_app status=starting
2026-09-30T09:34:50.862Z warning mcp_server_startup_status_updated hostId=durable server=cua_repl status=failed error='MCP server failed to start.'
2026-09-30T09:34:50.863Z warning mcp_server_startup_status_updated hostId=durable server=codex_app status=failed error='MCP server failed to start.'

Separate issue, not offered as the explanation for missing browser tools

Independent running CLI sessions do not currently share an app-server daemon. Auto-start was deliberately disabled following an earlier Windows terminal-popup regression. The supported queue command requires a shared server; starting another server does not prove safe ownership of those already-running sessions. They have been preserved. CLI 0.159.2 contains a console-suppression fix, but adoption requires a supported safe-checkpoint transition and delivery test.

Actions avoided

No reset/reinstallation of app data; no auth/profile copying; no native-host repair; no signed app or browser-plugin patch; no hidden API client; no direct live-session database writes; no browser moves/restarts; no interruption or duplication of fleet work. Low disk space was addressed by moving only two setup-downloaded installers with hash verification, but that did not restore the missing tools.

Request to maintainers

Please confirm personal Pro support for Windows local Dots browser/session tools in this package and identify a supported fixed package or repair. Check whether the MSIX virtualised user-data path is being exported as an ordinary non-virtualised cwd/plugin root to the standalone local executor. Please also expose the actual local MCP startup cause rather than only the generic failure.

Related public reports, not asserted duplicates

#26907
#21301
#33947

Official references

https://learn.chatgpt.com/docs/dots/computers-and-apps
https://learn.chatgpt.com/docs/enterprise/cloud-local-access
https://learn.chatgpt.com/docs/reference/troubleshooting

No credentials, private account/project details or raw diagnostic archives are included. The generated path defect is confirmed; causal attribution of the entire missing-tool failure remains a hypothesis.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    mcpIssues related to the use of model context protocol (MCP) servers
    remote
    browser
    computer-use
    on Sep 30, 2026

  2. github-actions commented on Sep 30, 2026

    @github-actions
    github-actionsbot
    on Sep 30, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. DDDFXYqiming commented on Sep 30, 2026

    @DDDFXYqiming
    DDDFXYqiming
    on Sep 30, 2026 – with ChatGPT Codex Connector

    I'm seeing the same OpenAI Dot versus ordinary local Codex tool gap on Windows, though the missing-directory condition didn't reproduce here.

    Package 26.928.1915.0, internal version 26.928.20755, bundled CLI 0.159.0. The generated codex_app config is enabled, and its cwd, launcher, server.mjs and Node executable are all visible from the diagnostic shell. A manually opened local chat successfully reads an existing chat; the Dot-created task has six correlated codex_app startup failures. The logs only say “MCP server failed to start.”

    I've put the fuller findings in #49488. This seems worth comparing before treating the MSIX path issue as the cause of every missing-tool case. We haven't found a working repair.

  4. juanbstevens commented on Sep 30, 2026

    @juanbstevens
    juanbstevens
    on Sep 30, 2026

    Additional Windows observation using the new Dot agent, September 30, 2026:

    • Desktop package: 26.928.2636.0
    • Browser/Computer Use bundle: 26.928.21956
    • Edge ChatGPT extension: 1.26.901.11451

    A local desktop chat successfully opened and inspected an Edge page, clicked a link, and captured a screenshot. Native desktop control also passed in VLC. This chat could list and read other chats.

    The affected workflow uses the new Dot agent, which delegated the retest to a separate chat.

    That cloud-coordinated delegated chat could execute commands on the connected Windows computer and read installed skill documentation, but reported no node_repl, browser-control, or screen-capture tools in its tool inventory. It therefore could not attempt the browser test.

    Changing the affected chat’s permissions did not restore control. The coordinating agent also reportedly could not read other chats; the exact blocker for that additional symptom has not yet been verified.

    The symptoms match this report, but we have not verified a generated-path defect or established the cause in this setup.

    Please clarify which desktop capabilities Dot-delegated chats should receive, and how to diagnose or refresh missing tools when a local desktop chat works.

  5. MisterRound commented on Oct 1, 2026

    @MisterRound
    MisterRound
    on Oct 1, 2026 – with ChatGPT Codex Connector

    We reproduced the native export-path problem and isolated a second, independent startup failure after the configured cwd was made reachable. Full sanitized RCA and current-build A/B evidence: #49820.

    On Desktop 26.928.31416 (Store package 26.928.3736.0, bundled agent 0.159.2), the generated app-tools launcher still starts without SystemRoot under the reproduced Unix-controller environment allowlist. The official owned native executor starts the process, but bundled Node exits before MCP initialize. Restoring only launcher-local SystemRoot makes the identical test pass initialize and tools/list, returning all 55 app-control tools.

    Earlier, the actual Dot worker also received those controls and successfully read/messaged an existing local Desktop chat after the path and environment repairs. The app update regenerated the launcher and removed the local guard; we reproduced the startup failure again and restored the guard. No Desktop/WSL/browser restart, global environment change, permission expansion, or interruption of other agents was required.

    This does not establish a fix for direct Chrome/CUA exposure, and it does not mean all missing-tool reports have the same cause. It also does not assume a previously failed MCP client refreshed merely because an isolated startup/catalog test passed.

    The upstream request in #49820 is to choose essential environment variables for the executor OS, not the controller build target, and to expose the actual startup exit/stderr cause. Fixing only the MSIX cwd, or checking only that node --version works, can miss this second failure.

  6. alecwardd commented on Oct 1, 2026

    @alecwardd
    alecwardd
    on Oct 1, 2026

    Additional reproduction: a path-only bridge does not restore the tools (package 26.928.3736.0)

    Environment: Windows 11 Pro x64 (10.0.26200). Microsoft Store package OpenAI.Codex 26.928.3736.0, browser/computer-use bundle 26.928.31416, bundled CLI 0.159.2. Personal ChatGPT account with a dot connected to this PC.

    1. Same generated cwd defect. The generated codex_app .mcp.json sets cwd to %APPDATA%\Codex\web\Codex\executor-plugins\codex-app-tools. Checked from an ordinary, unpackaged PowerShell session, %APPDATA%\Codex does not exist. The files exist under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\executor-plugins\codex-app-tools.

    2. Why some reports find the directory present. A diagnostic shell launched by a Codex task on this machine (sandbox user, no package identity) reported the nominal path as existing. Opening the files by handle showed the nominal path and the package LocalCache copy have identical file IDs (link count 1). So processes in the app's tree see a redirected view, and "directory exists" checks run from inside a Codex task can pass even when the defect is present. The check needs to come from a process outside the app.

    3. Path-only bridge test. I created a directory junction at the nominal executor-plugins path pointing to the package LocalCache copy and verified its target. Then the dot created a fresh connected-computer task. Its tool inventory still contained no cua_repl and no codex_app tools, only the codex_apps connector tools. The junction was removed after the test. This matches #49820: fixing the cwd alone is not sufficient, and the separate SystemRoot environment failure would still stop the launcher.

    4. The failures follow where the task runs. Across six dot-created tasks on this machine, every task whose environment is the connected Windows PC logs codex_app and cua_repl as failed. Tasks running on the dot's cloud computer log cua_repl as ready. Over Sept 30 to Oct 1 (UTC), codex_app never reached ready for a PC task (0 ready, 50+ failed status rows; these are status rows, not unique launches). Ordinary local Desktop threads were ready every time.

    5. Logging gap. After a Desktop restart, a newly created dot task produced no mcp_server_startup_status_updated rows at all, so log-based verification isn't dependable. +1 to the request to surface the real exit code and stderr.

    Representative log rows (UTC):

    2026-10-01T09:52:09.724Z hostId=durable server=cua_repl status=starting
2026-10-01T09:52:09.724Z hostId=durable server=cua_repl status=failed error="MCP server failed to start." failureReason=null
2026-10-01T09:52:09.732Z hostId=durable server=codex_app status=failed error="MCP server failed to start." failureReason=null

    The separate AbsolutePathBuf deserialized without a base path follow-up failure also reproduces here (#49477, #49488). I've added a permission-preset observation for it on #49477.

    No credentials, account or chat IDs, usernames, or machine names are included. No package files, permissions, or global environment variables were changed, and the junction was removed after the test.

  7. etraut-openai
    added
    dotsIssues involving setting up ChatGPT dots or managing their ongoing work.
    on Oct 2, 2026

  8. drhwatson commented on Oct 6, 2026

    @drhwatson
    drhwatson
    on Oct 6, 2026

    Additional Windows observation on October 6, 2026, with the same missing-tool symptom on a newer installed package. The specific MSIX path defect described above has not been verified on this machine.

    Environment:

    • ChatGPT Pro; Windows x64. Exact Windows build was not captured.
    • Installed OpenAI.Codex package: 26.930.4958.0, read from the AppxManifest.xml of the installation used by the running ChatGPT.exe, not from the About dialog.
    • The computer is connected and authorized for dot tasks. Shell commands work in the delegated local task, but it exposes no browser, screenshot, mouse, or keyboard controls.

    Capability discovery reports:

    failed to inspect capability root file:///C:/Users/<USER>/.codex/plugins/cache/openai-bundled/browser/26.928.40906: The system cannot find the file specified. (os error 2)
failed to inspect capability root file:///C:/Users/<USER>/.codex/plugins/cache/openai-bundled/unified-computer-use/26.928.40906: The system cannot find the file specified. (os error 2)
failed to inspect capability root file:///C:/Users/<USER>/.codex/plugins/cache/openai-bundled/computer-use/26.928.40906: The system cannot find the file specified. (os error 2)

    Observed workflow: connect and authorize the Windows computer, ask the dot to delegate browser work to it, then inspect the task capabilities. Local command execution succeeds, while the three capability-root lookups fail and supported UI controls are absent. A clean-install minimal reproduction has not been established.

    The installed package version and referenced plugin-cache version are recorded as observations only; we have not established whether that difference is expected or causal. Ordinary desktop-local Computer Use has not been independently compared in this diagnostic.

    In-product feedback reference: 01a0fed9-1f1a-73c9-ba41-9e7f1d0bb034. Please compare the capability-path resolution and tool provisioning with this issue and identify a supported repair or fixed build. No private site URLs, account identifiers, project files, or raw logs are attached.

  9. etrevio commented on Oct 10, 2026

    @etrevio
    etrevio
    on Oct 10, 2026 – with ChatGPT Codex Connector

    Feedback ID: 01a11466-6997-7221-887a-f8b663e77021

    Observed on October 10, 2026.

    After updating Codex Desktop, an existing task running on my connected Windows PC cannot discover its Browser / Computer Use tools. Capability discovery references an older bundled-plugin version.

    Environment:

    • Windows x64.
    • Installed MSIX package: OpenAI.Codex 26.1007.2314.0.
    • Bundled CLI: codex-cli 0.162.0-alpha.17.2.
    • Computer Use remains enabled.
    • Current Browser / Computer Use plugin directory version, according to separate local checks: 26.1007.21434.

    Observed workflow:

    1. Update Codex Desktop.
    2. Continue an existing connected-computer task.
    3. Ask it to discover Computer Use tools and run cua.getState(), without navigation or changes.

    Actual result:
    The tools remain unavailable. Capability discovery returns these errors. The Windows username has been replaced with <USER>:

    failed to inspect capability root file:///C:/Users/<USER>/.codex/plugins/cache/openai-bundled/browser/26.1002.52244: The system cannot find the file specified. (os error 2)

failed to inspect capability root file:///C:/Users/<USER>/.codex/plugins/cache/openai-bundled/unified-computer-use/26.1002.52244: The system cannot find the file specified. (os error 2)

failed to inspect capability root file:///C:/Users/<USER>/.codex/plugins/cache/openai-bundled/computer-use/26.1002.52244: The system cannot find the file specified. (os error 2)

    Expected result:
    The existing task should discover and use the currently installed Computer Use tools after the desktop update.

    Controls verified in the affected task:

    • Write-Output 'OK', whoami and AgentBrowser status executed successfully with normal permissions, empty stderr and process exit codes of 0.
    • The task could not call cua.getState() because the tool was unavailable.
    • Rechecking capability discovery reproduced the references to the older plugin directories.

    Additional local checks reported separately:

    • All three referenced 26.1002.52244 directories are absent, while the corresponding 26.1007.21434 directories exist.
    • A desktop-local Codex chat successfully ran cua.getState() and listed Chrome.

    Diagnostic scope:
    This is an unavailable-capability issue accompanied by missing-path errors (os error 2). It is distinct from the previously reported sandbox sharing violation (os error 32) and the direct-messaging AbsolutePathBuf error. A shared root cause has not been established.

    The observations suggest stale capability references following the update, but the component retaining those references has not been identified.

    Please investigate how existing connected-computer tasks refresh their versioned capability roots after desktop updates. Is there a supported recovery procedure that restores Computer Use while preserving the existing task history and permissions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingcomputer-usedotsIssues involving setting up ChatGPT dots or managing their ongoing work.mcpIssues related to the use of model context protocol (MCP) serversremotewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions