Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Dot cloud task control regression: readable tasks return UNKNOWN/NOT_FOUND on continuation; direct resume also fails

Open
  • Is something wrong?
#52,374 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Domain
api, cloud

Research direction

The payload names no source files, tests or entry points in this repository; the failures are backend errors (UNKNOWN, NOT_FOUND) from cloud_threads send_message and create, and the cause is unknown. Reproducing needs access to the Codex Cloud backend and the listed request IDs, which a newcomer does not have. Work on this with a maintainer before writing any patch.

Written by the indexing model from the issue text.

Description

app-server bug codex-web dots

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 wrong and 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

  • #50015: same UNKNOWN create/follow-up pattern with readable history
  • #50168: readable cloud task but NOT_FOUND write path
  • #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.

Dominant language
Rust
Stars
129k
Forks
20.3k
Avg merge
1m
Merged PRs (30d)
998

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.