Repository navigation
Windows desktop: dot fails to start local tasks with DesktopTaskWorkspaceUnavailableError #49423
Description
Environment
- Windows 10 Pro 22H2, build 19045.6466, x64.
- Desktop application version 26.928.20755, build 12246, prod channel.
- Windows Store package version 26.928.1915.0.
- Bundled local app-server reports 0.159.0.
- In-app update check returns up_to_date. The official prod x64 MSIX HTTP metadata reports the same installed package version.
Reproduction
- Connect the Windows computer to a dot and grant access. Its computer card shows Connected.
- Ask the dot to start a read-only local Codex task. The dot invokes cloud_threads.create.
- The call fails with DesktopTaskWorkspaceUnavailableError before a task starts.
- Disconnect and reconnect once; the connection succeeds. Repeat the request: same failure.
- Specify an existing absolute directory which is already registered as a local Git project in the desktop application. The call again fails before a task starts.
Expected behavior
The dot should create a local task on its connected, authorized computer, or return an actionable error explaining which requirement is missing.
Observed diagnostics
- Ordinary local Codex chats can run shell commands.
- The registered project directory and default Documents/Codex parent exist as ordinary directories.
- The current local chat's workspace passes a temporary file write/read/delete test. This does not independently establish the dot executor's permissions.
- Available disk space is approximately 13 GB on the system drive and 51 GB on the project drive.
- Desktop logs show the native app-tools pipe listening and the Local Work executor connecting to rendezvous.
- The computer reconnect operation logged success just before the failed task request.
- No direct DesktopTaskWorkspaceUnavailableError or dynamic_app_tools_request_failed entry was found in the desktop logs around the failure. Absence does not prove the request was never received.
- A separate, once-only attempt by the dot to send a read-only diagnostic to an existing local Codex chat failed with NOT_FOUND / CloudThreadNotFoundError. That may reflect the dot's access scope and is not asserted to share the same cause.
Version-related question
The Enterprise local-access guide states that dots require desktop app 26.929 or later, while the installed prod channel and the official public prod MSIX currently provide 26.928. Personal dot documentation does not list the same version gate. Is a newer client or server capability needed for this account, and how should the product expose that requirement?
References:
- https://learn.chatgpt.com/docs/enterprise/cloud-local-access
- https://learn.chatgpt.com/docs/dots/tasks-and-memory
- https://learn.chatgpt.com/docs/enterprise/windows-deployment
Please trace the workspace preparation request to the selected local executor and taskWorkspace/prepare handler, including the executor readiness and environment association. We have not modified packaged code, runtime paths, permissions, or account-wide executor registration as a workaround.
Account identifiers, thread IDs, project names/paths, credentials, screenshots, and unrelated business logs have intentionally been omitted from this public report. Full private request details can be provided through the in-app feedback channel if requested.
Activity
masterAIGC commentedon Sep 30, 2026
Update from a further retry on September 30, 2026:
DesktopTaskWorkspaceUnavailableError: The desktop could not prepare a task workspace. Update or reconnect it before creating the task.
Multiple attempts have failed with this error, including an attempt specifying an existing working directory. No new task appeared after the latest retry, and no local execution or changes occurred.
This continues to prevent dot from starting a local task despite the connected status. Which additional diagnostics should we collect, and is a specific desktop version required for this workflow?
DomVidja commentedon Sep 30, 2026
I'm seeing the same DesktopTaskWorkspaceUnavailableError on macOS when dot starts a local task. The Mac shows connected and authorized, but workspace preparation fails before a task starts:
The desktop could not prepare a task workspace. Update or reconnect it before creating the task.
The app is updated, and reconnecting and retrying produced the same error.
Update, October 1, 2026: A read-only local task now starts successfully after reconnecting; I haven't isolated what resolved it.
Current configuration: MacBook Pro, Apple M5 Pro, 64 GB memory; macOS 27.2 (26B5091g); ChatGPT desktop 26.928.40906 (build 12694). These were verified after recovery, not at the original September 30 failure.
up-and-down-0618 commentedon Oct 2, 2026
https://github.com/up-and-down-0618/dot-local-workspace-fix
thematthewdunlop-cpu commentedon Oct 2, 2026
Small change worth checking that fixed it for me. My projectless task folder in settings - general was pointing to a junction folder. I had done a migration of where the original folder was when first installed. The fix was to point Codex’s active folder settings directly at the physical new folders, while keeping the C: junctions for existing links.
After migrating my workspaces, normal file access through the C: junctions still worked. Repointing projectless task folder seemed to fix Dot and Spaces uses for me.
redshadow2085 commentedon Oct 2, 2026
I'm seeing the same failure on Windows after updating the desktop app to 26.930.21537 and fully rebooting the PC.
cloud_threads.createwith the selected computer fails before a task starts.DesktopTaskWorkspaceUnavailableError: The desktop could not prepare a task workspace. Update or reconnect it before creating the task.I previously saw the same error on 26.928 builds. It still occurs on 26.930.21537, so being below the 26.929 minimum mentioned in the Enterprise local-access documentation doesn't explain this latest reproduction.
I haven't verified whether the task folder involves a junction, as mentioned in another comment. No root cause or local diagnostic logs are available from this test.
redshadow2085 commentedon Oct 2, 2026
Update: changing the Projectless task folder resolved my read-only handoff test on Windows, desktop app 26.930.21537.
In Settings > General > Projectless task folder, I selected a new empty folder directly on my secondary drive. Pasting the path into the folder picker produced “Unable to change the projectless task folder”; browsing to the folder and selecting it succeeded.
After saving that setting, dot successfully started a new local task, and the task ran a read-only PowerShell command with exit code 0. This was verified on October 2, 2026, at approximately 14:12 UTC.
I had previously moved a workspace folder from the system drive to the secondary drive and kept a redirect for old paths. I have not verified whether the old Projectless task folder itself was a junction, so I can't confirm the exact root cause. Updating and rebooting alone had not resolved it. The existing redirect was left in place.
Thanks for the folder-path lead above.
Rockdoc610 commentedon Oct 3, 2026
Guys - Thanks so much! Changing the projectless task folder seems to have worked for me as well.
z1197659035-alt commentedon Oct 15, 2026
Additional Windows diagnostics — 2026-10-15, task creation still fails with a physical projectless workspace root
Adding a sanitized related report to this open issue. The exact
DesktopTaskWorkspaceUnavailableErrorexception has not been captured in this occurrence, so a shared root cause is not established. The visible symptom also resembles #50649.Observed failure
At approximately 2026-10-15 18:43 UTC+08:00 (10:43 UTC), a dot was asked to start a local Codex task on its already-connected Windows computer. The dot reported an internal/service error, said no new task was visible in its listing, and reported the same failure after one retry. The user-visible conversation provides no expandable raw tool-error details.
The exact dot-side tool name, error code, request/trace ID, original creation parameters and any partially-created task ID are therefore unknown. We have not assumed
-32603, that no task exists, or that a retry is safe. No further creation was attempted during diagnosis.Verified environment
26.1007.9446.0.26.1007.71326, build20398, prod.0.162.0-alpha.17.2.up_to_dateon October 15.lstatreports a directory, not a symlink/junction. The existing directory setting was left unchanged.What the local evidence establishes, and what it does not
list_threads,list_projectsand an existing thread's read-onlyread_threadreturned successfully. This is a local-context comparison, not a dot-origin acceptance test.taskWorkspace/prepare,thread/start,dynamic_app_tools_request_failedor native-pipe peer-rejection entry. Missing log entries do not prove the request never arrived or that no partial task record exists.codex doctorreports a stored sandbox provisioning failure, but thesetup_error.jsonmodification time is 2026-10-08 18:39:38 UTC. It has not been linked to this October 15 creation failure. “No desktop app-server handshake was recorded” is also not treated as readiness passing.The physical-directory workaround reported earlier in this issue does not directly match the current root. We have also not applied third-party patches or used “Restart dot” as a presumed fix: the related report in #50649 describes initial creation still failing after a restart.
Request for maintainers
Could you advise on a supported way to correlate the original dot creation attempts with the selected desktop's workspace-preparation request, including whether a partial task record was created? In particular, is there a known client/server fix, a supported read-only diagnostic export, or a targeted recovery that preserves the existing computer grant and running tasks?
Acceptance must be through the original dot path: reconcile the original attempt first, then verify the unique original task identity, intended local workspace, an actual read-only local-tool result, and readback from the dot. A successful task created independently by a local Codex caller would not close this report.
No reconnect, computer-access revocation, TUN/network change, app/executor/browser restart, task-state edit, business action or further task creation was performed. Existing records and unknown outcomes are preserved.
No account/computer identifiers, task IDs, local user paths, credentials, screenshots, business data or raw logs are included.
Report marker:
DOT-LOCAL-CREATE-20261015-AFollow-up: original-task execution error and automatic executor recovery
Further read-only inspection on October 15 found an exact failure in an existing dot-origin local-execution task, separate from the unexposed creation request above:
The task's original turn contains 47 successful command executions before its final two handshake failures, and no successful command after either failure. This confirms a real original-task execution failure; it does not identify the raw creation response or prove a shared root cause.
The desktop later captured an executor incident with:
At 11:39:53 UTC the executor exited with code 1. The desktop's existing supervisor automatically started attempt 4, which connected to rendezvous at 11:39:56 UTC. No diagnostic restart, sign-in, access-grant change or network change was performed. Transport recovery is not original-task acceptance.
The installed binary and matching public CLI tag already contain the handshake-cooldown behavior from #46031; the incident log also records that cooldown. Reapplying that old fix is therefore not a demonstrated remedy. The underlying authentication failure and original request admission still need a supported trace/recovery path.
One additional user-reported access symptom is being tracked separately: an existing local task is readable through the supported native host-local reader, while the dot reports an unsupported task-format version. That resembles #50704 / #49729. The original dot error object and exact format number are unavailable, and no shared cause with the creation or Noise failures is claimed.
No new task, helper, follow-up message, ID rewrite, database edit, permission change, or request replay was used. Private task/account/device identifiers, paths, business contents and raw logs are excluded.
Diagnostic supplement marker: DOT-LOCAL-CREATE-20261015-B