Repository navigation
Windows Desktop cloud thread: history reads successfully but turn/start fails AbsolutePathBuf validation #49839
Description
This was generated by AI during triage.
What version of the Codex App are you using?
Windows MSIX package 26.928.2636.0 (verified installed and running package).
What subscription do you have?
ChatGPT subscription; tier withheld for privacy.
What platform is your computer?
Windows x64 with an existing cloud Work/Codex thread. Machine details are omitted.
What issue are you seeing?
The history of an existing cloud thread can be read, but submitting a follow-up from Windows Desktop repeatedly fails before a new model turn starts:
method=turn/start
error.code=-32602
invalid turn/start params: AbsolutePathBuf deserialized without a base path
failureReason=invalid_config
The cloud thread metadata represents its working directory as a Linux cloud-workspace prefix followed by a Windows-style path. The original value is withheld; a deliberately synthetic illustration of its shape is:
/tmp/<CLOUD_WORKSPACE>/workspace/C:\Users\<USER>\Documents\<WORKSPACE>
This mixed representation is an observation, not proof that cwd is the offending parameter. The failing Desktop request body was not captured, so the specific path field is unknown.
What steps can reproduce the bug?
- Open an existing cloud Work thread associated with Windows local execution/workspace information.
- Read its history; this succeeds in the affected case.
- Submit a follow-up through Windows Desktop.
- Observe the exact turn/start validation error above.
Only the affected existing thread was investigated. This report does not claim deterministic reproduction from a clean installation, nor that it is caused by switching to WSL.
What is the expected behavior?
The desktop and cloud service should correctly interpret path-bearing arguments for the selected execution environment. Invalid paths should identify the offending field so the user can recover without editing unknown configuration.
Additional information
Related reports #31983 and #48583 describe similar AbsolutePathBuf failures, but those involve SSH restart or Windows/WSL thread/resume. This report records an existing cloud thread failing specifically on turn/start with code -32602. No successful fix for the sending failure is claimed.
This is separate from an unsupported thread/unsubscribe error during unarchive and a dot message-service 503; no common root cause is claimed.
Privacy: all path components above are placeholders. No screenshots, raw logs, credentials, account identifiers, thread/room IDs, device names, actual local paths, project names, or conversation contents are included.
Activity
github-actions commentedon Oct 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jonathanmolea commentedon Oct 2, 2026
Additional reproduction observed on October 2, 2026.
Environment:
Observed behavior:
Error submitting message: invalid turn/start params: AbsolutePathBuf deserialized without a base path
This affected three fresh tasks in this investigation. Restarting the app, reopening a task, and creating new tasks did not resolve it.
The actual Windows task folders exist and commands work in them. Task metadata combines a Linux cloud-workspace prefix with a Windows absolute path. In this metadata, a Linux-style /tmp/.../workspace/ prefix is followed by a Windows drive-letter absolute path under the user's Documents folder.
The exact failing request field is unknown. The mixed metadata is an observation, not proof that cwd is the rejected parameter.
Workaround test:
Following the folder-change suggestion discussed in #49477, the Projectless task folder setting was temporarily moved from Documents to a short directory directly under the C: drive, outside Documents. A newly created task confirmed that its actual Windows working directory used the new location and could run commands there. Its human Desktop follow-up still failed with the same error. The original folder setting was restored afterward. This independently supports the updated #49477 conclusion that moving the folder is not a general fix.
Expected behavior: a task that can complete its initial turn on the connected Windows computer should accept valid follow-ups from Desktop. Please identify the rejected path field and preserve the history of affected tasks when providing a repair.
Only sanitized reproduction details are included; no real user-specific paths, account or task identifiers, business content, or raw logs are published.
xixifusi1213-gif commentedon Oct 2, 2026
Follow-up on October 2, 2026: same-thread recovery verified on Windows Desktop package 26.930.2377.0.
Before changing the affected chat's permission selection, multiple Desktop
turn/startrequests failed with-32602andAbsolutePathBuf deserialized without a base path. Adjacent configuration logs showedrequestPermissionProfile=null,requestSandboxPolicyType=workspaceWrite, and one writable root.A bounded differential parser probe used random nonexistent thread IDs, so no input was delivered to a real conversation:
unknown thread.sandboxPolicyproduced the identicalinvalid turn/start params: AbsolutePathBuf deserialized without a base patherror.The owner changed the original affected chat from Custom to Approve for me, consistent with the recovery reported in #49753. The owner reports normal sending and replies. Independently, the original chat's new user input and newly started turn were read successfully; the Desktop log recorded
turn/startwitherrorCode=null. Its request configuration no longer included an explicit sandbox policy or writable roots. The observed mixed cwd remained unchanged. No chat recreation, project move, reinstall, proxy change, or Full access selection was required.The parser probe establishes that a Windows-form writable root independently triggers this backend validation error. It is not a capture of the complete failing Desktop request, and the permission switch also changes the resolved approval reviewer; those limits should be retained when identifying the exact Desktop code path. This is a history-preserving recovery verified on this installation, not a permanent fix or proof that separate delegated-browser problems are resolved.
Please fix cross-platform handling of Custom permission-policy paths and add regressions for Windows-connected durable tasks with initial and subsequent human turns. User-specific paths, IDs, names, conversation contents, screenshots, raw logs, and credentials are omitted.
Paul9431 commentedon Oct 7, 2026
Additional affected Windows durable task, submitted at the user's explicit request on October 8, 2026. This adds a recovery-access problem: the original task is still returned by account-level metadata but is no longer visible in Desktop, preventing use of the reported per-task permission workaround.
Observed timeline and evidence
invalid turn/start params: AbsolutePathBuf deserialized without a base path/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/C:\Users\<user>\Documents\Codex\<date>\<task>This is Composer context, not the submitted request body. The rejected path field and parser endpoint remain unknown. The original Windows directory exists.
thread not loaded. This does not establish deletion or corruption of the durable task.Existing workaround and remaining blocker
We found the same-task Custom → Approve for me recovery documented in this issue and #49753, including a report where the mixed cwd remained unchanged. We have NOT verified that the affected task currently has that UI selection, nor applied or verified this workaround. The currently exposed task tools have no per-task permission-selection update operation, and the missing task UI prevents selecting it.
Separately, the parent dot returned
The invoking thread is not attached to an active Aeon/ UNKNOWN in user-reported minimal messaging tests at 17:02 and 17:08:57 UTC. Account/task reads succeeded. We found the official incident https://status.openai.com/incidents/01M4BK9J2M83R4SSC71D9FXW45 marked Resolved, but have not confirmed recovery of this parent or task; no common cause with the path error is claimed.Current local UI diagnostics also encounter the node_repl.exe runtime-validation sharing violation (Windows error 32) described in #51590. That is a separate observed blocker, not an established cause of the durable task's turn/start rejection.
Requested supported recovery
Please provide a supported way to reopen/re-associate the ORIGINAL durable task so its task-specific settings can be inspected and any appropriate workaround applied with rollback. Please also provide redacted path-field diagnostics for the rejected turn/start request (field name, path shape, parser endpoint/platform), and an independent check of the parent's active-Aeon association. Preserve the original task history; do not require database edits, default-folder changes, broad permission changes, or replacement tasks.
Only sanitized metadata and selected error text are included. Private task/request/environment IDs, real path components, account identifiers, project names, conversation content, raw logs and credentials are omitted.
Paul9431 commentedon Oct 8, 2026
Follow-up to my earlier report (#issuecomment-6044493428): communication and task visibility now work, but local execution remains blocked. These should be tracked separately from the earlier Aeon association error and AbsolutePathBuf turn/start parser error. PC-direct turn/start has not been revalidated.
A newly received task instruction reached the original task. Its local execution attempt returned, before the command process was created:
Fresh local sandbox logs for 2026-10-08 contain the following nearby sequence (UTC; private paths replaced):
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-hash>\bin\node_repl.exe. The failing operation isopen ACL target for root-only update; Windows returns error 32 (another process is using the file).setup refresh had errors.The profile read-attributes ACL warning in the same sequence explicitly says "continuing setup"; it is distinct from the fatal runtime-validation error. This fresh sequence resembles #51590.
Correlation limitation: the sandbox records do not expose the task/turn/exec request ID or helper PID. The runtime error is directly evidenced in the same time window, but the exact exec-to-helper linkage and the identity of the process holding the file are still unknown.
An existing diagnostic node_repl kernel remains usable. A previous isolated workspace CLI probe with a temporary unelevated override succeeded; that did not validate the original task. A temporary shared configuration change was subsequently fully reverted to elevated, with config readback and a matching backup hash. No additional configuration, ACL, process, or runtime changes were made during this fresh diagnostic pass.
Could maintainers provide:
No private task IDs, usernames, workspace paths, file contents, credentials, or full logs are included here.