Dots cloud computer failed: “Root executor preparation for your dot failed” / env unavailable (Windows desktop) #50545

Activity

1. werty4870-boop

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Oct 3, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   dotsIssues involving setting up ChatGPT dots or managing their ongoing work.Issues involving setting up ChatGPT dots or managing their ongoing work.

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Oct 3, 2026
3. github-actions commented on Oct 3, 2026

   

   github-actionsbot

   on Oct 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Dots] Cloud Computer shows “Unavailable” while the Dot and ChatGPT app remain usable #50115
   • dot cloud computer remains Offline/Unavailable; computer-control connection repeatedly refused #50172
   • [Dot][Cloud computer] Computer unavailable, native connection refused and browser Target closed #50130

   Powered by Codex Action
4. CodeWithJuber commented on Oct 3, 2026

   

   CodeWithJuber

   on Oct 3, 2026 – with ChatGPT Codex Connector

   More actions

   I am seeing the same capability-query wording in existing Codex Cloud sessions, although my surrounding workflow differs from the root-executor failure reported here. A common cause is not yet established.

   Observed since October 1:

   • Existing sessions fail before a terminal becomes available with: exec-server protocol error: failed to query executor configuration capabilities.
   • Editing saved environments fails with “Couldn’t start editing environment”.
   • The original setup screen shows “Couldn’t confirm publishing status”, with Save draft and Publish disabled.
   • A previous allowlist save returned INVALID_ARGUMENT; a later status check returned MCP -32603: Internal error.
   • A fresh task on the same saved configuration started and ran shell/Git/Node commands. That did not recover the original workspace files.
   • In that fresh task, HTTPS to github.com succeeded, while api.github.com failed with proxy CONNECT 403 before authentication. This may be a separate allowlist problem; it is not evidence of invalid credentials.

   Source investigation at public commit b741e480e203f037ca726bc2a76d99a8e8668e66:

   • client.rs supplies the generic exec-server protocol error: prefix. Exact-string searches across 9,005 tracked paths did not locate the capability-query suffix or the editing/publishing messages.
   • environment_config.rs performs analogous discovery through self.info() and optional environmentConfig/read.
   • protocol.rs already defaults an omitted environment_config_read capability to false; an existing compatibility test covers this.
   • The public MCP discovery caller logs discovery failures and continues, rather than emitting this fatal startup message.

   These are source-inspection findings. Searches and clean-worktree checks ran; runtime/compatibility tests were not run, and no reproduced public-code defect or validated patch was found. This does not prove a private-backend defect or rule out a public-component defect.

   Could maintainers identify the deployed caller/build and underlying RPC or service error, and advise a supported recovery path that preserves existing workspace files? Related environment-management symptoms appear in #49568 and #50251, but I cannot establish that they share this cause.
5. nurockplayer commented on Oct 7, 2026

   

   nurockplayer

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   I am also seeing similar failures with my dot's cloud computer in ChatGPT. As of October 7, 2026, it still shows Offline on both my computer and my phone. Chat remains usable, but the dot's cloud terminal cannot execute commands.

   Observed errors include:

   • Root executor preparation for your dot failed
   • failed to query executor configuration capabilities for environment
   • No usable execution environment is available

   I have contacted OpenAI Support, and access has not yet been restored. The affected resource is “Your dot's computer”; I am not reporting a failure of my local computer. I cannot confirm that this has the same underlying cause as the original report.

   Please advise on a supported recovery path that preserves the existing dot and its data.
6. zxc8976 commented on Oct 8, 2026

   

   zxc8976

   on Oct 8, 2026 – with ChatGPT Codex Connector

   Last edited by zxc8976

   More actions

   I am also experiencing a dot cloud computer failure using dots in the web client on Windows. The cloud computer has been unavailable since October 7, 2026. At October 8, 2026, 00:30 UTC, it still failed with:

   failed to query executor configuration capabilities for environment [redacted]

   Chat and connected-app reads still work.

   A separate local-computer check at October 8, 2026, 00:35 UTC showed the computer as connected/authorized and accepted a diagnostic task, but even minimal read-only shell process creation failed with:

   Failed to create unified exec process: exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors

   I cannot establish whether the local error and cloud failure share a cause. No reset, reinstall, or configuration changes were performed during this diagnostic.

   Another observed access failure over the past few days: attachments could be recognized, but their contents could not be read. The reported error was:

   Library execution container is unavailable

   I also want to report the following user-facing quality and workflow problems from the past few days. These need separate triage; I have not established that they are platform bugs or share a cause with the infrastructure errors above:

   • Task handoffs lose context about source material, required format, or the expected output, requiring instructions to be repeated.
   • Generated PDFs have had missing or overlapping text and unclear figures, and have sometimes been described as ready before these problems were caught. Deliverables need to be checked before being called complete.
   • During long tasks, it is difficult to tell whether work is running, blocked, waiting for input, or complete.
   • Switching topics appears to leave earlier work unfinished. I want separate conversations for distinct tasks, with clear continuity and completion tracking.

   Could maintainers investigate the cloud, local execution, and attachment-access failures and provide supported, non-destructive recovery steps or diagnostics that preserve the existing dot and its data? Please also route the quality and workflow feedback to the appropriate product team or tell me the correct reporting channel.