Repository navigation
dot cannot start a task on a connected, authorized computer: AppServerBackendRequestError (UNKNOWN) #49566
Description
App version / platform
Desktop app version and host OS build have not yet been collected because I am away from the computer. The conversation client is ChatGPT on Android. This report concerns dot-initiated work on a connected personal computer, not a demonstrated Codex CLI failure.
What issue are you seeing?
Starting a new task on the connected computer repeatedly fails with:
AppServerBackendRequestError: Something went wrong
error_code: UNKNOWN
Immediately before the failed attempts, the computer is reported as connected, attached, and authorized for tasks. The permission was enabled on September 30, 2026, around 09:40 UTC. Subsequent task-list checks did not show a newly created local task. I cannot confirm whether an unlisted partial operation exists server-side.
Steps observed
- Enable computer access for the dot and keep the computer connected.
- From the Android conversation, ask the dot to start a small read-only task on that computer.
- Task creation returns the error above before any local inspection can be performed.
- Rechecking the connection still shows access authorized. Checking the task list does not confirm a new local task.
The failure occurred with explicit selection of the computer and with the default single attached computer. Reducing the request to a short read-only inspection did not resolve it.
Expected behavior
A new task starts on the authorized computer, or the error identifies the actionable connection, app-version, or service problem.
Timing / troubleshooting
Repeated attempts on 2026-09-30 between approximately 09:45 and 10:16 UTC (18:45–19:16 JST). Last observed failure: 10:16:43 UTC.
I contacted the official Help Center AI support and supplied timestamps and request IDs privately. It could not confirm a cause or a human escalation, and directed me to the Codex issue tracker. The advertised / feedback option did not appear in the Android dot conversation composer.
A contemporaneous public ChatGPT incident affected conversations, but its relation to this failure is unconfirmed. Please do not treat it as the established cause.
No forced desktop restart, access revocation, or interruption of existing work has been attempted. Please advise a non-disruptive diagnostic/recovery path, or redirect this report if another team owns dot-to-computer task creation.
Account email, computer identifiers, request IDs, private conversation content, and project files are intentionally omitted from this public report. Request IDs have already been provided through the private support channel.
Update — September 30, 2026
The user reports having updated the app at approximately 15:00 JST (06:00 UTC) today, before the failed task-start attempts. The exact installed version has not yet been verified, so this is not evidence that a particular required build is installed. Please do not assume the app simply has not been updated.
The duplicate-detection bot suggested #49423. That report has a similar connected/authorized-but-cannot-start symptom, but its reported error is DesktopTaskWorkspaceUnavailableError, whereas this report received AppServerBackendRequestError / UNKNOWN. A shared cause is not established. We have kept this issue open pending clarification rather than asserting a duplicate.
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
harryshawk commentedon Oct 3, 2026
Closing as a duplicate of #49585 at the user’s request after comparing both reports. Both describe dot-to-connected-computer task creation returning AppServerBackendRequestError / UNKNOWN despite connected/authorized status, with explicit and default computer selection failing and subsequent listings not confirming admission. #49585 retains more detailed timing, request IDs, and a successful manual Codex-chat comparison. A shared root cause remains unconfirmed.
Feifangongzao commentedon Oct 6, 2026
Additional reproduction on Windows 11, still failing on October 6, 2026. This adds verified client versions, fresh request IDs, a minimal read-only reproduction, and a contrasting successful local-execution control.
Environment
OpenAI.Codex_26.930.4958.0_x64(verified package metadata; not the About-dialog display version).10.0.22631, x64.0.160.0.01a0f0f1-bfad-70e6-be1e-68db4ba9d01d.Minimal task-start reproduction
cloud_threads.list_environments. On the failing connected-host retest it returnedstatus=connected,attached=true, andis_authorized_for_tasks=true.cwdand the selected computer'senvironmentId.cloud_threads.createfails before a file-read result or task execution is available.The actual directory exists. The minimal request uses the ordinary Windows path format, not
file:///. Private paths and environment identifiers are omitted here.Actual task-start errors and correlation IDs
Latest connected-host retest, 2026-10-06 around 02:29 UTC (10:29 Asia/Shanghai):
Previous reproduction, 2026-10-05 around 12:43 UTC (20:43 Asia/Shanghai), used an explicit existing Desktop directory and a read-only top-level folder count:
An earlier retry also failed with request ID
wfr_01a10bc3c31473e6b577e1ee552de65d.The latest connected-host environment, read, and create results were checked against the underlying tool-call records, not inferred solely from the dot's natural-language response.
Separate existing-local-task failure
The ordinary desktop task list confirms that the target task exists with
hostId=local, and the native local task remains usable. Giving that exact ID to the dot and callingcloud_threads.readreturns:No request ID was supplied for this read error. It reproduced again on October 6. A prior independent cloud
thread/readdiagnostic returned JSON-RPC-32602with the same format rejection.This appears related to the read/routing observations in #50704 and #50440, but I cannot establish that it shares the task-creation failure's root cause.
Controls and network observations
command/execrequests through the same account and registered Windows execution environment successfully executed locally and returned a local file's length with exit code 0. This is a bounded execution control, not proof that the normal dot task-start workflow works.hostId=localCodex task.offlinewhile the authorization remained valid. A subsequent lookup failed withExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception). Task creation was not attempted in that offline retest, and it produced no new create request ID. The proxy/node was not independently isolated by that access-network change.Expected behavior / request
An explicitly authorized, connected Windows computer should be able to start this minimal local task, or the error should provide an actionable explanation. Eligible existing local Codex tasks should have a supported read/continuation route.
Please trace the fresh request IDs and the feedback ID, investigate local task-start failure separately from the placement-format rejection, and advise the supported recovery path or required client/service update. If a different team owns this dot-to-local workflow, please route the report appropriately.
No credentials, account email, proxy subscription URLs, private computer names, project contents, or raw logs are included. No task IDs were rewritten, no session stores were modified, and certificate validation, firewall, and access controls were left unchanged. Prepared with AI assistance at the affected user's request.
Feifangongzao commentedon Oct 6, 2026
Follow-up: still failing after a verified Windows desktop update
Follow-up to my earlier report: #49566 (comment)
Retest: October 6, 2026, approximately 13:27–13:28 UTC (21:27–21:28 Asia/Shanghai).
OpenAI.Codex_26.930.4958.0_x64toOpenAI.Codex_26.930.7945.0_x64. These are package versions, not About-dialog display versions.ChatGPT.exeexecutable was verified to come from the new package's installation directory, so this was a retest with the updated app actually running.cloud_threads.list_environmentsreported the selected computer as connected, attached, and authorized for tasks.Minimal local task creation still fails:
cloud_threads.createwas asked to start a read-only task in an existing directory using a native absolute Windowscwd. The task was to read a small existing diagnostic text file and return its byte length.No new task ID or file-read result was returned; local execution was not established.
Existing local task reading also still fails:
The native desktop task list independently confirmed that the target exists with
hostId=local. This read error supplied no request ID. A common cause with the task-creation failure remains unconfirmed.The retest results were checked against the underlying tool-call records. No business files, proxy settings, session stores, or task IDs were modified for this retest. Private task/environment IDs, device names, paths, and conversation contents are omitted.
Please correlate request ID
4170bdcd-8c5c-45b4-85db-3bffde020a00with this timestamp and advise the supported recovery path or required client/service fix. Prepared with AI assistance at the affected user's request.