Repository navigation
[Dots][Windows] Delegated task environment unavailable while direct Codex works; model selection UI unchanged #54012
Description
Summary
On 2026-10-14, dot-mediated task control on a connected Windows computer failed while the owner reported that direct local Codex browser work on that computer worked. A separately observed model/reasoning selection inconsistency is described below; we have not established a common cause.
Observed task execution behavior
- The computer was listed as connected, attached and authorized. The selected computer identifier matched the computer originally associated with the task.
- Earlier, a shell command in the dot-created task worked. A later continuation reported that its selected execution environment was unavailable and did not expose filesystem/shell tools.
- A subsequent Codex Tasks
start_task_turnrequest against that existing task returnedInternalError, error codeUNAVAILABLE, with the messageCodex Tasks could not complete the request. - Reading the task afterward showed the previous turn, with no new turn from that request.
- The owner reported direct Codex browser operation working on the same computer. This is a contrast in observed functionality, not a controlled identical-command test.
Separately observed model/reasoning control inconsistency
A requested change was accepted by the control tool, but the owner observed that the displayed model/reasoning selection did not change. This is a UI observation; we have not verified which backend model executed a subsequent turn. The exact endpoint response is not available in this report, so this symptom should not be treated as proof of a backend model-selection failure.
Expected behavior
The control interface should start the requested task when its executor is ready, or return an actionable error identifying the unavailable component. Model/reasoning changes should accurately report and display the effective selection, or clearly report that a requested change was not applied.
Related reports
- Windows: dot-started tasks fail with “setup refresh had errors”, but direct local Codex chats work #51882: similar dot/direct-local difference, but its reported
setup refresh had errorssignature is not established here. - Windows MSIX: Dots connected-computer tasks lack browser and session tools; generated app-tools working directory points outside virtualised app data #49562: similar difference in browser/session tool availability for dot-connected Windows tasks.
- Windows desktop: dot fails to start local tasks with DesktopTaskWorkspaceUnavailableError #49423: dot workspace preparation failure while ordinary local Codex works; exact exception differs from our captured error.
We have not established an identical cause or a confirmed workaround. Could maintainers advise which minimal diagnostics distinguish task routing, executor readiness and state synchronization failures?
Exact current desktop app version was not captured in this report. No private task contents, local paths, computer identifiers, account information or unfiltered logs are included.
Activity