Repository navigation
[Dots] Cloud executor stops responding and cannot resume after file-transfer timeout #52509
Description
Additional diagnostics completed — 2026-10-09, 16:01 UTC
Still unresolved. A further diagnostic pass covered the affected cloud executor, a separate task on the connected Windows computer, installed desktop-app code and logs, supported UI/browser recovery routes, and public Codex source. No successful cloud recovery was observed.
Fresh execution checks
- At approximately 15:44 UTC, cloud startup failed with
failed to query executor configuration capabilities for environment. - Minimal
pwdprobes at approximately 15:44, 15:54 and 16:01 UTC were rejected before execution withNo usable execution environment is available. Wait for an environment to become available before using this tool. - A separate task on the connected Windows computer started successfully and ran PowerShell commands, read-only app inspection and an app query. The installed desktop app version was independently read as
26.1002.7124.0. This verifies the separate local execution route; the affected dot cloud executor remained unavailable.
Desktop reboot implementation and logging gap
Read-only inspection of the installed app found:
- The Reboot handler sends
POST /cloud-aeons/primary/reboot, with automatic retries disabled. - The generic “Couldn't request a reboot. Please try again.” message can cover local selection/identity checks, network failures or HTTP errors. The toast alone does not identify the failed layer.
- This request bypasses the ordinary
sa_server_request_failedlogging wrapper. Six inspected desktop logs did not reveal the actual reboot HTTP status, response body, server request ID or error class. Their silence cannot establish that the failed request never reached the service. - Some other attempts displayed “Reboot requested” without restoring execution, as described in the owner's earlier update. Request acceptance does not establish completed recovery; those attempts require service-side tracing.
- Messaging requests returned HTTP 200 around the outage. Separate background
thread/readrequests returned-32003: thread access denied. These are additional observations, with no demonstrated causal connection to the cloud-executor failure.
Recovery controls and final UI checks
- The Reboot UI warns that active dot work may be interrupted and says conversations, memories and schedules are preserved. It does not explicitly state cloud-file retention.
- The separate startup-error Retry flow calls
/tbo/{tbo_id}/environment/recreate. Its effect on existing cloud files was not established, so it was not used. - No additional reboot was submitted during this diagnostic pass: native desktop control was disabled in the diagnostic task, its app tools exposed no cloud reboot action, and both supported attempts to control the existing browser tab timed out. A fresh ChatGPT tab worked but was signed out and had no Reboot control.
- No credentials were extracted, security settings changed, app data reset, processes killed or cloud environment recreated. The existing environment and storage were left untouched.
Public-source interpretation, not a confirmed root cause
At public commit c63929af50518ca638ccad12f2805298cb7f25a1:
- Session-recovery code produces the earlier
failed to resume exec-server session: recovery timed out after 25serror. The 25-second deadline concerns executor-session reconnection, not the file-transfer timeout. It does not establish file loss. - Environment readiness gates reject an owner-provided failed configuration before waiting for readiness. This may explain immediate command rejection, but is not a proven cause of this incident.
- An internal Rust
refresh_connectionfacility exists; no supported dot tool or user-facing command for invoking it was found. - The exact capability-query wrapper was not located in the searched public code. The deployed managed-backend revision and underlying cause remain unknown.
OpenAI's public status page reported operational during this pass; that does not rule out an individual environment failure. Related reports and the official dots guide yielded no verified self-service fix for this failure.
Requested next step: Please correlate the failed executor-capability query and session-recovery timeout with both failed and accepted reboot requests in the managed service logs, using the feedback/support case already submitted. Restore the existing executor connection and attachment readiness without resetting persisted data, or provide a supported recovery procedure with explicit cloud-file retention guarantees. Exposing a sanitized error class, HTTP status and request ID for reboot failures would also make this diagnosable.
The original report is preserved below.
What issue are you seeing?
My dot's cloud computer stopped executing commands during an authorized file-transfer workflow on October 9, 2026. It subsequently entered starting, then failed; repeated readiness checks did not restore execution. Conversation and connected-app reads remained available, but file preparation and upload work could not continue.
The diagnostics below were reported by the assistant's tools. The managed executor/backend and client versions were not captured.
What steps can reproduce the bug?
This is one observed incident, not a deterministic minimal reproduction. Times are UTC on October 9, 2026:
- After I restarted the dot/session around 07:39, shell operations worked from approximately 07:40–07:47. A local archive checksum was verified.
- An attempt to transfer an approximately 514 MB file through the Google Drive connector timed out after
300001 ms. The failure occurred in the source/blob-transfer stage, before a successful Google Drive upload result. - By approximately 07:48, even simple shell reads stalled. No approval prompt was visible. A cloud computer-control
cua.getStaterequest also timed out after 300 seconds. - At approximately 08:26, a minimal
printfcommand failed with:
exec-server transport disconnected
failed to resume exec-server session: recovery timed out after 25s
- Supported environment-readiness waits ending at 09:06:54, 09:18:01 and 09:23:25 returned:
exec-server protocol error: failed to query executor configuration capabilities
- At approximately 09:24, an attempted shell reboot was rejected before execution:
No usable execution environment is available. Wait for an environment to become available before using this tool.
-
A clean minimal-command probe at 09:50:01 using
/bin/shwith login startup disabled failed before execution with the same “No usable execution environment” error. A further readiness wait failed at 09:54:06 with the same executor-capabilities error, and the environment changed fromstartingtofailed. At 09:54:09, even polling an existing terminal session failed with “No usable execution environment”. -
At 13:12:13 UTC, a supported readiness wait following the owner's failed desktop reboot request returned
exec-server connection attempt failed: environment unavailable: Root executor preparation for your dot failed.The environment remained failed; no successful reboot or executor recovery was verified.
The reboot command did not run. All currently exposed, supported same-environment recovery routes were tried without restoring access. No independent full-environment restart action was available to the assistant; backend/host-side recovery could not be attempted from this conversation.
User-visible cloud computer state
The main user-visible message in the cloud-computer view is exactly “Computer unavailable”, as confirmed by the owner. The owner cannot use the cloud computer while the assistant's execution tools report the startup and transport failures documented above. The reboot option was absent from the web interface the owner had been using. At approximately 13:07 UTC, the owner reported finding the reboot option in the desktop app only and trying it while the computer remained unavailable. The supplied screenshot's extracted error text reads: “Couldn't request a reboot. Please try again.” This reports a failure to request the reboot; a reboot starting or completing has not been verified. This user-facing reboot attempt is separate from the lack of an assistant-accessible host restart action documented above. The screenshot itself is not attached to this report.
What is the expected behavior?
A transfer timeout should leave the cloud computer usable, or provide a supported recovery path. Executor failures should show actionable status and provide an effective, user-accessible recovery/restart control in both the web and desktop interfaces. It should remain available when the computer shows “Computer unavailable”, work independently of the guest shell, and clearly report whether recovery succeeded or failed. Once recovered, the assistant should be able to resume the existing workflow and verify its files and upload outcome.
Additional information
- The transfer timeout preceded the execution failure; causation has not been established.
- Google Drive metadata reads still worked and showed the target folder empty. Chat, web research, and Google Drive/Library metadata reads remained usable. This report does not establish a general service outage.
- Files had been saved independently, but the inaccessible executor prevented further local preparation and transfer. No new data loss is claimed.
- Related reports reviewed: Dots cloud computer failed: “Root executor preparation for your dot failed” / env unavailable (Windows desktop) #50545 has the same capability-query error; Managed cloud executor handshake fails while runtime status reports running/connected; later recovers with files intact #51028 describes a different managed-cloud handshake failure and later recovery; [Dots] Cloud desktop unavailable after dock restart; add stream recovery and force VM reboot #50407 requests recovery independent of the guest shell. This report adds the transfer-timeout sequence and 25-second session-resume failure; a shared cause has not been established.
- Account details, private filenames/paths, archive contents, and runtime/task identifiers are omitted.
Please investigate the executor disconnect and failed recovery, and advise a supported way to restore the existing cloud computer without resetting its data.
Activity
github-actions commentedon Oct 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
COOLak commentedon Oct 9, 2026
Update from the owner (2026-10-10):
/feedbackdiagnostics from the affected dot's thread in the Windows desktop app (category: Bug; diagnostic logs and browser logs included). Feedback ID:01a120de-8c7d-72ed-a11b-c5ae227c8021Orbit activity stream failed stage=snapshotfor this dot, and a message to the dot timed out after 300 s waiting for its first response (13:12 UTC).codex doctorreports no failures; the app's local remote-control connection shows Connected; a full app restart changed nothing. Client-side causes have been ruled out as far as the logs allow.COOLak commentedon Oct 9, 2026
Completed the additional diagnostic pass. The cloud computer is still unavailable: the final minimal
pwdprobe at approximately 16:01 UTC on 2026-10-09 was rejected before execution with “No usable execution environment is available.”I have prepended the full findings to the original issue, preserving the earlier report. Key additions:
26.1002.7124.0; the dot's cloud executor still failed its configuration-capability query.POST /cloud-aeons/primary/reboot, with automatic retries disabled. The handler bypasses the ordinarysa_server_request_failedlogger, and the six inspected logs did not reveal the failed reboot's HTTP status, response or request ID. Its generic error can represent local validation, network or HTTP failures.thread/read-32003: thread access deniederrors were observed. No causal relationship to the executor failure was established.Please investigate the managed executor startup/reboot path using the feedback and support case already submitted, and provide a recovery route that preserves the existing cloud environment's files. A sanitized error class/status/request ID in reboot failures would help diagnose this without exposing credentials.
COOLak commentedon Oct 9, 2026
Update from the owner (2026-10-10, after the Microsoft Store update):
26.1007.21434, bundled Codex CLI0.162.0-alpha.17.2). The app was relaunched twice afterwards. The dot's cloud computer is still "Computer unavailable"; nothing changed.Connecting → Connected; 17:49:01 and 17:49:07Local Work executor connected to rendezvous(laptop side healthy, as before).orbit.startup.stage→client.readyoutcome=success.Computer snapshot display connectionState=connecting result=loaded source=placeholder(viewer never leaves the placeholder).Orbit computer stage event=orbit.computer.stage operation=list stage=request outcome=cancelled httpStatus=undefined durationMs≈2050 / 2007— the computer-list request is cancelled after ~2 s, twice; noenvironment_connectedevent follows.Orbit catalog task metadata could not be loaded status=undefined(seen at every app start since 2026-10-01).-32600 grpcStatusCode 5 "Some requested entity was not found: thread not found"onthread/readfor a durable thread.failed to refresh plugin cache for browser@openai-bundled: failed to activate updated plugin cache version: Access is denied. (os error 5)at 17:23:48.codex doctoron the new bundled CLI: 20 ok / 0 fail (same optional notes as before). No proxy, no firewall change.01a120de-8c7d-72ed-a11b-c5ae227c8021; OpenAI support case #16851292 is open and escalated.COOLak commentedon Oct 9, 2026
Update from the owner (2026-10-09, ~19:30 UTC) — the Reboot control has now largely disappeared, and the one remaining entry point is accepted but ineffective.
Where the Reboot option has gone
26.1007.2314.0(after the Store update), verified 19:17–19:27 UTC:…menu for the dot: Rename / Move to right pane / Delete only. No Reboot.Reboot from the sidebar menu: accepted, no effect
configRequirements/readand repeated pubsub room re-subscriptions (chatgpt_pubsub_topic_subscribed, catchupCount=0) at 19:25:50, 19:25:56, 19:26:04 and 19:26:16Z.Other log facts in the current app session (started 18:25:37Z)
thread/readfor the dot's root thread and five of its child task threads with-32003 "thread access denied"on every refresh: 112 occurrences in this session, 55 in the previous one, and the same pattern is already present in logs from 2026-10-07 (one session has 7001). Despite that, the locally cached primary-dot selection still reports the dot as available, status active, not paused, last check-in 18:26:11Z, profile updated 19:11:56Z.connectionState=connecting,source=placeholder) and the orbit computer list operation was cancelled at startup (18:25:51Z, 18:25:55Z).Connected(enrolled machine BOOK-E8U7FPF4UQ),Local Work executor connected to rendezvous.Question for the team: is removing the Reboot control while the computer is unavailable intentional? If so, the only user-facing option left is Delete in the sidebar menu (the app shows no "Reset" control; Delete archives the conversations and removes memories and scheduled tasks). I have not used it and am waiting for a server-side fix.
Support case #16851292 has been updated with the same information.
COOLak commentedon Oct 9, 2026
Follow-up (2026-10-09, 19:25–19:46 UTC) — server-side state read directly from the backend with the app's own login, and what Reboot actually does.
GET /cloud-aeons/primaryafter pressing Reboot (19:25:40Z): the dot's profile flipped tois_paused: trueat 19:25:44Z (it wasfalseat 19:11:56Z) andlast_check_in_atmoved to 19:25:43Z. It stayed paused until I chose Resume in the sidebar menu at 19:40:59Z. So in this state the Reboot flow pauses the dot and never brings it back; the sidebar menu silently switches from "Pause" to "Resume" afterwards.GET /tbo/{dot}/environment/status(what the computer pane polls): before Resume →{"environmentId": null, "status": "unknown", "capabilities": []}; after Resume →{"environmentId": "ccarenv_…", "status": "offline", "capabilities": []}. Resume also rotated the dot to a new root thread and the computers list now reports the OpenAI cloud computer asis_attached: true,can_connect: false,can_stream: false. Stillofflinewith no capabilities at 19:46Z, more than five minutes later.POST /tbo/{dot}/computers/{cloud_environment}/connect→ 409 "The OpenAI cloud computer cannot be disconnected or replaced". The hidden/cloud-aeons/by-thread/{thread}/doctor/check-in→ 404. No start/wake endpoint exists in the client's API surface; the only environment-level mutation the client knows isPOST /tbo/{dot}/environment/recreate(the "Retry" behind "Couldn't start computer"), which provisions a fresh environment and is not offered in the current UI state. I have not called it because of the data-loss reports ([Dots] Cloud computer lost files and browser sessions after Offline → Starting — is this intended? #49821).kind: user,status: connected,can_use_for_tasks: true— the local side is fine.Net: the dot's cloud environment is recorded server-side but stays
offline, and every user-facing recovery path (Reboot, Resume, re-connect) is a no-op or blocked. This needs the environment restarted or re-provisioned on OpenAI's side with the existing data preserved.COOLak commentedon Oct 9, 2026
Follow-up (2026-10-09, 19:53–19:55 UTC) — the hidden "dot doctor" is server-gated off for this account, so it cannot be used as a recovery path.
The desktop client contains a hidden dot-summary section (
orbit-doctor) with two actions: "Set up recurring doctor" →POST /cloud-aeons/by-thread/{thread_id}/doctor/setupand "Check in now" →POST /cloud-aeons/by-thread/{thread_id}/doctor/check-in("requests an immediate doctor check-in, starting the recurring doctor if needed"; the schedule link points at Temporal). The section is hidden behind a client feature gate, so I called the endpoints directly with the app's own login:404 {"detail":"Not found"}for every thread id tried: the current root thread, the previous root thread, the messaging conversation, a child task thread, the dot id, and a deliberately bogus id.GET /cloud-aeons/by-thread/{bogus}returns404 {"detail":"Your dot was not found"}, so the doctor handlers reject before resolving the dot — i.e. a server-side feature switch, not a lookup miss.x-openai-thread-route,OAI-Device-Id,X-OpenAI-Orbit-Selection, omitting the account header, browser-style headers.GETandPUTreturn 405, confirming the routes exist.GET /tbo/{dot}/automationsstays empty, so nothing was created.If the doctor is the intended self-heal mechanism for a dot whose cloud environment is stuck
offline, it would help to enable it for affected accounts (or run it internally for this dot). Current state is unchanged: environmentoffline,capabilities: [], Reboot pauses the dot, Resume re-attaches but does not start it.COOLak commentedon Oct 11, 2026
Update — 2026-10-11: the cloud computer eventually became usable again on its own. None of the recovery attempts described in this issue restored it when tried. This is recovery of this incident, not confirmation that the underlying bug has been fixed. The exact recovery time and the backend event responsible are unknown; it appears that something changed silently on the service side, but I cannot verify what happened.
Please keep this issue open for investigation. The failure left the cloud computer unavailable while the local computer connection and other app functions remained usable, and the available recovery controls did not restore execution.
OpenAI support case #16851292 is tracking the same incident. Every browser/network troubleshooting step suggested in the latest support email had already been tried early in the incident, and none helped:
The additional steps acknowledged in that email—restarting the app and PC, testing the Windows app/web/mobile, using Reboot and Resume, and updating the Windows app—also failed to restore the cloud computer at the time. The eventual recovery should not be attributed to those steps.
The collected diagnostics cover the unavailable-computer period, executor transport/readiness failures, desktop and renderer activity, ineffective recovery attempts, and the subsequent native Doctor/build diagnostics. Doctor setup/check-in returned 404 during those tests; that response alone does not establish whether policy, deployment, or resource lookup caused the failure. No Doctor start or successful repair was observed during the diagnostic pass.
Diagnostic log archive: chatgpt-dot-52509-logs-20261011.zip (5,297,781 bytes).
The archive contains 38 available native Windows app logs from October 7-11 (183,569 lines), 487 selected runtime warning/error rows, diagnostic receipts and correlation facts, source audit summaries, and 17 reviewed screenshots. Its README and SHA-256 manifest describe the finite collection and redactions. Original full sources remain local; credentials, private identities/paths and unrelated payloads are excluded. The later local logs do not independently establish the cloud recovery time or cause.
Archive SHA-256:
5c9b5f9f1aa3382da859db2a773e7ae48097d4312e1db910070687724b1b7339. The public GitHub download was independently retrieved and matched this hash. The same archive has now been attached to my reply in the existing OpenAI support case, after collection and independent review were complete.Please correlate the outage and eventual recovery with the service-side executor/environment and recovery-operation logs, using support case #16851292 and the previously submitted feedback diagnostics. It would help to explain what changed, whether the underlying defect has been addressed, and what supported recovery procedure should be used if this happens again, with explicit guarantees about preserving the existing environment's files.
pvillavi commentedon Oct 11, 2026
Another affected dot cloud-computer session, on October 11, 2026. The observed disconnect/recovery sequence closely matches this issue, although a shared root cause has not been established.
Sanitized timeline (UTC):
startingtofailed, withfailed to read executor configuration for environment.transport disconnectedandrecovery timed outafter a video had been rendered locally and successfully decoded for validation. The interruption blocked the remaining delivery workflow.I have encountered recurring environment failures and, in some cases, what appears to be a restart. That recurrence is my observation; a restart, environment replacement, and data loss were not demonstrated in this particular incident. The pending upload ultimately succeeded.
The affected execution host was dot's own cloud computer. This was not a local Mac going offline or a permission denial. Exact client and managed-executor versions were not captured.
Impact: long-running work is interrupted near validation/delivery, and recovery requires checking existing files and pending operation outcomes before retrying to avoid duplicate work or uploads.
Please include this occurrence when investigating executor disconnects and configuration/recovery failures. A clear recovery status, preservation of the existing workspace, and unambiguous outcomes for in-flight operations would help. Private project contents, account details, paths, and environment/task/file identifiers are omitted.