Repository navigation
dot-to-desktop task creation fails with UNKNOWN on macOS; manual Codex chat works #49585
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT desktop app 26.928.21956, from About ChatGPT. The dialog shows “Powered by Codex & OWL” and a release date of September 30, 2026. This is the desktop app version; the bundled Codex CLI version has not been collected.
Affected experience: dot creating a task in Codex/Work on my Mac.
What subscription do you have?
Pro
What platform is your computer?
- macOS Tahoe 26.5
- MacBook Pro, 14-inch, Apple M5, 16 GB memory
What issue are you seeing?
When I ask dot to summarize my Codex work on my Mac, desktop task creation fails with:
AppServerBackendRequestError: Something went wrong
error_code: UNKNOWN
The Mac is reported as connected, attached to the conversation, and authorized for tasks. All three attempts in this incident returned the same error. The first two each took approximately 21 seconds, including a retry using the default attached computer instead of explicitly selecting the Mac.
No child task appeared in the subsequent task listings, so dot could not perform the requested work summary or collect computer diagnostics through a desktop task. The empty listings do not establish whether a partial operation exists in the backend.
As a control, I manually opened an ordinary Codex chat in the ChatGPT desktop app and confirmed that it responded successfully.
What steps can reproduce the bug?
This is the sequence observed on September 30, 2026:
- Keep the ChatGPT desktop app open on a Mac connected to dot and authorized for tasks.
- Ask dot to summarize the day's Codex work on that computer.
- Attempt desktop task creation with the connected Mac explicitly selected. It returns the error above after approximately 21 seconds; the subsequent child-task listing is empty.
- Retry using the default attached computer. The same error returns after approximately 21 seconds; the subsequent listing is empty again.
- Manually open an ordinary Codex chat in the desktop app and send a message. It responds successfully.
- Try desktop task creation again during a later diagnostic check. The same error returns, and no child task appears in the subsequent listing.
Reproduction in a fresh dot conversation or after an app restart has not been established.
What is the expected behavior?
dot should be able to create and start a task on a connected, authorized Mac, or return an actionable explanation of why creation cannot proceed.
Additional information
Timing and request IDs
All times below are UTC on September 30, 2026. The windows are approximate, reconstructed from recorded timestamps and elapsed times rather than precise instrumentation of request start times.
| Attempt | Selection / context | Approximate observation window | Duration | Request ID |
|---|---|---|---|---|
| 1 | Explicit Mac selection | 10:55:57–10:56:18 | ~21 seconds | 4f67f9e9-0b7a-4691-a95c-c7b9e7a7b647 |
| 2 | Default attached computer | 10:56:36–10:56:57 | ~21 seconds | b292f6ea-e0b7-4d41-8578-10b26db7c296 |
| 3 | Later diagnostic check | 11:09:08–11:09:29 | ~21 seconds for the diagnostic check and task-creation call combined; creation was not timed separately | d831cd31-6001-418a-9f65-d07cba8d4ec4 |
Please correlate these request IDs with the task-creation failure. The similar durations do not establish a timeout or identify the failing component. The successful manual chat confirms that one ordinary desktop chat could respond; it does not establish that the dot-to-desktop connection was healthy.
Related reports
- dot cannot start a task on a connected, authorized computer: AppServerBackendRequestError (UNKNOWN) #49566 reports the same error during dot-to-computer task creation with explicit and default computer selection. The duplicate-detection bot linked it here; a shared cause has not been confirmed.
- Realtime Voice loses Codex task-tool handlers and live host route after successful delegation #36404 reports Voice-to-desktop task failures while manual desktop task creation still works.
- Codex Desktop: tool_search advertises read_thread but invocation fails with “No handler registered” until app restart #36013 reports a missing tool handler. I did not observe that error here, and have not confirmed whether an app restart changes this failure.
If this task-creation path is owned outside this repository, please point me to the appropriate reporting channel.
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
[-]dot-to-desktop task creation returns UNKNOWN while direct desktop chat works (macOS, ChatGPT 26.928.21956)[/-][+]dot-to-desktop task creation fails with UNKNOWN on macOS; manual Codex chat works[/+]fukaya0404 commentedon Oct 1, 2026
+1, I can reproduce “AppServerBackendRequestError: Something went wrong (UNKNOWN)” when starting a new dot-to-desktop task. Later, sending a message to an existing task also returned “failed to query executor configuration capabilities”.
App: ChatGPT Powered by Codex & OWL 26.928.31416 (October 1, 2026 release).
Feedback ID: 01a0f0af-0fcd-70c2-a889-7e1d9a957016
HOLYtoma commentedon Oct 3, 2026
I can still reproduce the dot-to-desktop task creation failure on Windows as of October 3, 2026 at approximately 23:15 UTC (October 4, 08:15 JST).
The computer is reported as connected, attached, and authorized for tasks. Creating a read-only diagnostic task with that computer explicitly selected still returns:
AppServerBackendRequestError: Something went wrong
error_code: UNKNOWN
Request ID: 3312bc9c-f2c4-4d82-8ba6-bc0d3932aa20
The subsequent task listing showed no newly created diagnostic task. Reading an existing local Codex conversation also returned “thread not found.” These are separate observed failures; I have not established that they share the same cause.
No desktop settings were changed or applications restarted during this check. Please correlate the request ID above with the task-creation failure and let me know if there is a supported workaround or any additional diagnostic information needed.
tanossy commentedon Oct 4, 2026
I can also reproduce this on Windows. Importantly, local file operations work in Chat Work inside the same ChatGPT desktop app, while starting a local task from my dot fails. This is not only a comparison with the VS Code extension.
Environment:
Minimal test: ask the dot to run
cmd.exe /c echo okon the connected Windows computer. Explicit computer selection with an existing local working directory fails. Omitting the computer selector, working directory, model, and other optional overrides also fails.Observed error:
Recent request IDs and UTC result-observation times:
4fc3d230-d1f6-4dc7-b54a-6d35b976957c— 2026-10-04 00:02:49 UTC.wfr_01a1045d4aeb7177ace187b8747e752d— approximate test/result window 2026-10-04 00:43:50–00:44:28 UTC.wfr_01a10649ab76728194e1455ea3442f64— 2026-10-04 09:41:28 UTC (18:41:28 JST).These are client-side observation times, not exact backend event timestamps. No threadId was returned, and the subsequent child-task listings were empty. No command output or exit code was obtained. This does not establish whether an internal partial operation occurred.
Restarting, reconnecting, and resetting the app had previously not resolved the dot failure. DNS resolution and TCP 443 connectivity checks succeeded, but authenticated WebSocket behavior has not been verified, so I am not ruling out a path-specific network issue.
Could you correlate these request IDs and compare the dot task-creation/executor handoff with the working in-app Chat Work path? The executor-configuration-capabilities error mentioned above may be worth checking, but it has not appeared in my own returned error and I have not established a shared cause.
HOLYtoma commentedon Oct 5, 2026
Follow-up to my Windows report: this still reproduces on October 5, 2026.
At approximately 04:13–04:14 UTC (13:13–13:14 JST), dot checked the desktop connection and then tried to create a fresh task as a communication-only test. The desktop was reported as connected, attached, and authorized for tasks. The request explicitly selected that connected desktop and did not request any repository changes or application execution.
Creation returned:
AppServerBackendRequestError: Something went wrongerror_code: UNKNOWNRequest ID:
29169b61-fc36-493b-9654-b5ef25fed9b5The immediate direct-child task listing completed with no continuation cursor and showed only a pre-existing task. No new child was visible, so I could not test sending a second instruction to a newly created task. I did not repeat the uncertain creation request.
Separately, at approximately 04:08 UTC, sending a follow-up to an existing local Codex task returned
CloudThreadNotFoundError/NOT_FOUND. Pasting the instruction manually into that existing task worked, and the task acknowledged it at approximately 04:11 UTC. These may be separate routing issues; I have not established a shared cause.Please correlate the new request ID with the creation failure. The current desktop app version was not re-collected during this attempt.
HOLYtoma commentedon Oct 5, 2026
Additional diagnostic detail from October 5, 2026, approximately 11:33 UTC (20:33 JST): reading three existing local task conversations from dot returned a more specific error than the previous generic UNKNOWN:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version NThe three respective failures reported versions 1, 2, and 3, each with
error_code: UNKNOWN. Task IDs are omitted here. Another existing task read returnedthread not found.At this check, the Windows desktop was still reported as connected, attached, and authorized for tasks. These were read-only checks; no application settings or project files were changed.
I cannot determine whether these read failures share a cause with the task-creation UNKNOWN error reported above, but the placement-format error may help identify the failing path.
HOLYtoma commentedon Oct 5, 2026
Additional evidence about communication in the reverse direction, plus an update after updating the desktop app:
Before the update, a screenshot of a local Codex task showed it reporting that its direct message to dot had not been delivered because the destination was unknown, and asking for dot's current destination. It also reported a delivery failure from another task. This is an assistant-reported result shown in the UI; the screenshot does not contain the raw tool error or an error code. I am omitting the screenshot and internal identifiers because they contain unrelated project information.
After I updated the desktop app, dot checked the connection and retried sending an already-approved instruction to an existing local task at approximately 17:37 UTC on October 5 (02:37 JST on October 6). The desktop was still reported as connected, attached, and authorized for tasks, but the send returned
CloudThreadNotFoundError/NOT_FOUND. The updated app version was not collected during this check.These observations suggest that communication has failed in both directions in these separate attempts. The reverse-direction raw error and whether the failures share a cause remain unconfirmed.
Dy3r commentedon Oct 6, 2026
I can also reproduce the dot-to-desktop launch failure on Windows. The latest attempt was on October 6, 2026 at approximately 01:21 UTC.
App version from my About dialog: 26.930.41038, “Powered by Codex & OWL,” released October 3, 2026. This is the desktop app version.
Windows: Windows 11 Pro, version 25H2, OS build 26200.8737. OS architecture: x64.
Subscription: ChatGPT Pro.
Ordinary local Work had previously worked while dot-launched tasks failed. I have not repeated that local Work comparison during this latest check.
Read-only diagnostics collected afterward:
The notification-sound errors and IPC warnings do not establish the cause of task startup failure. Executable lookup may be a diagnostic clue, but its connection to the failed dot launch is unverified.
Could maintainers correlate the request ID and advise which sanitized diagnostics would help identify whether the failure occurs during workspace setup, executor startup, or the WebSocket connection?
Dy3r commentedon Oct 7, 2026
Following up on my October 6 Windows report: dot-to-desktop task creation still failed on October 7, 2026.
At approximately 12:06 UTC, after I reported installing another desktop app update, the computer was still reported as connected, attached, and authorized for tasks. Creation returned:
AppServerBackendRequestError: Something went wrong
error_code: UNKNOWN
Request ID: wfr_01a116414cfc731c80f1e01e4bdfe93b
An earlier October 7 attempt at approximately 01:06 UTC returned the same error with request ID wfr_01a113e5211b77dcbaf435f47cf2f6bf.
At approximately 12:15 UTC, I confirmed that the About dialog reports desktop app version 26.1002.52244, released October 7, 2026. This confirmation came after the 12:06 failed attempt; the installed package and running executable were not independently inspected during that attempt. Local execution was not established.
OpenAI Status announced a Windows fix for the Work-thread creation incident at 11:53 UTC today:
https://status.openai.com/incidents/01M4ADHMMBK7K92NJFJ0DXRYJM
Could maintainers confirm whether desktop app version 26.1002.52244 includes that fix, whether it covers this dot-to-desktop failure, and correlate the latest request ID?
flyerwires commentedon Oct 7, 2026
We’re seeing a similar error, which persists after updating the Windows desktop app.
One important difference: our dot is attempting to start tasks in a saved cloud environment, rather than on a local macOS executor. The error matches, but we cannot confirm a shared underlying cause.
What we have verified:
Latest minimal reproduction:
Could you correlate this request ID and check whether saved-cloud delegation is affected by the same issue? If it belongs to a different component, please point us to the appropriate reporting channel.
Windows desktop app version: 26.1002.52244. The issue persists after updating.
HOLYtoma commentedon Oct 7, 2026
Follow-up to my earlier Windows report: I have updated the desktop app, but dot still cannot send messages to an existing local Codex task.
On October 7, 2026, two send attempts from dot to the same existing local task, at approximately 12:26 and 17:56 UTC, returned:
A screenshot provided afterward shows 26.1002.7124.0 in Microsoft Store's “Installed version” field for ChatGPT. This is the Store-displayed installed version, not a version collected from the app's About dialog. The running executable/package used during these tests was not independently verified.
There is some working communication: a notification from an existing local task reached dot at approximately 12:37 UTC, and manually pasted instructions reached the local task. These observations do not establish that dot-to-task messaging has recovered.
The October 7 status incident was marked resolved at 11:53 UTC and concerns creating new Work threads. Could maintainers confirm whether that fix also covers messaging to existing local tasks, or whether this needs a separate report? The 12:26 and 17:56 UTC checks above tested messaging only. A later new-task creation test is documented below.
Later check on October 7, at approximately 18:03 UTC: dot also attempted to create a new communication-only task on the Windows desktop. Immediately beforehand, the desktop was reported as connected, attached, and authorized for tasks. The creation request explicitly selected that desktop and asked only for an acknowledgement and reply, without file edits or command/application execution.
After approximately 15.6 seconds, creation returned:
No task or turn ID was returned. The immediate direct-child listing and the account's 10 newest tasks did not show a new task. This was not a full account-wide scan and does not establish whether a partial operation exists in the backend. The uncertain creation request was not retried. The request ID has been retained for follow-up.
Could maintainers check whether this creation failure is covered by the resolved incident, and whether the existing-task messaging failure needs separate investigation?
HOLYtoma commentedon Oct 10, 2026
Follow-up to my October 7 report: dot-to-desktop task creation still failed on Windows on October 10, 2026.
At approximately 09:44 UTC, the desktop was reported as connected, attached, and authorized for tasks. Task listings worked, but reading two existing local tasks returned
AppServerBackendRequestError: thread not found/UNKNOWN. Sending to those tasks was not tested in this check.At approximately 09:54 UTC, dot made one new-task creation attempt with that desktop explicitly selected. The task requested only an acknowledgement and reply, with no file edits or application execution. After approximately 8.8 seconds, creation returned:
No task or turn ID was returned. The immediate direct-child listing (first 10) and account-wide listing (10 newest tasks) showed no new task. This was not an exhaustive scan and does not establish whether a partial operation exists in the backend. The uncertain creation request was not retried.
A screenshot I provided afterward shows 26.1007.2314.0 in Microsoft Store's “Installed version” field for ChatGPT. This is the Store-displayed installed package version; the running process and in-app About version were not independently verified, and an app restart was not confirmed.
Could maintainers correlate the new request ID and advise whether the existing-task read failure needs separate investigation? A shared cause has not been established.
johnnychen1026-web commentedon Oct 11, 2026
I can reproduce a similar dot-to-macOS task-dispatch failure on October 11, 2026. A shared underlying cause with this issue has not been established.
The computer is reported as connected, attached, and authorized for tasks. Reading recorded task history and listing tasks work. Sending a communication-only instruction to existing tasks fails with AppServerBackendRequestError: Something went wrong, error_code UNKNOWN. This occurs across two different existing tasks. Creating a communication-only task fails with either explicit computer selection or the default attached-computer selection; reading the desktop project registry also fails.
Recent observations (UTC, client-side observation windows, not exact backend timestamps):
Control: directly interacting with a local desktop task succeeds. The user supplied a local result showing successful file access, and subsequently reported successful foreground execution. These results establish that the observed local route works, not that the dot-to-desktop route is healthy.
The desktop app/build and macOS version have not been independently collected. I have not established a timeout, configuration error, or a particular faulty component. Could maintainers correlate the request IDs, identify the failing dispatch/executor-setup stage, and advise a supported recovery step? If private diagnostics are needed, please indicate a secure submission route.
JakeRoyRandall commentedon Oct 12, 2026
Update — October 12, 2026 (UTC): dot still cannot start a task on my connected, attached, authorized Mac. The latest attempt failed before even running
pwd, withAppServerBackendRequestError/UNKNOWN. Restarting dot did not help. As a control, a separate local Codex agent ranpwdsuccessfully on the same Mac. Reading that agent’s thread also returned “unsupported placement format version 3.”\n\nLatest failure: October 12, 2026, 10:46 UTC. Request ID:53a3d5b9-114b-4990-8a3e-3c076b55e015.\n\nPlease investigate both task startup on the authorized connected Mac and compatibility when dot reads an existing local thread. This update adds a successful independent local-agent control and fresh request ID; it does not establish a shared root cause between task startup and thread placement compatibility.pvillavi commentedon Oct 15, 2026
Additional reproduction on macOS on October 15, 2026:
cloud_threads.createfails withAppServerBackendRequestError: Something went wronganderror_code: UNKNOWN, including with the Mac explicitly selected by environment ID.cloud_threads.send_messageto a cloud task, but messaging does not fail for every existing task.These observations do not establish a shared root cause across creation and messaging failures. Could maintainers share an update or supported diagnostic steps to narrow this down, including whether saved-cloud task creation should be tracked separately?
HOLYtoma commentedon Oct 18, 2026
Follow-up to my October 10 report: fresh read-only checks on October 18, 2026, approximately 14:48–14:51 UTC, still failed for existing local tasks on Windows.
AppServerBackendRequestError: thread not found: [redacted]. The other three returned the error below, with placement format versions 1, 2, and 3 respectively.error_code: UNKNOWN; no conversation content was retrieved from those local tasks.As a control, reading a cloud task in the same account returned substantive conversation messages during this check. Task IDs could be listed, but the listings did not provide placement metadata.
The desktop app version was not rechecked, and no new local-task creation attempt was made in this check. A shared cause with the earlier creation failures has not been established.
Does this placement-format error, including its occurrence on a recent local task while a cloud task remains readable, help narrow down the read failure? Is there a supported recovery step, or should this read failure be tracked separately?