[Windows] dot-started local tasks lack Computer Use tools while ordinary local Codex sessions work

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT desktop on Windows, with an About-dialog release date of September 29, 2026. The user confirmed the app is up to date.

Installed Windows package version: 26.928.1915.0 (read from local package metadata, not the About-dialog display version)
Bundled Codex CLI: 0.159.0
Bundled Computer Use plugin: 26.928.20755

The exact About-dialog display version was not independently verified.

What subscription do you have?

Not collected for this report.

What platform is your computer?

Windows 11, native Windows desktop.

What issue are you seeing?

A dot can successfully start local tasks on my connected Windows computer, but those tasks cannot use Computer Use. An ordinary local Codex session on the same computer can inspect the current window using Computer Use.

In the affected dot-started tasks:

Shell commands and reading the installed Computer Use skill work.
No callable node_repl, cua_repl, or other supported native computer-control interface is exposed to the model.
Consequently, the task cannot perform the skill's initial screen/window inspection.
This reproduces in both an existing task and fresh tasks, including a fresh task explicitly requesting Computer Use with its skill preloaded.
Fully restarting the desktop app and starting another fresh dot task did not resolve it.

The computer was confirmed online, attached to the dot, and authorized for tasks. This is a tool-availability failure after a local task starts, rather than a failure to connect the computer or launch shell work.

What steps can reproduce the bug?

Observed on September 30, 2026; a clean-install minimal reproduction has not been established.

On Windows 11, use the desktop app with Computer Use enabled and connect/authorize the computer for a dot.
In an ordinary local Codex session, request Computer Use to inspect the current window. This succeeds on the affected machine.
Ask the dot to start a local task on that same computer and inspect the current window using Computer Use.
The local task starts and can run shell commands and read the Computer Use skill, but its available model tools lack the required runtime/control interface.
Repeat with a fresh dot task, explicitly requesting Computer Use and preloading its skill. The same tool omission occurs.
Fully restart the desktop app and repeat with another fresh dot task. The omission persists.

What is the expected behavior?

If Computer Use is supported for dot-started tasks on Windows, an authorized local task should receive the supported computer-control tools, as an ordinary local Codex session does on the same host.

If this path is not yet supported, the app should clearly explain the limitation and supported recovery or alternative workflow.

Please confirm Windows support for this task type and inspect the affected task's runtime registration, effective configuration, and final model-tool exposure. The root cause is not established.

Additional information

Read-only diagnostic observations:

Computer Use, Chrome, Browser, and unified Computer Use plugins are enabled in the inspected configuration. Plugin files and runtime executables are present.
A standalone codex mcp list invocation from the task's default sandbox environment reported no servers. An invocation-only CODEX_HOME override pointing to the normal user configuration reported eight, including the relevant runtimes. This shows different CLI configuration contexts; it does not establish which effective configuration the owning desktop app-server used for the task.
The manifest contains omit_tools_from = ["code_mode", "deferred"]. This alone does not establish the cause: the public CLI 0.159.0 tool-planning implementation retains direct exposure when those two routes are omitted.
Historical logs contained an MCP startup path-not-found error (os error 3) followed by ready events with error=null. Those events were not correlated to the affected task, so they are not presented as its cause.
No persistent configuration or security-setting changes were made during these checks.

Separately, the dot UI displayed “Restore conversation failed” / “Codex app-server is not available.” Matching diagnostic fields included thread/read, source=thread_hydration, and failureReason=remote_unavailable. Chat and delegated shell work remained usable. A relationship between this warning and the missing Computer Use tools has not been established.

Related reports:

[Windows app] Resumed task omits cua_repl after restart while a new @Chrome task works #46782: a resumed Windows task omits cua_repl while a new local task works. Here, fresh dot-started tasks also fail, while an ordinary local Codex session works.
Windows Desktop: Chrome/Computer Use enabled but mcp__node_repl__js is not exposed; js_repl remains removed false #30486: enabled Windows plugins without an exposed node_repl tool, reported on an older version.
Windows desktop: dot fails to start local tasks with DesktopTaskWorkspaceUnavailableError #49423: dot local-task startup fails with DesktopTaskWorkspaceUnavailableError. Here, local task startup and shell execution succeed.

Private paths, usernames, project names, account identifiers, task/conversation IDs, screenshots, and raw logs are omitted. Further diagnostics can be provided privately through a secure support channel if needed.

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

Chrome/Computer Use extension is enabled, but the tool runtime never loads #48813

Powered by Codex Action

Additional diagnostic results from September 30, 2026, shared with the affected user's authorization:

