Repository navigation
dot cloud task creation and continuation fail with AppServerBackendRequestError / UNKNOWN while manual creation works #51372
Description
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.
Activity
github-actions commentedon Oct 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
NaturalMatchaKing commentedon Oct 7, 2026
Adding an independent observation from October 7, 2026 (UTC), involving dot-mediated cloud task creation and continuation.
AppServerBackendRequestError.Desktop environment: Windows 10; exact client version not captured. Successful manual creation has not been verified in this case, so this comment corroborates the error path rather than every part of the original report.
Please provide a non-destructive way to reconcile the last readable turn, current execution/admission state, and safe retry eligibility. An actionable failure should make clear whether a request created a task or started a turn, so users can avoid duplicate execution.
No root cause is established. Private project/task/environment/request identifiers, names, paths, prompts, screenshots and raw logs are omitted.
LikelyLucid commentedon Oct 8, 2026
Additional reproduction: October 8, 2026 (UTC)
Observed in ChatGPT web with a Linux execution environment. Saved cloud task creation reproduces the error described above.
Steps and result
Both creation requests returned
AppServerBackendRequestErrorwitherror_code: UNKNOWN. Subsequent task listings showed no new task. This does not establish whether an unlisted partial operation exists server-side.Expected: a new cloud task is created, or an actionable error explains why creation failed and whether the request was admitted.
Request references
366ae27b-c5e2-4848-aea3-a1ffabb6d9fbfcd6a9e5-b026-4a55-b077-d86541d9687fwfr_b62e292f684a4ba09b2d31d2060f305dSeparate CLI observation
At approximately 02:53 UTC on October 8, using
codex-cli 0.159.2:codex login statusreportedLogged in using ChatGPT.codex cloud list --limit 1 --jsonexited with status 1 and HTTP 401:Could not parse your authentication token. Please try signing in again.No CLI task was launched and no credentials were changed. There is no established causal connection between this CLI authentication failure and the cloud-task connector's
UNKNOWNerror; the CLI observation is included only as separate troubleshooting evidence.Please investigate the request references and advise a supported, non-destructive diagnostic or recovery path.
Repository details, company information, account identifiers, credentials, and private task/environment identifiers are omitted.
Cameron10TA commentedon Oct 8, 2026
Additional observation, October 8, 2026 at approximately 05:47 UTC:
The symptom-matching OpenAI incident was marked resolved October 7, but these failures persist: https://status.openai.com/incidents/01M4BK9J2M83R4SSC71D9FXW45. This does not establish a causal connection.
Could maintainers investigate actor identity and task routing, and provide a supported, non-destructive diagnostic or recovery procedure? Please include how to verify request admission and safe retry eligibility without duplicate execution. Restoring dot-driven creation and continuation is the goal; manual task creation does not resolve that workflow.
lloydboybebop commentedon Oct 8, 2026
I’m seeing the same issue. Existing cloud workers briefly resumed on October 7, then continuation and fresh-task creation started failing with AppServerBackendRequestError / UNKNOWN. Read, list and environment-discovery operations still work. Fresh read-only task creation also fails, with no new task visible afterward. A prompt entered directly by the user is accepted and marked running. Please provide a supported, non-destructive recovery procedure and a way to verify whether failed requests started work.
kaikaitaketake-lang commentedon Oct 8, 2026
Additional report: web-only use; direct Codex requests succeed
Submitted at an affected user's request. These observations were reported by the user and have not been independently reproduced by the reporting assistant.
When the user asks their dot to start a new Codex task or send follow-up instructions to an existing task, the dot reports:
Both new-task creation and continuation fail, across multiple unrelated tasks. No task code execution is observed after these requests. The dot can still read past task results.
Key comparison: Instructions submitted directly by the user in the Codex web interface execute successfully. In the user's observations, the failures occur when instructions are sent through the dot.
Reported reproduction
Expected: The dot can start and continue eligible Codex tasks.
Actual: Dot-mediated start/continuation fails, while past-result reading and direct Codex execution remain available.
Please investigate the dot-to-Codex request path and advise a supported recovery procedure that preserves existing work. The underlying cause and whether a failed request was accepted server-side have not been established.
philbritton commentedon Oct 8, 2026
We are also seeing dot-mediated cloud task creation and continuation fail with
AppServerBackendRequestError/UNKNOWNon October 8, 2026, while listing saved environments and listing/reading existing tasks work. The saved coding environment is visible. Minimal read-only task requests also failed, and no newly created cloud task was confirmed afterward. Manually started coding tasks have progressed successfully. Separately, laptop task creation can succeed but shell startup fails with a Windows setup-refresh error; that is a distinct symptom, not an established common cause. In-app feedback covering the cloud-task and Windows-runner failures was submitted under feedback ID01a0f244-58e2-7159-9695-2223abdfb0d8. Failed cloud attempts were recorded around 09:22 and 12:31 UTC on October 8; underlying cause and recovery remain unconfirmed. Private computer details, prompts and logs are omitted.ChrisTinaAmadeus commentedon Oct 9, 2026
我这边 10 月 5 日的记录也有同样问题：让 dot 继续已有云任务，或用同一环境创建新任务，都会返回：
原计划的诊断未执行，也没有确认失败请求是否在服务端创建了任务。希望报错能说明实际任务状态，以及能否安全重试。
michaeltockstein commentedon Oct 9, 2026
Still reproducing on October 9, 2026. Assistant-initiated creation from a published cloud environment fails with AppServerBackendRequestError / UNKNOWN. Manual creation from the same environment succeeds, commands run, and direct messages continue the task. Republishing did not restore assistant creation. Latest failed create: approximately 12:47 UTC, request wfr_01a120b3ca4e7168aef518436d144908. Nine additional resume attempts failed overnight. I can provide the private task URL and environment details through Support. Is there an engineering investigation or supported recovery procedure for this specific creation-path failure?
hx123321 commentedon Oct 9, 2026
Resolved for me: in the web version, open the menu in the upper-right corner of the dot conversation and click "Restart dot". This restored dot-initiated task creation and continuation for me. Closing this issue as resolved.
Cameron10TA commentedon Oct 9, 2026
Could this issue be reopened? Following up on my earlier report: recovery is still unverified on my account. Some cloud task creation has worked, but the latest observed attempt to continue an existing task failed with NOT_FOUND.
I have not yet verified the reported Restart dot workaround on this account, so I cannot confirm this is resolved for us. Please reopen the report for investigation or let us know the supported verification steps.
fichil commentedon Oct 10, 2026
Additional reproduction on October 10, 2026 (UTC), after this issue was closed: dot-initiated cloud-task creation still failed in my personal account/workspace.
Steps and observed results
AppServerBackendRequestErrorwitherror_code: UNKNOWN, without a usable new task identity or any visible checkout/setup execution.The three failures were recorded at approximately 03:15, 03:17, and 05:20 UTC. The first two used the same saved configuration; the third used another listed configuration. Server-side admission or an unlisted partial operation has not been verified.
Additional environment UI observation
The new environment UI disables editing the internet toggle and displays “Ask your admin for edit access”, even though this is a personal workspace. Two same-named configurations appear unpublished. A screenshot of the older environment UI shows editable network settings with networking enabled, but successful task execution through that older UI has not been verified. We have not established that this UI discrepancy causes the creation error.
The “Restart dot” workaround reported above has not been verified for this account. Restarting the Windows computer during separate local troubleshooting is not evidence of testing that workaround. Exact client and backend build versions were not collected.
Expected result / request
Please investigate why a catalog-visible saved cloud environment cannot admit a minimal task, clarify the personal-workspace editing restriction, and provide an actionable failure or safe recovery procedure. If this needs a separate issue, please advise.
No security settings were changed. The root cause and any relationship to subscription level are unknown. Account email, repository names, private task/environment identifiers, request IDs, screenshots, and source code are omitted from this public report. Submitted with AI assistance at the affected user's request.
fichil commentedon Oct 10, 2026
Update to my earlier report: “Restart dot” restored dot-initiated cloud-task creation. A task launched from a saved cloud environment can now run commands and read the repository.
The remaining blocker is environment configuration and dependency downloads in my personal account/workspace:
I have not confirmed that the inspected UI configuration is the one used by the task, or that “Unpublished” causes the 403 responses.
How can a personal-workspace owner edit and publish these network settings, and verify which configuration and internet policy a cloud task actually uses?
KevinCJM commentedon Oct 10, 2026
"Restart dot" also helped me on October 10, 2026, with dot-managed local tasks on a Mac mini.
Before the restart, dot could not list desktop projects, new-task requests left empty tasks, and follow-up messages failed with "thread not found." After I used "Restart dot," project listing worked again. A new-task request still returned "-32603 Internal error" and left an empty task, but a follow-up sent to that same task now started execution successfully. It confirmed its working directory, listed the directory, and accepted another instruction.
This restored my ability to run and continue the task, although the initial creation error remains.
hi426436-stack commentedon Oct 14, 2026
At around 22:04 UTC on October 14, 2026, attempting to continue existing Codex cloud tasks through dot resulted in AppServerBackendRequestError / UNKNOWN. Listing those same tasks and reading their results still succeeded. Work had been running successfully shortly beforehand, but continuation requests for two existing tasks failed.
The cause has not been established. If anyone has recovered from similar symptoms, could you share your environment and what worked for you?
135f2l commentedon Oct 15, 2026
Follow-up on October 15, 2026: restarting dot restored follow-up messaging temporarily, but the failure returned about 45 minutes later. All times below are UTC.
2c5f08cb-8a78-4f59-b77e-d6ecfede755d.AppServerBackendRequestError/UNKNOWN. Recorded request reference:a7e06688-b5d8-4602-91af-0aefdf8d10c7.Separately, at approximately 02:18, a send to a user-created task returned
CloudThreadNotFoundError/NOT_FOUND, similar to #50168. That is a separate observation; the recurrence above affected a dot-created task that had demonstrably accepted multiple follow-ups.Client: macOS desktop app; exact app version was not captured. The elapsed time is one observed interval, not an established timeout. No backend cause or server-side admission state is established.
Could this issue be reopened to investigate recurrence after the Restart dot workaround? A supported, non-destructive recovery procedure and a way to determine whether a failed send admitted a turn would help avoid duplicate execution.
Private repository names, code, data, task/environment identifiers and account details are omitted. Request IDs are included for diagnostic correlation. Posted with AI assistance at my request.
athome-inc commentedon Oct 16, 2026
Additional reproduction on October 16, 2026: frequent recurrence after Restart dot makes sustained cloud-task coordination unreliable. Submitted with AI assistance at the affected user's explicit request.
Observed in ChatGPT web on Windows, coordinating an existing cloud coding task. Exact browser/client build was not captured. All times below are UTC.
The user reports the same symptom in both Business and personal accounts; the personal account was used less for cloud work, so the issue initially went unnoticed there. This is a user observation, not an independently controlled account comparison. Waiting can sometimes recover a send without restarting, but multiple spaced attempts also fail. Restart is at best a temporary workaround, not a demonstrated permanent fix or requirement after every instruction.
Please reopen or route this to the responsible engineering team to investigate recurring dot-to-cloud instruction failures. We need a durable fix and a supported, non-destructive diagnostic that distinguishes failed submission, accepted-but-unacknowledged work, and genuinely stopped execution. Reliable admission/reconciliation information is important to avoid duplicate work or paid requests. Frequent manual restarts defeat the unattended workflow.
No backend root cause is established. Account emails, private project/task/environment identifiers, request IDs, prompts, source code, screenshots, raw logs and business data are omitted from this public report.