TDove
October 15, 2026, 4:12pm
1
Environment
Surface: ChatGPT Web/dots → Codex Cloud
Codex version: Unknown
OS/browser: macOS; exact OS and browser versions not recorded
Model: Not recorded
Plan/authentication: ChatGPT subscription login; exact plan not included. No API key used for these requests.
Bug
I’m experiencing task-delegation failures across multiple dots. In a verified example, the dot can list Cloud environments and read existing task results, but creating or continuing tasks intermittently returns AppServerBackendRequestError with error_code: UNKNOWN.
Expected: The dot starts the authorized task or returns a specific, actionable error.
Actual: Requests fail before any new execution is visible. Directly entering an instruction into the existing Cloud task worked and produced a verified file download. Some delegated requests succeeded earlier, but the failures returned.
Reproduction
Use a published Codex Cloud environment.
Ask a dot to create a task or continue its existing task.
Observe AppServerBackendRequestError / UNKNOWN.
Check task history and listings. In our failed attempts, no corresponding new task or turn appeared.
Enter an instruction directly into the existing task UI. In our October 15 test, this succeeded.
We tried minimal prompts, fresh tasks, existing-task continuation and recent-context inheritance. None restored reliable delegation.
Diagnostics
Exact error:
October 15, 2026 — all times UTC:
Approximately 10:18–10:19: continuation and creation failed. Request ID: a0779ca2-bb01-43b1-b478-76c229418345
Approximately 15:44: another creation attempt failed. Request ID: a7143718-2c6c-4d54-ae2b-ca6e3f98c1d9
By 15:58: a direct user instruction successfully downloaded the file; its byte count and SHA256 matched the expected values.
Frequency: Intermittent earlier, then repeated across multiple requests. I’m now observing similar problems across all my dots; the request IDs above document one dot’s failures.
A separate proxy CONNECT 403 was addressed by allowing the exact destination hostname and republishing. The subsequent direct-UI download succeeded. The remaining UNKNOWN errors happen before execution, so we have not established a shared cause.
Related reports:
opened 02:32PM - 08 Oct 26 UTC
bug
codex-web
app
app-server
dots
### What version of the Codex App are you using (From “About Codex” dialog)?
Ve… rsion 26.930.51102
### What subscription do you have?
Max 200
### What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64 *** AND *** iOS
### What issue are you seeing?
My assistant (dot) can list saved cloud environments and read task results, but delegated task creation and continuation fail. Starting a task directly in the product UI using the same saved environment succeeds.
Behavior:
Delegated launches fail with a generic UNKNOWN error. Follow-up task listings show no corresponding newly created task. Direct UI launches succeed, and the assistant can read their completed results.
A separate observation: attempting to continue a UI-created task through the assistant returns CloudThreadNotFoundError / NOT_FOUND, despite read access. This may be an intentional access boundary and should not be assumed to have the same cause as the creation failure.
What still works
- Saved-environment discovery
- Task history and result retrieval
- GitHub connector reads and writes
- Direct UI task creation
Timeline
Observed on October 8, 2026. The last successful delegated task completed around 03:51 UTC; failures began around 04:10 UTC. Direct UI success and delegated creation failure were verified again around 13:49 UTC.
Environment
ChatGPT Pro; direct UI test from web on Windows; saved Codex Cloud environment. Earlier failures were also observed while using iOS.
Troubleshooting already performed
- Tested a minimal, read-only prompt
- Tested without explicit model or reasoning overrides
- Compared existing-task continuation with fresh-task creation
- Confirmed the saved environment remains listed
- Checked task listings after failed creation attempts
No explicit quota, approval or model-access error was returned. The underlying cause remains unknown; this report does not establish a service-wide outage.
### What steps can reproduce the bug?
1. In the product UI, select a saved cloud environment.
2. Submit: “Reply STARTED and stop.”
3. Observe that the task completes successfully.
4. Ask the assistant to create a task in the same environment with an equivalent minimal prompt.
5. Observe AppServerBackendRequestError with error_code UNKNOWN.
The delegated test omitted explicit model, reasoning, service-tier, skills and inherited-context settings. Continuing an existing assistant-created task also fails with UNKNOWN.
Expected behavior
The assistant should be able to start the task, or receive an actionable error explaining why delegated execution is unavailable.
### What is the expected behavior?
The assistant should be able to create and start a task in an accessible saved cloud environment, and continue tasks it previously created. Successful requests should return a task/turn ID and make progress visible.
If execution is unavailable, the system should return a specific, actionable error explaining the restriction or failure, rather than UNKNOWN.
Read access to a separately UI-created task does not necessarily imply permission to continue it.
### Additional information
Is there a known difference in authorization or routing between direct UI launches and assistant-delegated launches that could explain this behavior? What diagnostics would identify the failing stage?
Request IDs, task IDs and environment identifiers are omitted from this public report and can be provided privately to maintainers.
opened 02:33AM - 09 Oct 26 UTC
bug
codex-web
app-server
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.
opened 02:02PM - 06 Oct 26 UTC
closed 04:48PM - 09 Oct 26 UTC
bug
codex-web
app-server
dots
On October 6, 2026, manually creating a new cloud task worked, but dot-initiated… creation of new cloud tasks and continuation of existing tasks repeatedly failed with:
`AppServerBackendRequestError: Something went wrong`
`error_code: UNKNOWN`
Listing saved cloud environments and reading existing tasks continued to work. New-task requests selected the saved cloud environment. Subsequent task-list checks did not show a newly created delegated task.
The root cause is unknown. We have no evidence that disk exhaustion or idle reclamation caused this failure.
Expected: dot can create or continue the cloud task, or receives an actionable diagnostic explaining why manual task creation works while this path fails.
Please provide a non-destructive diagnostic or recovery procedure. Account details, project names, private task/environment IDs and request IDs are intentionally omitted.
Is this a known active delegation issue? Is there a supported, non-destructive recovery procedure? How can we reliably determine whether a failed request was admitted before retrying and risking duplicate work?
Private task/environment IDs and additional diagnostic details can be provided through Support.
3 Likes