Repository navigation
Windows desktop: durable chat turn/start and thread/fork fail with AbsolutePathBuf deserialized without a base path #50428
Description
Windows Codex Desktop can read an existing durable/cloud chat bound to a Windows execution environment, but direct plain-text submissions and a same-directory fork fail before execution.
Environment
- Observed on 2026-10-02.
- Desktop versions reproduced: 26.928.31416 and 26.930.21537.
- Windows package observed: 26.930.2377.0.
- Durable/cloud chat with a connected native Windows execution environment.
- The local checkout is an existing linked Git worktree. WSL was not required for this reproduction.
Errors
invalid turn/start params: AbsolutePathBuf deserialized without a base path
invalid thread/fork params: AbsolutePathBuf deserialized without a base path
For turn/start, the recorded JSON-RPC code was -32602 and failureReason was invalid_config.
Reproduction
- Open the existing environment-bound durable chat in the Windows desktop app.
- Submit plain text without attachments.
- Observe the turn/start error before a new turn is created.
- An authorized diagnostic-only send_message_to_thread call from the desktop reproduces the same error.
- Attempt to fork the affected chat in the same directory; thread/fork fails with the same AbsolutePathBuf message.
Observed evidence
- read_thread succeeds and the existing chat history remains readable.
- The failed composer item had no file, image, or pasted-text attachments.
- The same failure was present in logs before and after the desktop update between the two versions above.
- A diagnostic-only desktop submission was rejected at 2026-10-02 18:51:11 UTC.
- Executor diagnostics and later direct filesystem validation showed that the Windows cwd and checkout were usable.
- A later cloud-to-cloud diagnostic message to the source chat was accepted. The evidence therefore does not imply that all submission routes fail.
- The exact outbound request JSON was not captured.
Redacted path and request context
Durable chat cwd:
/tmp/<cloud-agent>/app_servers/thread_service/workspace/C:\Users\<user>\Documents\Codex\<date>\task\<repo>
Windows executor cwd:
C:\Users\<user>\Documents\Codex\<date>\task\<repo>
Environment runtimeWorkspaceRoots:
C:\Users\<user>\Documents\Codex\<date>\task-2
The cached policy was workspaceWrite with writableRoots ["/tmp"], networkAccess false, excludeTmpdirEnvVar true, and excludeSlashTmp false. The queued desktop submission had executionHostId "durable", shouldSendPermissionOverrides false, usePermissionSelection false, and permissionSelection null. The desktop log nevertheless recorded a workspaceWrite override with one writable root.
Working hypothesis, not a confirmed root cause
The installed request-builder code appears to select environment-native Windows cwd/workspace roots and merge roots into the top-level workspaceWrite sandbox policy. A Windows drive path may then reach a POSIX AbsolutePathBuf parser. The logged root counts are consistent with this interpretation, but do not identify the exact offending field.
The inspected installed asset was webview/assets/app-shared-ac32c0d1413b.js; the relevant minified function names were ton, qB, and htn. Please compare outgoing turn/start and thread/fork cwd/sandboxPolicy.writableRoots with environments[].runtimeWorkspaceRoots and host-native path expectations. Preserve the existing approval and review controls when fixing path serialization.
Expected behavior
A readable durable chat with a usable Windows execution environment should accept ordinary text and support the applicable fork flow. Environment-native paths should be serialized at the correct boundary; invalid paths should produce an actionable field-specific error.
Recovery and impact
A fresh local continuation could inspect the same original worktree. No source repair was necessary:
- All 63 reviewed uncommitted files matched the saved SHA-256 manifest: 9 modified tracked files and 54 untracked files, no extra or missing pending paths, and an empty index.
- Archive rereads verified all 63 reviewed file entries and 23 checkpoint/evidence entries.
- A Git history bundle preserving current HEAD and the intended incoming commit passed git bundle verify.
- The intended incoming commit existed but remained unmerged; its 19 paths did not overlap the pending files.
- HEAD, status, index hash, and all reviewed file hashes stayed stable during the recovery verification.
- A previously completed full npm.cmd run verify result had exit code zero, with its log hash verified. It covers the pre-integration tree only.
No merge, publication, approval-settings change, or persisted app-state patch was used as a recovery workaround.
Recovery coordination follow-up
Dot's cloud_threads.read call could not read the new local continuation and returned an unsupported placement region error, reported as region6. A self-contained inline handoff was needed to communicate the recovery proof. This is an additional symptom; it is not proven to share the path-serialization root cause.
Related reports, not confirmed duplicates
- Windows Desktop thread/read succeeds but thread/resume rejects WSL runtimeWorkspaceRoots; restart restores chat #48583 — readable Windows chat fails to resume with runtimeWorkspaceRoots/path-format concerns.
- Codex app: Scheduled automation run fails with
AbsolutePathBuf deserialized without a base pathand remains stuckIN_PROGRESS#27567 — turn/start fails with an AbsolutePathBuf error in a scheduled WSL run. - Windows dot imagegen with readable reference images immediately fails: AbsolutePathBuf deserialized without a base path #50170 — Windows dot reference-image path failure.
This report omits usernames, machine names, repository names, source commit hashes, chat IDs, credentials, screenshots, source code, raw session transcripts, and raw logs. The observed failures have not been retried merely to file this report.
Activity
github-actions commentedon Oct 2, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
mbeanii commentedon Oct 3, 2026
I'm also seeing this exact error on October 3, 2026, when submitting ordinary text to existing Windows-executor tasks from ChatGPT web on Windows:
Error submitting messageinvalid turn/start params: AbsolutePathBuf deserialized without a base pathLast observed local versions: Windows package 26.930.2377.0 and Codex CLI 0.159.0-alpha.12.1.
It has recurred in more than one task, including a newer continuation task that previously accepted a direct message. Task history is still readable, and assistant-to-task messages continue to be accepted, while my direct UI submissions fail. The failed submissions here were plain-text authorizations for already requested work, with no file attachments. I have not independently reproduced thread/fork.
The failure prevents providing direct approval in the affected task. Creating a fresh continuation is our current recovery approach, but it has not established a permanent fix. We are testing a fresh task with an explicitly supplied, existing native absolute working directory; that is an experiment, not evidence that cwd is the offending field.
No approval/security settings, credentials, or persisted app-state files were altered to work around this. No raw logs, private paths, task IDs, or project data are included in this report. Is there a known fixed desktop/service version, or a supported way to repair the path metadata of an existing affected task?
mbeanii commentedon Oct 3, 2026
Follow-up to my report: the fresh-task workaround also failed. At about 19:02 UTC on October 3, a newly created Windows-executor task with an explicitly supplied, verified existing native absolute working directory accepted the assistant's initial request and could read its handover, but the user's direct web submission returned the same
invalid turn/start params: AbsolutePathBuf deserialized without a base patherror. This rules out simply supplying an explicit native absolute cwd as a sufficient workaround in this setup. The offending request field remains unknown. No further app-state edits or security changes attempted.quiet-cedar-482 commentedon Oct 3, 2026
I’m experiencing a similar problem on Windows with a cloud chat created by Dot. I often cannot send even a simple text follow-up through the Codex desktop app, while Dot has been able to communicate with that same chat.
I observed the failures on October 2, 2026, from 4 p.m. Pacific time (PDT) onward. They continue today, October 3, with Codex app version 26.930.31730, build 12947.
Dot has also returned
unsupported placement format version 2for this same cloud chat. I haven’t confirmed an AbsolutePathBuf error on the desktop side or whether these symptoms share a cause.This blocks me from reliably reviewing and continuing the work directly. I’m happy to try a simple diagnostic or provide specific additional details.
OliverFrux commentedon Oct 3, 2026
I’m seeing this too on Windows. In my case, it reproduces every time I try to send a message in a task created by my Dot.
The task and its history are visible, but submitting a message fails with:
“Error submitting message: invalid turn/start params: AbsolutePathBuf deserialized without a base path.”
This also prevents me from giving the agent approval directly in that task. Dot-created tasks are the consistent trigger I’ve observed; I haven’t isolated the underlying cause.
mattalberta commentedon Oct 3, 2026
This is a cloud-started vs windows executable issue. Recover the checkout at the current checkpoint and start a fresh local task with a verified and recovered worktree. Can't confirm the reproduction of the failure.
quiet-cedar-482 commentedon Oct 3, 2026
Follow-up, October 3, 2026: I asked Dot to create a fresh test chat on my Windows computer. The new chat successfully ran its initial checks and reported verifying its working directory and Windows OS.
When I tried sending a short message directly through the Codex desktop app, submission failed with:
invalid turn/start params: AbsolutePathBuf deserialized without a base pathThe app identifies this chat as “Cloud” and “Runs on your computer when available.” Ordinary local chats I create myself work normally. This confirms the exact desktop error and shows the failure also affects a newly created Dot chat.
MLStoltzenburg commentedon Oct 4, 2026
Adding another reproduction of this turn/start failure, observed on October 4, 2026 UTC (October 3 BRT).
Environment:
The submission route makes a difference. Tasks created by dot start successfully and accept follow-up messages through dot's task interface. A same-turn steering test was accepted, with an acknowledgement approximately 40 seconds later. However, sending a plain-text reply directly in the Windows desktop UI fails with:
invalid turn/start params: AbsolutePathBuf deserialized without a base pathThis persisted across multiple fresh tasks, including creation with an explicitly specified existing absolute Windows working directory using forward slashes. Local inspection confirmed that the directory existed and was usable.
Reading the global configuration found no sandbox, profile, or workspace-root overrides, and the relevant Windows project entry was valid. The UI displayed Custom permissions. No security preset or approval-setting changes were made during these checks.
Inspection of the 0.160.0 protocol types indicates that turn/start.cwd uses PathBuf, while runtimeWorkspaceRoots and sandboxPolicy.writableRoots use AbsolutePathBuf. This supports investigating root-path serialization across platform boundaries, but we have not captured the exact failing JSON field and cannot establish the root cause. The local CLI version also does not establish the version of the durable/cloud receiver.
Could maintainers identify which request field fails deserialization, which OS/runtime receives the request, and a supported way to capture a suitably redacted diagnostic request? The same task remaining reachable through dot's submission route may help isolate the failing boundary.
No private paths, conversation IDs, project data, screenshots, or credentials are included.
shaun-parkside-dev commentedon Oct 4, 2026
Adding my experience and a workaround that is working for me.
Environment:
This workflow worked for several days before direct messages to dot-created tasks through the desktop app began failing with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
The parent dot can still send messages to the affected tasks. One direct test message recently succeeded, but I haven’t found a reliable recovery.
I’ve tried updating and reinstalling the app, archiving chats, resetting the workspace, creating fresh dot tasks, switching between Windows and WSL agent environments, toggling permission settings, fully closing the app through Task Manager, and rebooting.
After selecting WSL and restarting, fresh dot-created tasks still reported native Windows PowerShell 7.6.5. I don’t know whether that is related to the message-submission error.
Codex CLI running directly inside WSL is now working well, and I’ve been able to continue work on the same repository using a handoff. That’s a usable workaround, but I’d like to get the desktop dot workflow working again.
Is there a known fix or upcoming release addressing this, or a specific diagnostic that would help identify the failing request field?
marekfindlay commentedon Oct 4, 2026
I’m seeing this on Windows when trying to message tasks created by my dot:
Error submitting message
invalid turn/start params: AbsolutePathBuf deserialized without a base path
It affects multiple tasks and prevents me from giving the agents instructions directly. My dot can still message some of those tasks. Is there a supported workaround or specific diagnostic information that would help?
mattalberta commentedon Oct 4, 2026
6 remaining items
gugatarga commentedon Oct 5, 2026
Follow-up to my earlier reproduction: in the same affected Windows desktop task/build, typing
/approvein the composer displays “No commands”. Submitting/approveas ordinary text then fails withinvalid turn/start params: AbsolutePathBuf deserialized without a base path. This observation is limited to the affected task/build; it does not establish that/approveis unavailable generally. No screenshots or private task details are included.tomhda commentedon Oct 5, 2026
Another reproduction, with what the desktop log records about the request.
27 rejected
turn/startrequests for the same chat between 2026-10-05T15:35:58Z and 15:40:49Z. Every retry failed the same way. Example:The request says
useAppServerPermissionDefault=true, yet it still carries aworkspaceWritesandbox policy with one writable root. For a chat bound to a Windows folder, that root is presumably a Windows path, which the cloud app-server cannot parse as an absolute path. This matches #50332 and #50428.The messages were plain text with no attachments.
Right after these rejections the server closed the durable WebSocket, and every reconnect has returned 403 since (details in #50412).
dean1012 commentedon Oct 6, 2026
Additional user-reported reproduction on Windows, desktop version
26.930.61225.The failing direction is an existing user-created local chat sending to an existing dot-created chat:
There is an important distinction in the working reverse workflow: the dot-created chat sends a request to the local chat, polls/reads the local chat's output in its own conversation, and relays that output to dot. This retrieves the response but does not demonstrate that the local chat can actively send a reply to the dot-created chat.
Expected: the local chat can send the authorized message to the existing, selected dot-created chat without this path-deserialization error.
These observations describe this workflow, not every local/dot-created chat configuration. The cause is unconfirmed, and no additional messaging tests were run to file this comment.
StutteringJohnMelendez commentedon Oct 7, 2026
Please provide a maintainer status update and supported recovery for the Windows
turn/start/AbsolutePathBuffailure already documented in this issue.The public report records a cached
workspaceWritepolicy withwritableRoots: ["/tmp"]and mixed cloud/Windows path context, while existing history remains readable. The public parser comparison at #49477 (comment) is also relevant: its synthetic checks distinguish cwd-only parsing from permission/workspace-root parsing and explicitly do not establish the live rejected field.Please identify the failing request field and the platform boundary where it should be validated. Is there a shipped fix and a supported repair for already-affected conversations that preserves existing work, history, and permission controls?
Please distinguish successful decoding in an isolated test, a temporary permission-picker workaround, and verified direct replies in the original conversation after resume. If recovery is available, please provide the applicable release/service rollout and verification steps.
This request uses only the evidence already published in this issue and the linked comment. It adds no new user-specific reproduction, environment, timestamps, task identifiers, private paths, or logs.
peanuttbuttersupport-oss commentedon Oct 8, 2026
I'm seeing the same error on Windows 11, with observations from October 7–8, 2026 UTC:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
The installed Windows package is OpenAI.Codex 26.1002.7124.0. The version of the running app process was not independently verified.
What worked and failed:
There are additional routing observations that may be separate problems:
The exact cause is unconfirmed, and I haven't established whether the placement and tool-availability symptoms share the same cause as the AbsolutePathBuf failure. The working routes also mean this is not a failure of every messaging route.
Could maintainers provide a supported fix or recovery for the affected existing conversation that preserves its history and permission scope? A relevant fixed client/service version, or guidance on identifying the rejected request field safely, would help.
No additional local messaging tests or settings changes were made just to post this report. Private paths, task identifiers, project details, screenshots, and raw logs are omitted.
ve6btc commentedon Oct 8, 2026
Adding a current Windows direct-submission report, with a qualification about the latest error wording.
At about 03:59 UTC on October 8, 2026, my attempts to give approval directly in dot-created tasks failed. The wording I reported was “invalid task turn”. Earlier troubleshooting associated this workflow with the AbsolutePathBuf error in this issue, but I don't have a fresh screenshot or full exact error capture from these latest attempts, so I can't confirm that exact signature this time.
The approvals weren't recorded in the tasks. Their history remains readable, and messages from my parent dot to the tasks still succeed. After the latest update attempt, About shows “Powered by Codex & OWL”, version 26.1002.52244, released October 7, 2026.
A separate local shell setup failure is being reported in #51778. I haven't established that it shares a cause with these direct-submission failures.
The existing permission scope is unchanged. Is there a supported recovery for direct replies and approvals in these existing tasks that preserves their history and permission scope? A fixed client/service version or guidance on the minimal redacted diagnostic needed would help.
RAMBULLS commentedon Oct 9, 2026
Still reproducible on Windows desktop 26.1002.52244 build 13536 prod (Store package 26.1002.7124.0), October 8, 2026. A bounded, authorized
send_message_to_threadattempt from an existing local task to an existing durable/cloud task failed with:invalid turn/start params: AbsolutePathBuf deserialized without a base pathThe receiver remains readable through
read_thread; the rejected send produced no new receiver turn or request ID. Its reported cwd has the mixed form/tmp/<cloud-agent>/app_servers/thread_service/workspace/D:\<existing-project-path>. The exact outbound request payload was not captured, so the offending field and desktop-versus-service responsibility remain unconfirmed. A separate local task created through the supported native Project API admits work and runs harmless commands in its verified existing Project.Earlier connected-task admission attempts also returned
AppServerBackendRequestError; those request IDs were supplied privately to official support. This comment does not establish that they share the AbsolutePathBuf cause. The separate Windows runtime ACL error 32 is tracked at #51882 / #51822 and is not treated as this admission fault.Please confirm the supported recovery or fixed desktop/service release for this route. No persisted app-state edits, path rewriting, permission bypass, duplicate replacement task or repeated restart was used. Credentials, private task IDs, request IDs, personal paths and raw logs are omitted.
IFsub commentedon Oct 9, 2026
Windows Desktop: existing durable chat is readable but both manual text
submission and native send_message_to_thread fail before a new turn.
Desktop: 26.1002.52244, build 13536 prod
Windows package: OpenAI.Codex 26.1002.7124.0
Bundled local CLI: 0.162.0-alpha.2
Target host: durable
Date: 2026-10-09, Asia/Shanghai
Exact error:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Native dispatch failed at about 23:09; no new turn ID was returned.
User separately reproduced the same error by manual submission in the
same chat. Exact manual submission time/request ID is unavailable.
Official readbacks succeed and remain on the previous completed turn.
No approval rejection was returned. No retry, permission relaxation,
task/database edit or app patch was performed.
Please inspect the existing failed turn/start request's path-valued fields
(including environment paths and any top-level runtime/sandbox roots),
the receiving platform and deserialization base context. Local retained
logs do not contain the full failed request; the precise offending field
is unknown. Please provide a field-specific diagnosis and a supported fix
that preserves current approval controls and conversation history.
Divine-Shadow commentedon Oct 9, 2026
On Windows Codex Desktop 26.1002.7124.0, official task coordination encountered three separate errors: Transport closed during read_thread/wait_threads; Task host changed during passive read; and AbsolutePathBuf deserialized without a base path when messaging an existing durable task. Some official reads recovered on a later turn, but recurrence remains unresolved. In one case the remote task completed CI while terminal observation failed. No shared root cause is established. Please provide a supported recovery/diagnostic route that preserves history and does not require replaying completed operations.
etrevio commentedon Oct 9, 2026
I am also seeing this issue when messaging existing tasks created by a dot.
Environment:
From a local Codex chat on Windows, send_message_to_thread fails when attempting to continue an existing task created by a dot and hosted on durable. Even a minimal request asking the task to reply only “OK” returns:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Steps to reproduce:
Both variants fail with the same error, and no new turn starts through the send operation. read_thread successfully reads the same tasks and their previous responses. The behavior was reproduced with two existing tasks.
Expected behavior: The message should reach the existing task and start or continue its work, preserving its context.
Diagnostic clue: The task summaries expose a cwd combining a Linux-style temporary workspace prefix with a Windows absolute path. Redacted example:
/tmp/codex-cloud-agent-<REDACTED>/workspace/C:\Users\<USER>\Documents\Codex\<TASK_DIRECTORY>The tasks execute commands on Windows. This suggests checking environment selection and path serialization when building turn/start, but the precise rejected field and root cause remain unconfirmed.
No messaging patch has been installed. Please provide a supported correction that works with existing tasks without requiring them to be recreated or losing their context.
This is a separate messaging issue from the Windows sandbox-helper/ACL failure.
Feedback reference: 01a11466-6997-7221-887a-f8b663e77021
taopeng9192 commentedon Oct 11, 2026
Additional offline reproduction of the request-builder boundary in Windows Codex Desktop 26.1007.21434 (build 13901, prod; Windows package 26.1007.2314.0). The configured updater reports up to date.
The installed asset
webview/assets/app-shared-737655e1fb23.jscontains a reproducible path mix-up under synthetic inputs. InTun, a Windows bound environment selects the native cwd.FVmerges its runtime roots into the top-level workspaceWrite policy;Fanthen filters policy roots using that native cwd's path style. With an existing policy root/tmpand environment rootD:\fixture\work, the outgoing top-level writableRoots becomes["D:\\fixture\\work"], dropping/tmp. Top-level cwd and runtimeWorkspaceRoots are null, while environments[0] correctly retains the Windows cwd and roots.Executing the exact extracted functions offline reproduced non-POSIX top-level roots with both useAppServerPermissionDefault=false and true, an explicit POSIX sandbox-root override, and a Windows UNC environment. An isolated candidate retaining the selected top-level policy for the Windows-environment/POSIX-session boundary passed all four cases, while local Windows and remote Linux outputs were unchanged. Approval policy, reviewer, permission-profile ID, native environment roots, networkAccess and temporary-directory restrictions were checked. No installed files, app state, permissions or running tasks were changed.
Please inspect the FV/Fan policy construction boundary and fix it in the client source while preserving the bound executor's effective permission scope. This is an offline JavaScript reproduction with synthetic data and platform path checks, not a cloud Rust deserialization test or a captured production request. The precise rejected field in the real failed request remains unconfirmed. The candidate is not deployed and does not claim to fix separate WebSocket disconnects.
Asset SHA256: a1daa891e89a395b8db399ff6eaa365f12a86880c3d8cf891caf4ccbcb9eebf5.
Akkie-24 commentedon Oct 13, 2026
Additional Windows reproduction and a scoped client-side candidate, observed 13–14 October 2026.
The installed package is 26.1007.2314.0; its app package.json reports 26.1007.21434, build 13901. The target is an existing dot-created task with a native Windows executor. Its first turn completed and its history remains readable.
One official Desktop send with explicit hostId=durable failed before a new turn with -32602 and "invalid turn/start params: AbsolutePathBuf deserialized without a base path". The target stayed idle on its original completed turn. The corresponding connection log identifies durable WebSocket transport and reported server version 0.1.0; this is distinct from the separately installed native CLI version.
The request-resolution log shows workspaceWrite, one sandbox writable root, zero top-level runtime workspace roots, no permission-profile ID, and useAppServerPermissionDefault=false. The actual root string and complete outgoing payload were not captured. A separate one-time parent-agent send timed out without an acceptance ID; no new turn was observed afterward. We have not treated that timeout as the same parser failure or repeated either send.
We reproduced the same-version builder boundary offline using exact extracted functions from both the Node and webview assets. The original final filter uses the native environment cwd's path style for the top-level sandbox roots. With a POSIX control session and a bound Windows environment, this drops existing POSIX roots and keeps Windows roots at the top level.
The candidate changes only the final filter's cwd argument, leaving the existing policy merge and projection in place. For durable Windows-bound/POSIX-control cases with a nonempty selected POSIX policy and POSIX-only additional control roots, it filters against the original control-session cwd. Outside those confirmed conditions it retains the original behavior. Native environment paths stay inside the environment payload; permission flags and other request fields are unchanged.
Both exact complete builder bodies were executed with fixed manager/filesystem I/O. Nine cases passed: the four affected path cases; local Windows and remote Linux baselines; legitimate additional POSIX control roots; unchanged fallback for native additional roots; and the existing projectless/empty-root conversion. Request, prepared params, current permissions and workspaceCommit were compared. Approval policy, reviewer, profile ID, environment fields, network and temporary-directory flags remained unchanged relative to the original builder. Candidate function syntax checks also passed.
This was an offline JavaScript builder experiment. Config/model service I/O was excluded through explicit inputs, no durable Rust request was submitted with the candidate, and the live task is not claimed restored.
The installed executable has a valid vendor signature and an embedded ASAR header digest matching the current archive. Embedded ASAR integrity validation is enabled. We have not modified the installed archive, executable, signatures, fuses, application permissions, database or existing task state. The configured updater could not resolve the current Windows package family; the standard Store inventory showed no upgrade candidate, while its catalog version was Unknown. Neither result establishes that a corrected eligible build is unavailable.
Please fix this boundary in the source owner’s build and provide a signed release or a supported recovery for already-affected tasks that retains their history and permission scope. Please also capture sanitized path-style diagnostics for the rejected field, rather than requiring raw user paths or logs.
moruku36 commentedon Oct 15, 2026
Additional reproduction on Windows, observed on 15 October 2026 UTC.
Submitting a reply directly in an existing ChatGPT Work task shows:
Error submitting message
invalid turn/start params: AbsolutePathBuf deserialized without a base path
The failure occurs when submitting the message. The exact app version and rejected request field have not yet been verified, so I cannot identify the underlying cause or confirm a version regression.
Is there a supported fix or recovery for existing affected tasks that preserves their history and permission scope?
etrevio commentedon Oct 15, 2026
Feedback ID: 01a11466-6997-7221-887a-f8b663e77021
Follow-up to my earlier report: additional Windows reproduction on 15 October 2026.
Submitting /mcp directly in an existing connected-computer task failed. The desktop logs record two turn/start rejections at 17:29:28.850 and 17:29:33.188 UTC:
code=-32602
failureReason=invalid_config
invalid turn/start params: AbsolutePathBuf deserialized without a base path
PowerShell execution in the connected-computer task still works. The rejected path-valued field and the underlying cause have not been identified.
Browser policy-loading errors and unavailable Browser / Computer Use tools were also observed, but their relationship to this submission failure is unconfirmed.
Please provide a supported recovery for the existing task that preserves its history and permission scope, or guidance for collecting the minimum sanitized diagnostic needed to identify the rejected field.
supplefrog commentedon Oct 15, 2026
Additional reproduction on Windows Codex Desktop, 15 October 2026 UTC, involving an existing durable task.
invalid turn/start params: AbsolutePathBuf deserialized without a base pathThis confirms the exact turn/start error for the affected task. It does not establish that the parent-send timeouts or initial navigation failure share its cause. The rejected path field and responsible client/service layer remain unknown. The current running app version has not been reverified.
Please provide a supported recovery or fixed release for the original task that preserves its history and permission scope, plus field-specific sanitized diagnostics if needed. No database edits, queue modifications, or permission bypass were performed for this report. Private task/request IDs, host/usernames, local paths, raw logs, and conversation contents are omitted.