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:
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.
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.
26.928.1915.0(read from local package metadata, not the About-dialog display version)0.159.026.928.20755The 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:
node_repl,cua_repl, or other supported native computer-control interface is exposed to the model.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.
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:
codex mcp listinvocation from the task's default sandbox environment reported no servers. An invocation-onlyCODEX_HOMEoverride 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.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.os error 3) followed by ready events witherror=null. Those events were not correlated to the affected task, so they are not presented as its cause.Separately, the dot UI displayed “Restore conversation failed” / “Codex app-server is not available.” Matching diagnostic fields included
thread/read,source=thread_hydration, andfailureReason=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:
cua_replwhile a new local task works. Here, fresh dot-started tasks also fail, while an ordinary local Codex session works.node_repltool, reported on an older version.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.