The desktop app's update-check tool reports installed version 26.928.20755, build 12246, release channel prod.
The running Windows Store package is 26.928.1915.0.
In the ordinary local conversation, the documented @oai/sky initialization succeeded, sky.list_apps() returned native app/window objects, and sky.get_window_state() returned screenshot images. This confirms the runtime works in that conversation; it does not validate mouse/keyboard control in a dot-created task.
The user reports that a fresh dot-created local task still has the Computer Use skill but no callable node_repl tool. That task's inventory was reported by the user, not independently inspected in this diagnostic session.
A targeted Microsoft Store update attempt (winget upgrade --id 9PLM9XGG6VKS --exact --source msstore --disable-interactivity --silent) returned: No available upgrade found. No newer package versions are available from the configured sources. Exit code: 1. No update was installed.

The enterprise local-access documentation at https://learn.chatgpt.com/docs/enterprise/cloud-local-access specifies desktop version 26.929 or later for dots. This may be a relevant compatibility/rollout gap, but the report does not establish that this requirement applies identically to the affected account or that it is the root cause.

Could the team clarify the supported Windows dot task/runtime combination, whether 26.929 is required for Computer Use tool exposure, and the recovery path when Microsoft Store does not offer that version?

No private paths, device names, screenshots, credentials, raw logs, or conversation IDs are included.

Same issue observed.
Feedback ID: 6abccd79-99a8-8191-8044-9f193a7d60f0

Additional reproduction on Windows on September 30, 2026, with newer installed versions:

Windows app package: 26.928.2636.0
Desktop internal / Computer Use plugin version: 26.928.21956
Bundled Codex CLI: 0.159.2

On the same connected, authorized computer:

An ordinary Codex Desktop session started directly by the user successfully initializes the Computer Use runtime, enumerates and activates windows, takes screenshots, recognizes controls, and clicks. Opening TradingView also succeeded.
A dot-created local task can execute shell commands and read the Computer Use skill, but its available tool catalog has no node_repl, cua_repl, or other supported desktop/browser-control entry point. No dynamic tool-discovery entry point is available either.

Reproduction:

Start an ordinary local Codex Desktop session and request Computer Use. The runtime and desktop interaction work.
Have the dot start a local execution task on that same connected computer and request Computer Use.
The delegated task starts and shell access works, but it cannot perform the skill's initial inspection because the required callable tool is absent.
Disconnect and reconnect the computer, then test both an existing delegated task and a brand-new delegated task. The missing-tool behavior persists.

Read-only configuration checks show node_repl enabled in codex mcp list, the configured executable present, and no tools disabled in the inspected configuration.

Historical logs contain os error 3 startup failures and optional MCP omission, followed by later initialization events. Those entries could not be reliably correlated with the affected delegated tasks, so they do not establish a root cause.

Could maintainers investigate tool exposure/readiness for dot-created Windows sessions, specifically why the skill is available but its execution tool is missing while ordinary local sessions work?

@xlztong

I'm seeing the same thing as @xlztong after updating Windows desktop to MSIX 26.928.2636.0, internal build 26.928.21956, with local backend 0.159.2.

A fresh task started by OpenAI Dot can run shell commands and read logs, but its callable tools still lack local browser/Computer Use access (node_repl and cua_repl) and the codex_app tools for existing local chats. Dot still couldn't read an existing local chat. Ordinary local Codex sessions worked in my earlier tests.

The latest startup logs mark local codex_app, node_repl and cua_repl, plus durable cua_repl, as ready. The fresh Dot task still has no callable cua_repl tool. I found no status record for durable codex_app in this startup, so I can't say whether it initialized. I haven't established the cause.

On Windows app 26.928.2636.0, a direct local @Computer chat successfully opens Calculator. However, multiple dot-created tasks explicitly targeting the same connected, authorized Windows computer load the Computer Use skill but receive no node_repl, cua_repl, or browser-control tools. Any App and Chrome are enabled, and the Chrome extension is installed. Explicitly loading the skill does not help. Please investigate tool provisioning for delegated local tasks. Plugin version: 26.928.21956.

Confirming on Windows with additional isolation. The Computer Use helper and runtime work; the problem is limited to node_repl not being attached to dot-started tasks.

Environment

Windows 11 25H2 (build 26200.9550), x64
ChatGPT desktop (MSIX): OpenAI.Codex 26.928.2636.0 (Microsoft Store; no newer build offered as of 2026-09-30)
Bundled codex-cli: 0.159.2
computer-use plugin: 26.928.21956
cua_node runtime: be2aaea167c12e53, @oai/sky 0.7.5
ChatGPT Pro, one personal computer connected to the dot and authorized

Symptom

Tasks started on the connected PC by my dot receive:

Present: exec_command, write_stdin, apply_patch, download_file, view_image, tool/resource discovery, web search, connected-app tools
Missing: node_repl, cua_repl, any callable @oai/sky runtime, screenshot/mouse/keyboard tools, local Chrome/browser-control tools

The Computer Use skill files are installed and readable from the task, but the entry point they require (node_repl) is not exposed. A Calculator test (123 + 456) couldn't start. This reproduces in both existing and fresh tasks.

