Repository navigation
Dot cloud task control regression: readable tasks return UNKNOWN/NOT_FOUND on continuation; direct resume also fails #52374
Description
Summary
Observed October 8–9, 2026 (UTC), using ChatGPT web on macOS and iOS with saved Codex Cloud environments. Dot successfully coordinated an existing cloud task earlier, then lost the ability to continue it or create a replacement. Task reads and saved-environment listing still succeed. A newly user-created cloud task is readable, but dot messaging returns NOT_FOUND.
This is a cloud-task coordination report, not a local desktop executor or trading/data API connection issue. Exact client/backend builds are unknown.
Verified behavior
- Earlier on October 8, dot follow-up messages were admitted and actual command execution, file processing, and remote saves succeeded.
- Later, cloud_threads.send_message to that same task repeatedly returned
AppServerBackendRequestError: Something went wrong,error_code: UNKNOWN. - cloud_threads.create with a catalog-returned saved cloud environment also returned UNKNOWN. Subsequent task-list checks showed no newly created delegated task.
- cloud_threads.read and list_environments continued to succeed.
- A direct user message appeared in the old task and its status changed to inProgress, but this alone did not verify command execution. The user subsequently saw
Failed to resume chat. Something went wrongand stopped that task. - The user reset the environment and created a new cloud chat with explicit implementation authorization. Dot can read its exact user instructions and inProgress status, but send_message to that exact readable task returns
CloudThreadNotFoundError,error_code: NOT_FOUND,error_data.type: cloud_thread_not_found. - A final messaging attempt at October 9, 02:32 UTC returned the same NOT_FOUND result.
Selected diagnostic request IDs
- Existing-task continuation:
wfr_01a11e49cba4774496e64774c751a535(October 9, about 01:42 UTC) - New cloud-task creation:
df158839-38e0-4bbc-bc1e-52a7d6a96c54(about 01:10 UTC) - Post-reset continuation:
cb6111de-914c-4ad2-8c66-e5f217786a4b(about 02:10 UTC) - User-visible resume error:
b6ddd305-f88e-4f06-9fbc-55cd02c2c04b - Latest creation retry:
521de1a3-f07b-9cb6-9b6a-514c77751fac(about 02:21 UTC)
Recovery attempts and limits
Bounded retries, direct user continuation, an environment reset, and a new user-created chat did not restore dot messaging. No security settings, credentials, or permissions were changed by the assistant to bypass the failure. The cause is unknown. We have not established disk exhaustion, network geography, model choice, context length, or approval policy as the cause. A separate earlier upload-approval denial occurred, but it is not evidence that these server/routing errors share that cause.
Expected behavior and impact
Dot should be able to continue an authorized readable cloud task, or receive a specific actionable error. Failures have required repeated manual message relays and prevented reliable unattended work. Please provide a non-destructive recovery procedure that preserves existing workspaces and unpublished files, and identify whether the task is actually executing when history says inProgress.
Related reports
- Dot cannot resume or create cloud tasks, while direct messages in the original tasks execute successfully #50015: same UNKNOWN create/follow-up pattern with readable history
- Dot cloud_threads: create returns UNKNOWN and send_message returns CloudThreadNotFoundError for readable Codex Cloud task #50168: readable cloud task but NOT_FOUND write path
- dot cloud task creation and continuation fail with AppServerBackendRequestError / UNKNOWN while manual creation works #51372: manual cloud creation works while dot creation/continuation fail
Please consolidate if this is a duplicate. The October 7 dot thread-creation incident is marked resolved; no connection to this occurrence is established.
Submitted with AI assistance at the affected user's request. Private task/environment IDs, repository names, paths, source data, credentials, and conversation contents are omitted. Request IDs are included for backend tracing only.
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
crystal-xiaoxiao commentedon Oct 9, 2026
Same symptom on my account. Adding request IDs for backend tracing.
Setup: ChatGPT web, "Your dot". A recurring scheduled task created with the dot's native automation tool. On each run, the dot verifies a saved Codex Cloud environment with
cloud_threads.list_environments, then starts the worker withcloud_threads.create.Last success: 2026-10-08, roughly 10:00–12:00 UTC. The same dot created cloud tasks in two saved environments, including the environment that now fails. Those delegated tasks ran end to end: commit, push and Pages deploy.
Failing since 2026-10-09:
cloud_threads.list_environmentsstill succeeds. It returns the expected environment, repositories andmainbranch.cloud_threads.createreturnsAppServerBackendRequestError: Something went wrong,error_code: UNKNOWN.Request IDs:
wfr_28b1bde342ad43788c39b65626179759: natural scheduled run, scheduled for 2026-10-09 05:17 UTC27be7d5f-8f82-4276-94cf-5db6f7b2277c: manual retry in the dot conversation, about 2026-10-09 07:06 UTCThis is not a missing-tool problem. The create tool is present and environment listing works. As far as I know, no environment configuration changed between the last success and the first failure. This looks like the same issue as #52135 and #51372.
Is there a non-destructive workaround, for example re-binding the environment, while this is investigated?
Posted with AI assistance at the account owner's request. Private task/environment IDs, repository names and conversation contents are omitted.
n572770 commentedon Oct 12, 2026
Additional reproduction — October 12, 2026 (UTC+8), Windows / Dot → existing Codex task
Adding a fresh instance of the read succeeds,
cloud_threads.send_messagefails issue. The user authorized reporting and non-destructive investigation.Observed (from the affected Dot's tool results, relayed by the user):
cloud_threads.read; its latest known turn wascompleted. No new turn was observed after the failed sends.cloud_threads.send_messageto that same existing task fails before a verifiable follow-up turn appears:wfr_01a12fb970b07488acee496649a28f89493f2a8a-096e-4309-bc04-123f9063fe12connected,attached=true,is_authorized_for_tasks=true. This is context only, not proof of the Codex Cloud write route.Separate local read-only checks (not equivalent to the Dot Cloud API): On the connected Windows machine, installed Codex app package
26.1002.7124.0; separately installed CLIcodex-cli 0.160.0. The CLIcodex cloud list --jsonreturned no WHAM tasks;codex cloud status <the cloud_threads thread ID>returnedInvalid task IDfrom/backend-api/wham/tasks/. These commands may use a different task identifier/API thancloud_threads; this does not prove the original thread is missing, and neither was used to mutate it.Requested backend investigation: Please correlate the two request IDs with the readable Codex task and identify whether the write failed at routing, task provenance/ownership authorization, turn admission, or a post-cutover placement mapping. If the write was not admitted, return a deterministic actionable error; if admission is ambiguous, expose an idempotent confirmation/recovery mechanism. We need a supported non-destructive continuation path preserving the existing task, source files and authorization boundaries.
This is distinct from unrelated site-release verification and application-level runtime issues, which were never reached during the failed continuation. Private task/turn IDs, machine hostname, project paths, repository content, and credentials are omitted.
n572770 commentedon Oct 12, 2026
Recovery update — October 12, 2026, 11:50 UTC
The affected user has now verified that continuation works again for the original existing task, without recreating that task.
cloud_threads.readsuccessfully confirmed the original task.cloud_threads.send_messagesuccessfully started a new turn in the same task.READ_ONLY_MESSAGE_TEST_OK 20261012T1150Z.Before this successful check, the Windows installation was updated in place:
OpenAI.Codex26.1002.7124.0→26.1007.2314.0.0.160.0→0.162.1.Causation is not established: the result is consistent with a client/runtime update resolving a problem or with a coincident backend recovery. There was no controlled pre/post test isolating these causes. The previously submitted request IDs remain available for backend correlation.
The original task and all existing project files were preserved. Separate release/verification workflow issues are not considered fixed by this messaging recovery. Thank you.