Computer Use works normally in Desktop threads I start manually on the same PC.

Local configuration verified healthy

codex mcp get node_repl: enabled, stdio transport, command ...\runtimes\cua_node\be2aaea167c12e53\bin\node_repl.exe (the file exists; plain ASCII path, so not Windows Desktop mangles Korean USERPROFILE in generated notify/node_repl paths, causing invalid config.toml and setup loop #37740)
Only one cua_node runtime folder present, rebuilt today
SKY_CUA_NATIVE_PIPE and SKY_CUA_NATIVE_PIPE_DIRECTORY are present in [mcp_servers.node_repl.env]
Already tried without effect: reinstall, restart, reconnect, resetting both Computer Use connections

Helper and native pipe work outside node_repl

From a plain PowerShell on the same PC (not a Codex task), I loaded the [mcp_servers.node_repl.env] values from config.toml into the environment, then used the bundled cua_node\...\bin\node.exe to import @oai/sky by absolute file:// URL. Result: sky.list_windows() succeeded in 1,108 ms and returned 10 windows. There was no spawn EPERM (#37845), because the call went through the app's native pipe.

So the helper, the pipe, and @oai/sky 0.7.5 are functional. The failure is specifically that node_repl isn't injected into dot-started local tasks' tool inventory. The dot itself won't use exec_command as a workaround, citing guidance.md ("Use node_repl JavaScript for all Computer Use actions"), so there's no user-side path for dot-driven GUI work.

Related: handoff to a manual thread also fails (#49729)

As a workaround, I started a local thread manually (Computer Use works in it) and asked the dot to continue it:

The read failed with unsupported placement format version 3 (Dot cannot create or follow up with local Codex tasks in saved projects #49729 reports version 1 on macOS).
The send returned "cloud thread was not found."

So both dot → Computer Use paths are currently blocked on Windows.

Side note (possibly separate)

Codex core 0.159.2 warns at startup: computer_use.windows.always_allowed_app_ids is ignored. The key is written and read by the desktop app (app.asar) as a table of "<app id>" = true entries, but the string doesn't appear in the core binary, so the core flags a key the app legitimately uses. The docs' example shows an array (always_allowed_app_ids = ["mspaint.exe"]), which the app's schema rejects.

I'm also seeing the missing Computer Use tools in dot-started tasks on my Windows PC.

Our latest test was September 30, 2026, around 8:51 p.m. EDT (October 1, 00:51 UTC). The dot started a fresh local task on the connected, attached, authorized PC with the installed Computer Use skill explicitly preloaded.

The task confirmed:

It was executing on the intended PC, and file reads and shell commands worked.
It could read the Computer Use skill from plugin version 26.928.20755.
No callable node_repl, desktop/browser-control tool, or tool_search entry point was available in that session.
The skill required @oai/sky initialization through node_repl, so the task could not perform an initial screen inspection or the planned blank-tab test.

This reproduced the missing-tool behavior from our earlier dot-started attempts. Loading the skill explicitly did not make its required execution tool available.

This particular test did not compare against a manually started local session, and we did not independently verify the current desktop app or CLI version during it. No configuration changes were made, and we haven't established the root cause.

Could the team clarify the supported recovery path for a dot-created Windows task that has working shell access and the Computer Use skill, but lacks the callable Computer Use tools?

Adding my Windows reproduction here, since this issue more closely matches the task-creation path than the earlier general missing-tools report: #29921 (comment).

Latest checks on October 1, 2026:

Desktop package: 26.928.3736.0; Computer Use component: 26.928.31416; desktop-managed CLI: 0.159.2.
The computer is connected, attached, and authorized. Dot-created local tasks can execute shell commands and read the Computer Use skill, but no callable node_repl, cua_repl, or supported local browser/desktop-control interface is exposed.
This was observed in two independently created tasks and remained unresolved in the diagnostic task after a full desktop restart. No desktop screenshot was obtained.
Ordinary local Codex text conversations work. Historical local-session records show successful extension-backed browser interaction, but a current, controlled local-GUI-versus-dot comparison has not been completed; I am not claiming that stronger comparison here.

A separate, previously verified browser-helper proxy workaround was reapplied for the current component. After restart its on-disk presence and hash were verified, but this did not make the control tools available to the delegated task. Actual helper-process proxy inheritance could not be verified in that task, so this neither proves nor rules out a separate networking issue.

The desktop also still reports a root dot conversation-resume failure, with durable WebSocket timeout/1006 and remote_unavailable, while local chat and delegated shell work remain usable. Its relationship to missing tool exposure is unproven.

Could maintainers clarify the supported Windows dot-task/runtime combination and recovery path for this specific missing-tool condition? In particular, is a newer desktop rollout required, or should these builds already expose Computer Use to delegated local tasks?

This summary omits private paths, device and conversation identifiers, proxy endpoints, credentials, screenshots, and raw logs.

Additional Windows reproduction and correlated startup diagnostics, September 30–October 1, 2026.

Updated environment (verified October 1)

Windows 11 Pro 25H2, x64, build 26200.9550.
Desktop MSIX: 26.928.3736.0; Browser/Computer Use component: 26.928.31416; bundled Codex CLI: 0.159.2.
Previous desktop package/component: 26.928.2636.0 / 26.928.21956.

The user reports that the problem persists after this update. The versions above were independently checked; the detailed comparison and logs below were captured before the update.

Local and delegated observations on the same Windows PC

A manually started local desktop chat used both Chrome and the in-app browser to open https://example.com, click “Learn more,” and verify the IANA destination URL/content.
An existing dot-created task and a fresh dot-created task ran harmless Windows shell commands successfully, but reported no callable node_repl or supported browser/computer controller. The Computer Use skill was readable.
Desktop startup records correlated to those exact delegated tasks show cua_repl and codex_app failing while other MCP servers become ready. In the fresh task, resume itself succeeded, so this is not solely a conversation-resume failure.

Redacted error text:

hostId=durable server=cua_repl status=failed error="MCP server failed to start." failureReason=null
hostId=durable server=codex_app status=failed error="MCP server failed to start." failureReason=null

Observed workflow to reproduce

Enable the supported Browser/Chrome/Computer Use plugins.
In an ordinary local chat, request the example.com visit and link click.
Ask a dot to start a fresh task on the same connected Windows PC, run Get-Date -Format o, and perform the same browser test.
Shell access works, but the delegated task lacks the controller entry points and cannot begin the browser test.

Expected: supported delegated tasks receive their authorized controller tools, or show an actionable compatibility/permission error.

Please compare delegated versus local MCP startup/configuration and expose the underlying startup exception. The root cause is still unknown.
generated by Codex

Adding another Windows Dot browser regression report, with trace evidence from October 12, 2026.

My Dot's browser access previously worked, including a verified report-reading task on October 10. It now fails both when asked directly and through existing scheduled tasks. Ordinary local Codex chats on the same PC still initialize browser control and open a blank Chrome tab successfully. Creating a fresh Dot diagnostic task and restarting the desktop app did not restore access.

Environment:

Windows 11 26H2, build 26300.9550
Desktop MSIX package: 26.1007.2314.0
Bundled CLI: 0.162.0-alpha.17.2
Browser/Computer Use component: 26.1007.21434
ChatGPT Pro, $200/month

Initial failure:
mcp__cua_repl.js → await cua.getState(); exits before browser inventory with:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003.

Verified diagnostics:

The official host-side MXC probe returned MXC_OK, exit 0.
Process Monitor captured the actual --__codex-windows-mxc child attempting <task working directory>\%SystemDrive%\ProgramData, receiving PATH NOT FOUND and exiting with code 1.
Full Process Start details for that child had no SystemDrive assignment, although the task's shell had SystemDrive=C:. Shell environment checks therefore did not describe the failing launcher's environment.

Temporary mitigation attempts:

Added SystemDrive=C: to the generated cua_repl environment and its pass-through allowlist, with a backup and hash guards.
A later captured launch successfully opened C:\ProgramData and no longer attempted the literal %SystemDrive% path, but its MXC children still exited with code 1. Browser calls reported “trusted Node process exited unexpectedly; kernel reset, rerun your request.” One requested recovery attempt also failed.
That later child's full environment had SystemDrive, SystemRoot and real host TEMP/TMP paths, but lacked LOCALAPPDATA.
Tried adding the real host LOCALAPPDATA path to the same environment/allowlist. Restarting the app removed both additions and refreshed the generated pipe configuration. Reapplying both additions and testing without an app restart also failed. Their presence on disk does not prove the active child inherited both; no successful browser recovery was established.
No global Windows variables, permissions, or sandbox-security settings were changed. Raw traces, full environments, private paths, task IDs and report contents are not included here.

The support bot received these findings but could not confirm human escalation or provide a case number or supported targeted repair.

I am stopping further troubleshooting. This issue thread has been open since September 30 and has many similar reports. I am extremely disappointed that I have not found a clear maintainer acknowledgment, supported recovery, or fix status. For a $200/month Pro account, I expect better service than repeatedly diagnosing a previously working capability.

Please acknowledge this regression, identify the engineering owner, and provide a supported fix or clear status/ETA. The existing Dot and scheduled workflows need to work; replacing them with manual local chats does not solve the problem.

Related launcher reports: #52407 and #53188.

Exact same error here today. This makes my setup essentially useless as it can't seem to do anything.

✅ WORKING FIX — Windows Dot browser / MXC launcher error 0x80070003

Verified on my affected Dot on October 13, 2026, and successfully reapplied after a client update on October 14. Unofficial local workaround; not a released OpenAI fix. Exact bootstrap patch, reload instructions, rollback, and limitations are below.

⚠️ CLIENT UPDATE RESET THE FIX — REAPPLICATION RESTORED IT

On October 14, the desktop update to MSIX 26.1007.9446.0 selected a new CUA runtime and browser component 26.1007.71326. The bundled CLI remained 0.162.0-alpha.17.2, and @oai/cua-repl remained 0.1.0. The new active bootstrap lacked the patch and exactly matched the original SHA-256 recorded below. The generated configuration had also lost our earlier environment overrides. The Dot again reported HRESULT 0x80070003.

We backed up the new active bootstrap and reapplied the same patch only after confirming its package version and exact original file hash. We did not reapply the generated .mcp.json environment overrides. After reloading the app, the affected Dot verified all three additions, reset its kernel once, and one await cua.getState(); call returned Chrome inventory successfully at approximately 11:55:12 UTC (7:55:12 a.m. EDT), October 14. No errors, retries, or private-page inspection were reported.

If a client update removes this workaround, it needs to be reapplied to the newly active runtime—not just the old cached runtime. Verify the active script path, installed version and original contents first. An update may contain different code or an official fix; do not overwrite unknown/newer content or install an automatic patcher. Backups and rollback should target the newly reviewed file. This recovery confirms inventory initialization after reapplication; it does not prove every future update will behave identically.

Follow-up to my October 12 report: the same affected Dot now initializes successfully and supports browser navigation after a local bootstrap workaround. This is an unofficial workaround, not a released OpenAI fix.

Verified result

On October 13, 2026, 09:03:06–09:03:17 UTC, my Dot verified the three bootstrap additions, reset its CUA kernel once, and made one await cua.getState(); call. That call returned Chrome inventory. It was the affected Dot route, not a replacement local chat.

Later follow-up: I subsequently used the affected Dot for extensive browser navigation successfully. Recovery therefore extended beyond the initial Chrome inventory check to actual browser use. The initial test above was limited to inventory; this later navigation result is my subsequent user confirmation. I am not publishing page URLs, browsing history, or private page contents.

Scheduled-report completion, native desktop control, and persistence across app updates are still not established by these tests.

Versions

Desktop MSIX: 26.1007.2314.0
Bundled CLI: 0.162.0-alpha.17.2
Browser component: 26.1007.21434
Installed @oai/cua-repl: 0.1.0

What we applied

We followed the bootstrap patch reported in #52407, preserving the existing import and launch/error handling.

The file is the installed runtime's:

<CUA_RUNTIME>/bin/node_modules/@oai/cua-repl/bin/cua-repl.mjs

The generated cua_repl MCP configuration's script argument identified the active file; we did not guess or patch every cached runtime.

Immediately after the existing import * as cua_repl from "@oai/cua-repl";, and before try { await cua_repl.launch(); }, we added:

import { homedir, tmpdir } from "node:os";
import { join, parse, sep } from "node:path";

if (process.platform === "win32") {
  process.env.SYSTEMDRIVE ||= parse(process.env.SYSTEMROOT || process.execPath)
    .root.replace(/[\\/]+$/, "");
  process.env.LOCALAPPDATA ||= join(homedir(), "AppData", "Local");
  const pluginRoot = join(process.env.CODEX_HOME || join(homedir(), ".codex"),
    "plugins", "cache") + sep;
  if (process.cwd().toLowerCase().startsWith(pluginRoot.toLowerCase())) {
    process.chdir(tmpdir());
  }
}

The environment additions are process-scoped and fill only missing/empty values. The cwd change applies only to Windows launches starting below the plugin-cache root. No global Windows variables, registry, ACLs, permissions, or sandbox-policy settings were changed.

Deployment and reload

Save the exact original bootstrap and its SHA-256 before editing. Review the installed version and contents; do not overwrite a different/newer implementation.
Add the block above while preserving the original launch/error handling. We checked JavaScript syntax with the bundled Node and verified the installed file hash.
Let active jobs finish, fully quit and reopen the desktop app, then have the affected Dot verify the patch remains, reset its CUA kernel once, and initialize once.
Stop on failure rather than repeatedly adding environment variables or changing permissions.

For reference, our original bootstrap SHA-256 was 992174A5E637645AEB444ADFDB1BAE688E997BB84D7DB07532F68E358E60F278. The exact formatting of a manually edited patch may differ; the original-version/content check is the important guard.

Important evidence limit

Earlier SystemDrive and LOCALAPPDATA additions to the generated .mcp.json environment/pass-through allowlist were still present during our successful test. Those configuration-only attempts had not restored browser access. We did not isolate bootstrap-only recovery during the initial October 13 test. The October 14 update/reapplication described above subsequently succeeded without adding those generated configuration overrides. The initial October 13 result was the combined observed state; the later October 14 result supports the full bootstrap patch without those generated overrides. Neither test isolates the contribution of each individual patch line.

Editing the generated .mcp.json alone proved unreliable: an app restart previously removed our additions and refreshed native-pipe routing. Do not restore an old complete configuration with stale pipe details.

Rollback / durability

After active jobs finish, restore only the exact original bootstrap from the backup, then reload the app/executor. Do not overwrite unknown content after an update. Restore any separately modified configuration only against its current state, preserving refreshed connection details.

App updates may replace this runtime or change its path. We saved manual, hash-guarded reapply/rollback tools locally; we did not install an automatic patcher. This workaround still needs an official, update-stable product correction.

Our escalated support conversation has been updated with the successful result. Please provide a supported fix for both Windows startup-variable propagation and trusted-worker cwd handling, plus regression coverage through the actual Dot-to-Windows browser route.

No private paths, account/device/task identifiers, browsing inventory, credentials, or raw traces are attached.

Could a maintainer clarify the supported native Computer Use recovery for Windows desktop package 26.1007.2314.0?

My connected, authorized PC supports local file and shell work, but dot-created tasks report native computer APIs disabled and expose no native node_repl controller. A separately opened local Codex conversation also lacks that controller. Computer Use is not visible in the plugin catalogue I can access, so this is broader than the working-local/failing-delegated comparison in the original report.

What supported diagnostic distinguishes account/workspace eligibility, plugin provisioning, and per-task tool registration here? Is there a released build or supported refresh that restores native screenshot/click/type capability without editing installed runtime files or relaxing security settings?

I also reviewed the browser-startup workaround in #52407. Its reported browser recovery does not establish native Windows-app control. Please clarify whether these need separate product fixes.

Prepared with AI assistance. No private logs, paths, account/device identifiers or screenshots are included.

@computer

Additional controlled Windows reproduction on October 14, 2026 (UTC).

The computer was connected, attached, and authorized for dot tasks. The inspected desktop/Computer Use release was 26.1007.71326, with @oai/sky 0.7.7.

On the same computer:

An ordinary local session successfully initialized the official Computer Use runtime and ran sky.list_apps(), returning six apps.
A fresh dot-created task explicitly requesting @computer could read the official Computer Use skill. That skill required node_repl with @oai/sky, but node_repl was absent from its callable tools. Its available cua_repl explicitly stated that native computer APIs were disabled.
Earlier dot-created tasks also had working file/shell access but no usable native Computer Use execution path. Thus this is not simply a disconnected computer or missing skill.

We also verified an indirect route: a dot-created diagnostic task used official native thread tools to send a read-only request to the existing ordinary local session, and a new turn successfully ran sky.list_apps(). This does not restore native tools in fresh dot-created tasks and should not be treated as a documented standard setup or a fix. The related placement-format failure is reported separately in #50171; a shared cause is unproven.

Please confirm whether native Windows Computer Use is supported directly in dot-created tasks, which capabilities should be provisioned, and the applicable fix or supported recovery procedure. No permissions were relaxed, no runtime patches were applied, and private identifiers/logs are omitted.

Adding another reproduction on Windows.
Environment:

Windows 11 Pro 24H2, x64, OS build 26100.9711
Desktop MSIX package: OpenAI.Codex 26.1007.9446.0
Desktop-bundled Codex CLI: 0.162.0-alpha.17.2
Browser, Computer Use and Unified Computer Use plugins: 26.1007.71326
@oai/sky: 0.7.7
@oai/cua-repl: 0.1.0
node_repl is configured and its executable exists locally.

Comparison on the same connected, attached and authorized PC:

In a manually opened local Codex conversation, node_repl successfully imported @oai/sky and ran sky.list_windows().
In the dot-started task, PowerShell and file access work, and the Computer Use skill is readable. However, its callable tools contain no node_repl, cua_repl or supported desktop/browser controller.
Restarting the app and continuing the delegated task did not restore those tools.

The delegated task could not initialize Computer Use at all, so it did not reproduce the separate MXC 0x80070003 launcher error.
Is there a supported way to refresh tool provisioning for dot-started tasks?

ChatGPT’s earlier analysis misinterpreted the ProcMon evidence by presenting missing environment variables as the established cause. That causal conclusion was not demonstrated.

The eighth ProcMon capture directly records the invalid-path failure. This is the actual retained event row exported from the PML:

"12:30:17.0165636 AM","codex.exe","39764","CreateFile","C:\Users\antho\Documents\Codex\2026-10-14\task%SystemDrive%\ProgramData","PATH NOT FOUND","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"

Columns: Time of Day, Process Name, PID, Operation, Path, Result, Detail.

The event occurred October 15, 2026, at 05:30:17.0165636 UTC (12:30:17.0165636 a.m. CDT). The task’s working directory existed. The failed lookup targeted a path beneath it containing the literal %SystemDrive% reference and returned PATH NOT FOUND.

Browser-control startup reported: “MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003.” Startup failed, and the browser command could not run.

This is the observed path-resolution defect. The precise code-level cause remains unconfirmed; no fix has been validated.

Evidence source: browser-controls-startup.pml, eighth capture, 23,706,396 bytes. Retained CSV line 22051; corroborating raw PML event ordinal 22049, byte offset 10673899.
SHA-256: A64D5B804F741B0A42A4DA82413946B901EF9471C173414223F4D22277DB2772

Windows retest on October 16, 2026, shared with the affected user's authorization. These are observations from our test, not maintainer confirmation of a fix.

Versions:

Desktop app: 26.1013.31256, build 20586, production channel.
Windows package: 26.1013.3656.0.
Bundled and running core: 0.163.0-alpha.10.2.
A fresh local updater check reported up to date; no restart was performed during this retest.

Comparison on the same computer:

The existing delegated dot task (durable context) still exposed no native Computer Use or browser-control tools. Its update check reported that the calling host was unsupported.
A newly created, projectless native task (local host context) exposed the in-app browser. Navigation, clicking, screenshot capture and test cleanup succeeded. Native app/window inventory also succeeded. No Chrome backend was exposed in that task.
Both contexts successfully read an existing local thread, and fresh thread creation/read also worked. The placement-format error did not reproduce in these checks. This does not establish that the original cloud-parent route is fixed.

Native desktop screenshot capture and mouse/keyboard input were not tested: the only available window was Codex, and the applicable computer-use guidance prohibited automating that UI. Successful in-app browser interaction and native window inventory therefore should not be interpreted as verification of full native desktop control.

No authentication, manifest or security-setting changes were made. Original browser tabs were preserved. Account/workspace attribution was not verified.

The result remains a task-context difference: browser interaction works in the fresh local task, while the existing delegated task lacks the control tools. Please clarify the supported Windows delegated-task route and whether this build includes a supported tool-provisioning recovery. This report does not establish a root cause or a general fix.

Prepared with AI assistance. Private paths, account/device/task identifiers, screenshots and raw logs are omitted.

I tested again on Windows after the latest update and a reboot. Native Computer Use is still unavailable, now in a fresh regular chat as well as a dot-created task.

Installed versions: Windows package 26.1013.4894.0, app build 26.1013.40934, bundled CLI 0.163.0-alpha.10.2.

“Any App” is enabled in Computer Use settings, and Diagnose reports healthy dependencies.
The Windows Computer Use instructions still require node_repl with @oai/sky. The server is configured and its executable exists, but neither session exposes node_repl.
Both expose cua_repl, which reports that native computer APIs are disabled. Asking the fresh regular chat to list open windows failed without any desktop interaction.
The installed app code appears to add native computer access to the unified interface only on macOS, leaving Windows dependent on the separate tool that is missing here.

One limited Chrome-extension test in a delegated task succeeded after reboot. That does not establish that browser access is fixed across sessions, and it does not restore native desktop control.

Can someone confirm how the Windows node_repl tool is supposed to become available, and what supported recovery we should use when the components are installed but the tool is absent? We haven’t established whether this is a startup failure or a tool-exposure problem.

Has anyone here actually restored local browser control for a dot on Windows when ordinary local chats work but dot-created tasks have no browser-control tools? We’re looking for someone willing to help narrow down the cause and identify a supported fix. We need to preserve existing signed-in browser sessions and won’t share credentials, private logs or remote access.

@dj-atch

@dj-atch We’ve had similar problems on Windows. After the latest update and a reboot, a dot-created task was able to use the Chrome extension and open a test page. That’s the browser route we’ve had some success with, although we haven’t established why it started working or whether it’s reliable yet.

Native desktop control is still unavailable for us, including in a fresh regular chat. Shell commands in delegated tasks do work, so we’ve been using those where practical.

We kept our existing browser sessions and haven’t needed to reinstall or clear the browser profile. Happy to compare versions or share more detail if useful.

@advgiraffe

@advgiraffe Thanks, that’s helpful, especially that you kept your existing browser sessions. Could you share the desktop app and Chrome extension versions used for the successful test? Was it a brand-new task created by the dot after the update and reboot, or an existing task resumed by the dot?

What exact steps or request got it to use the Chrome extension successfully? Also, did it require any manual runtime patch or configuration change, or was the update and reboot enough?

We’re trying to narrow down a supported browser-only recovery before changing anything. No private logs, account details or screenshots needed. Thanks for comparing notes.

@dj-atch

@dj-atch Here’s what we could verify:

Windows app package: 26.1013.4894.0; desktop component: 26.1013.40934 (build 20770).
Chrome extension: “ChatGPT — Control your browser with ChatGPT,” currently version 1.26.1005.11759. We didn’t record its loaded version during the successful test, so I can’t confirm it was exactly the same then.
It was a fresh task created by the dot after the update and reported reboot. The initial browser list was empty, and trying Chrome returned “Browser is not available: chrome.” Later, in the same task, cua.listBrowsers() showed Chrome with type “extension.” The task opened a new example.com tab, read “Example Domain,” and closed just that test tab.

No patch, configuration change, installation or restart was made between those attempts. The browser/computer-use plugins were already enabled. We don’t have a complete record of older runtime changes, so I wouldn’t call this a clean-install test or claim the update/reboot alone fixed it. We still don’t know why Chrome appeared on the later attempt.

Windows 手动任务可以枚举窗口，dot 任务缺少 node_repl，564 个工具中未找到该入口。

接续本地任务出现 unsupported placement format version 3 / NOT_FOUND。

反馈 ID：01a14dec-7ab7-756d-89ab-2941de0f502a。

另注明云端 Linux 的 Telegram 网页可用，但原生 Telegram、微信连接失败，FlClash 测试超时，原因未知。

@computer

Additional Windows reproduction on October 18, 2026, posted with the affected user's authorization.

Environment checked during diagnosis:

Desktop / Computer Use component version: 26.1013.40934.
Bundled app-server/core: 0.163.0-alpha.10.2.
Windows build: 26300.9711, x64.

Comparison on the same connected, attached, and authorized computer:

The user reports that an ordinary local Codex conversation, started directly with the Computer feature selected, successfully operated Calculator to compute 1 + 1. A screenshot of that conversation was reviewed, but its underlying tool trace was not independently inspected.
Dot-created tasks successfully execute local Windows shell commands; hostname and OS checks confirmed the intended local machine rather than a cloud Linux environment.
The delegated tasks can read the Computer Use instructions, but have no callable node_repl. Their available cua_repl explicitly reports that native computer APIs are disabled; its configured surface is browser-only.
Existing and freshly created delegated tasks show the same limitation. A fresh concise Chinese Calculator task and a subsequent explicit @computer text request did not make native tools available. No Calculator interaction occurred in those delegated tests.

The installed Computer Use configuration and runtime executable are present. Historical native-pipe readiness does not establish readiness or tool exposure in the affected tasks. We have not established whether the cause is runtime startup, task-context provisioning, or final tool filtering. We did not modify configuration, relax security settings, or apply runtime patches during these checks.

Could maintainers confirm the supported native Computer Use route for dot-created Windows tasks on this build, and provide a supported recovery procedure or fix? Browser-only recovery would not resolve the native desktop-control limitation described here.

Prepared with AI assistance. No device names, private paths, account identifiers, conversation IDs, screenshots, or raw logs are included.

Navigation Menu

Repository navigation

[Windows] dot-started local tasks lack Computer Use tools while ordinary local Codex sessions work #49458

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Symptom

Local configuration verified healthy

Helper and native pipe work outside node_repl

Related: handoff to a manual thread also fails (#49729)

Side note (possibly separate)

66 remaining items

✅ WORKING FIX — Windows Dot browser / MXC launcher error 0x80070003

⚠️ CLIENT UPDATE RESET THE FIX — REAPPLICATION RESTORED IT

Verified result

Versions

What we applied

Deployment and reload

Important evidence limit

Rollback / durability

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows] dot-started local tasks lack Computer Use tools while ordinary local Codex sessions work #49458

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 30, 2026

vieiraphilipe875-ux commented on Sep 30, 2026

abdu355 commented on Sep 30, 2026

xlztong commented on Sep 30, 2026

DDDFXYqiming commented on Sep 30, 2026

jchame commented on Sep 30, 2026

tonyrice923-dev commented on Sep 30, 2026

Environment

Symptom

Local configuration verified healthy

Helper and native pipe work outside node_repl

Related: handoff to a manual thread also fails (#49729)

Side note (possibly separate)

wirelesstkd commented on Oct 1, 2026

etoqeyeyise49-lang commented on Oct 1, 2026

ionabio commented on Oct 1, 2026

66 remaining items

dfife commented on Oct 12, 2026

firrae commented on Oct 13, 2026

dfife commented on Oct 13, 2026

✅ WORKING FIX — Windows Dot browser / MXC launcher error 0x80070003

⚠️ CLIENT UPDATE RESET THE FIX — REAPPLICATION RESTORED IT

Verified result

Versions

What we applied

Deployment and reload

Important evidence limit

Rollback / durability

malikbouheraoua-star commented on Oct 14, 2026

jeongsuho-lawyer commented on Oct 14, 2026

djs4000 commented on Oct 15, 2026

AnthonyStephens1 commented on Oct 15, 2026

Eliagiac commented on Oct 16, 2026

advgiraffe commented on Oct 17, 2026

dj-atch commented on Oct 18, 2026

advgiraffe commented on Oct 18, 2026

dj-atch commented on Oct 18, 2026

advgiraffe commented on Oct 18, 2026

project-cit commented on Oct 18, 2026

9527-Cai commented on Oct 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions