Windows Native: durable-task follow-ups fail with AbsolutePathBuf; mixed paths and permission-profile correlation

Summary — updated October 2, 2026

Windows Desktop follow-ups to dot/cloud-created tasks can fail before a new turn starts, even though the task's initial turn completed and its history remains readable:

invalid turn/start params: AbsolutePathBuf deserialized without a base path
code=-32602 failureReason=invalid_config method=turn/start

Correction to the original report: moving the project-list task folder outside OneDrive-managed Documents worked for one new task, but it is not a general fix. Subsequent reproductions include non-OneDrive Documents, a Windows home directory, and a directory outside both Documents and OneDrive. The original test did not establish OneDrive as the cause.

Environments

Original report: Windows 11; Codex Desktop 26.928.1915.0; bundled app-server 0.159.0; Windows Native was already selected.
Additional reports here: Windows packages 26.928.2636.0 and 26.928.3736.0, with runtime/CLI 0.159.2. The October 1 outside-Documents reproduction uses a configured CLI runtime override.
Related October 2 reproduction in [Windows][dot/Work] Computer tasks lack browser/desktop tools: durable MCP startup failures and follow-up path error #49488: Windows Codex Desktop 26.930.21537, build 12776.

Confirmed observations reported in this issue

Mixed paths and failure outside the original folder

The original local log showed a Linux cloud prefix joined to a Windows task path. An isolated app-server probe reproduced the parser error with a mixed path; a normal Windows absolute path passed parsing. That probe does not identify the exact field rejected in live Desktop requests.

The September 30 reproduction reports two dot-created tasks with hostId=durable. One could execute Windows PowerShell, but Desktop replies failed. Creating another task with an explicit Windows home-directory cwd did not avoid the mixed path or follow-up failure.

The October 1 reproduction reports a readable, idle durable task outside Documents and OneDrive. All three Desktop submissions failed before creating a turn. Its sanitized cwd had this shape:

/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/E:\work\project

Adjacent composer logs show mode=local followUp=local. These are observed fields, not proof of the exact backend route or rejected path field.

Permission-profile correlation

A separate reproduction on Windows 11 Pro, package 26.928.3736.0 / CLI 0.159.2, uses Documents folders that are not OneDrive-managed. The reporter compared turn-start config resolved rows across durable tasks:

Task	Composer permission setting	`requestSandboxPolicyType`	Desktop follow-ups
A	“Approve for me”; `activePermissionProfile=:workspace`	`null`	2 of 2 started
B	“Custom”; no profile	`workspaceWrite`, one writable root	8 of 8 failed with `AbsolutePathBuf`
C, fresh task; settings never changed	“Custom”; no profile	`workspaceWrite`, one writable root	First follow-up failed

The dot's own messages to these tasks succeeded. This is a correlation across tasks on one installation, not a controlled same-task profile-switch test or a proven general workaround.

Related October 2 reproduction: #49488

The October 2 update, tested in UTC+08:00 on Desktop 26.930.21537 / build 12776, reports:

A brand-new dot-created task after the update completed its initial turn and successfully executed Windows PowerShell.
That task reported missing browser/CUA, node_repl, and native local conversation-management entry points; it could not enumerate Chrome tabs. No fresh underlying MCP startup exception was captured in this test.
An ordinary local chat on the same machine and version successfully used mcp__cua_repl.js through the Chrome extension to open https://example.com/, click “Learn more,” and verify the resulting IANA page.
Both native send_message_to_thread and the user's manual Desktop composer follow-up failed before another turn started with AbsolutePathBuf deserialized without a base path.
Task metadata again combined a Linux cloud-workspace prefix with a Windows absolute working directory.

Earlier comments in #49488 document durable MCP startup failures and successful dot-originated continuations where native continuations failed. The October 2 test covers native-tool and human-composer follow-ups; it does not establish failure of the dot's own continuation API. Other installations report broader local-tool failures, so the successful local control above is specific to that reproduction.

Hypotheses and unresolved questions

The permission comparison suggests that an explicit Windows writable root in the client-supplied workspaceWrite policy may be interpreted relative to the Linux cloud workspace. The exact failing field and code path remain unconfirmed.
Mixed cwd metadata may be relevant, but the reported logs do not contain the full failing turn/start payload. Do not assume cwd alone is the rejected field.
The follow-up path error and delegated browser/MCP tool failures may be related, but a shared root cause has not been established. Fixing one must not be assumed to fix the other.

Workaround status

The original folder change allowed one new task to complete and accept a second turn; it did not repair existing tasks. Later reports rule it out as a general fix. A replacement explicitly created as a local chat started successfully in one investigation, but that investigation did not test its second turn. Updating and creating a fresh dot task did not avoid either symptom in the October 2 reproduction. No universal workaround or history-preserving repair is established.

Duplicate notice and related reports

The automated duplicate suggestion points to #48583. That report concerns WSL-style paths and thread/resume failing with -32600; a probe reproduced the error through runtimeWorkspaceRoots, and restarting restored that user's chat. This report concerns durable Windows tasks failing at turn/start with -32602, mixed cloud/Windows paths, and a permission-profile correlation. The same error text is relevant, but it does not establish the same failing field, cause, or recovery. Please retain these reproduction differences if consolidating the reports.

#49488 tracks the overlapping path symptom plus delegated browser/MCP capability failures. Earlier related references from this report: #40881 and #42984.

Requested maintainer investigation and expected behavior

Please focus on durable-task Windows path and permission handling:

Trace Windows cwd and permission-policy writable roots through dot-task creation, durable persistence, connected-executor routing, and Desktop turn/start serialization. Identify the exact rejected field and the producer/consumer platform assumptions.
Compare profile-based requests (:workspace, no explicit sandbox policy) with “Custom” requests carrying workspaceWrite roots, and compare Desktop/native follow-ups with dot-originated continuations. Valid Windows roots should retain Windows semantics across these boundaries.
Provide a supported way to collect sanitized failing-request fields and underlying delegated MCP startup errors, keeping the browser/CUA investigation distinguishable from the path failure.
Provide a supported repair or migration that lets already affected tasks resume without losing history. Cover initial turns and follow-ups, fresh and existing durable tasks, both permission configurations, directories inside/outside Documents and OneDrive, and restart/reconnect in regression tests.

Expected: a connected Windows task that completes its initial turn should accept valid follow-ups under its supported permission configuration without path-deserialization failure. Any related browser/CUA fix should also be verified against the fresh-task/local-control comparison in #49488.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows Desktop thread/read succeeds but thread/resume rejects WSL runtimeWorkspaceRoots; restart restores chat #48583

Powered by Codex Action

Additional reproduction on Windows, observed 2026-09-30. This case involves two tasks created by a dot/cloud agent and then opened for replies in the Windows desktop app.

Environment

Installed Windows package: OpenAI.Codex_26.928.2636.0_x64 (from local app log).
Desktop runtime log release: 26.928.21956.
Bundled executable reports codex-cli 0.159.2.
OS reports Microsoft Windows NT 10.0.26200.0.
Affected threads report hostId=durable; an ordinary local chat on the same computer works.

Observed behavior

The original task can run Windows PowerShell through the connected computer executor, but subsequent user replies fail before a turn starts:

invalid turn/start params: AbsolutePathBuf deserialized without a base path
code=-32602 failureReason=invalid_config method=turn/start

Reading the two affected thread records returns working directories with these structures (user and cloud instance identifiers redacted):

/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/C:\Users\<user>\Documents\Codex\2026-09-30\task
/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/C:\Users\<user>

The second task was specifically created with an explicit Windows home-directory cwd as an attempted workaround; it acquired the same mixed path and replies still failed. Therefore simply supplying a Windows absolute cwd at creation did not prevent this failure.

Selected desktop log events, UTC:

2026-09-30T15:30:43.135Z: first affected task, turn/start, -32602, exact error above.
2026-09-30T16:06:15.291Z: same task, same error.
2026-09-30T16:11:34.849Z and 16:12:19.813Z: second affected task, same error.

Adjacent composer error records show the corresponding mixed cwd and followUp=local mode=local. These are observed log fields, not proof of the exact backend routing or failing field.

Scope and workaround

Only these two tasks were identified as affected in this investigation. A replacement created explicitly as a local chat reports hostId=local, a normal Windows absolute cwd, and its initial turn started successfully. A second-turn reply test in the replacement has not been performed by this investigation; this is a recovery workaround, not a verified repair of the original records.

Neither affected thread was present in the local state_5.sqlite threads table. No cloud record, local state database, permissions, or installed app files were edited. OneDrive involvement was not tested; the home-directory example above may help distinguish path normalization from Documents-specific behavior.

Requested fix

Please investigate platform-aware cwd handling across dot child-task creation, durable thread persistence, connected Windows executor routing, and desktop follow-up serialization. Linux cloud path normalization must not turn a Windows executor's absolute path into a relative suffix of the cloud workspace. Please also provide a supported repair/migration for already affected threads that preserves their history, and test both initial runs and subsequent replies across desktop restart/reconnect.

Related dot/Windows capability report: #49488. A shared root cause is not established. This comment contains sanitized evidence only; private chat IDs, full logs, and conversation contents are omitted.

Additional data point: the thread's permission preset correlates with the failure (26.928.3736.0)

I see the same error on Windows 11 Pro, package 26.928.3736.0, bundled CLI 0.159.2, for dot-created tasks running on the connected PC (hostId=durable). The task folders are under %USERPROFILE%\Documents\Codex\<date>\task-N. That folder is not OneDrive-managed here, so OneDrive isn't needed to trigger the failure.

Comparing Desktop's turn-start config resolved log rows across dot-created tasks on this machine:

Task	Composer permission label	`requestSandboxPolicyType`	Follow-ups sent from Desktop
A	"Approve for me" (`activePermissionProfile` = `:workspace`)	`null`	2 of 2 started
B	"Custom" (no profile)	`workspaceWrite`, 1 writable root	8 of 8 failed with `AbsolutePathBuf`
C (fresh task, settings never changed)	"Custom" (no profile)	`workspaceWrite`, 1 writable root	First follow-up failed with `AbsolutePathBuf`

When the thread has no permission profile, Desktop sends an explicit workspaceWrite sandbox policy with a writable root on turn/start. The adjacent composer error shows the Linux cloud prefix joined to the Windows task path. When the thread has a profile, Desktop sends no sandbox policy and the turn starts. The dot's own messages to these same tasks succeed, which matches the entry-point difference noted in #49488.

This suggests the Windows writable root in the client-supplied sandbox policy is being resolved relative to the Linux cloud workspace. That's an inference from log fields, not a confirmed code path. Fresh dot-created tasks appear to start with no profile, so the first follow-up from Desktop fails by default.

No account or chat IDs, usernames, or machine names are included.

Additional reproduction on 2026-10-01 (Windows x64, NT build 26200.9457 / 25H2).

Installed Codex Windows package: OpenAI.Codex_26.928.2636.0_x64. The desktop log reports app-server 0.159.2; this installation uses a configured CLI runtime override (path omitted).
A distinct delegated thread reports hostId=durable and is readable and idle after its previous turn completed.
Its reported cwd has the shape /tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/E:\work\project. The Windows task directory is outside Documents and OneDrive.
Three desktop composer submissions (2026-10-01 11:22:56, 11:23:00, and 11:23:20 UTC) all failed at turn/start before creating a new turn:
```
code=-32602 failureReason=invalid_config
invalid turn/start params: AbsolutePathBuf deserialized without a base path
```
The adjacent composer error for the same thread records mode=local followUp=local alongside the mixed cloud/Windows cwd. This is observed routing/configuration evidence; the log does not include the full turn/start payload, so it does not identify the exact path field rejected by the parser.

This confirms another affected durable thread even when the Windows directory is outside the original Documents/OneDrive path. The thread remains readable, but desktop follow-ups cannot start. Please preserve a way to resume already affected threads when fixing the platform-aware path/routing behavior.

Additional reproduction on Windows Native.

Desktop version shown in About: 26.909.12148
Settings: Agent environment is Windows native; integrated terminal is PowerShell. WSL is not selected

Observed steps:

Have dot create a task on the connected Windows computer.
Open the task in the desktop app after its initial work has completed.
Type an ordinary follow-up message and send it.
Submission fails before a new turn begins with:

invalid turn/start params: AbsolutePathBuf deserialized without a base path

This affects two dot-created tasks. Every manual message attempted in those tasks fails, while ordinary pre-existing conversations on the same computer still accept messages. The affected tasks' completed history remains readable, and follow-ups sent by dot can still run.

Restarting the app and rebooting the computer did not resolve it. An app update was attempted, but About still shows 26.909.12148, so a newer installed build has not been verified.

Expected: the owner can send ordinary follow-up messages directly to a dot-created task from Desktop, while retaining the existing task history.

The underlying cause has not been confirmed. This report includes only the visible error, app/settings information, and observed reproduction behavior.

Additional user-visible symptom on the same Windows setup: file links in dot-created conversations also fail to open.

Clicking a task's file link shows the generic message “无法打开文件” (“Unable to open file”). The corresponding file exists on the computer. Opening it outside the app has not been verified.

This file-opening message is different from the AbsolutePathBuf error reported above for submitting messages; I have not observed that exact error when clicking a file link.

Ordinary pre-existing conversations still accept messages, but their file links have not been tested for comparison.

This may be relevant to task file-path handling, but a shared cause with the message-submission failure has not been established.

October 2 confirmation: manually changing the Desktop composer from Custom to Approve for me restored direct follow-ups in two affected dot-created Windows tasks on this installation.

Environment: Desktop package 26.930.2377.0, bundled CLI 0.159.0-alpha.12.1.

Same-task sequence, repeated on two fresh tasks:

Let the dot-created task complete its initial turn.
Open that task in Desktop; the composer shows Custom.
Submit a simple message. It fails with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Manually select Approve for me in that same task and submit a greeting.
A new turn starts and an assistant reply completes.

Successful replies were verified at 14:44 and 14:54 UTC. These are same-task before/after observations, adding evidence beyond the cross-task correlation above. Thanks to the earlier tests in #49753 (comment) for pointing us toward this.

Creating a fresh task with an explicit forward-slash Windows cwd did not prevent the failure in our test.

Automatic defaults remain unresolved: another fresh dot-created task at 15:40 UTC still opened as Custom, even after inspected older/newer local and durable preferences all showed guardian-approvals. No named custom permission profile was found in the inspected configuration. The practical workaround here remains manual selection per task.

This should be a deliberate permission-mode choice; we did not establish that every effective permission stayed identical. These observations do not prove that the displayed mixed cwd was repaired, that stored data was corrupt, or which request field failed.

Separately, the native MCP startup repair in #49820 enabled an actual message/reply with an existing local chat, including a successful later retest. A shared root cause with this composer failure is not established.

Please regression-test direct composer follow-ups under both modes and investigate why new dot-created Windows tasks still initialize as Custom despite the saved preferences.

Can confirm this bug and that setting the permissions in the activity chat clears the bug. My working theory is that dot creates the activity chat but doesn't have the "permission" to set further permissions. Therefore the exception catcher defaults the null value to a "custom" label and once the user sets a value for that, the chat session is then properly formed and the issue is corrected.

Additional sanitized reproduction on October 3, 2026: this still occurs after updating Codex Desktop on Windows.

Verified versions:

Desktop app: 26.930.31428
Windows package: 26.930.3748.0
Bundled Codex CLI: 0.160.0

The same installation previously reproduced the problem on app 26.930.21537 / package 26.930.2377.0 / bundled CLI 0.159.0-alpha.12.1.

Observed behavior:

A task created by dot can execute work on the connected Windows computer, and its history remains readable.
Submitting a follow-up through the Windows Desktop composer fails before the user message is delivered. The text remains in the pending/retry row.
The exact visible error is: invalid turn/start params: AbsolutePathBuf deserialized without a base path.
Application logs record turn/start, error -32602, and failureReason=invalid_config.
Restarting the app did not resolve the issue. It remained reproducible after the verified update above.
A newly created replacement task with an explicitly supplied Windows absolute working directory also completed its initial work but failed on a direct human follow-up with the same error.

Parent-to-task delegated messages continued to work, while the direct Desktop composer failed. The composer displayed Custom. Logs showed mixed Linux/Windows path representation, but the complete failing request payload was not captured, so the exact rejected field and root cause are not established.

The permission-mode workaround described in earlier comments has not yet been tested on this installation. No claim is made that changing permissions is a permanent fix or that all effective permissions would remain identical.

Please include this newer app/package/CLI combination in regression testing for initial and subsequent human turns in Windows-connected durable tasks, especially Custom permission-policy path serialization. A history-preserving recovery would be helpful.

Privacy: this comment intentionally contains no source code, private repository or project names, real filesystem paths, account or conversation identifiers, credentials, screenshots, or raw logs.

Follow-up to the newer-build reproduction above: a same-task recovery has now been verified on this installation (app 26.930.31428 / Windows package 26.930.3748.0 / bundled CLI 0.160.0).

The owner manually changed the affected task's Desktop composer permission selection from Custom to Approve for me. A harmless no-op follow-up then successfully started a turn and received an assistant response. Delivery of the user message and completed response was independently confirmed by reading that same task's history. This is the same replacement task whose direct composer submission had previously failed with the exact AbsolutePathBuf error.

This is evidence for a permission-selection workaround on this installation, not an OpenAI-confirmed fix or proof of a particular rejected request field. We have not established that every effective permission is identical across these modes. No Full access selection was used. Restarting and creating the replacement task alone had not resolved the failure.

Please preserve this as a regression case for Custom permission-policy serialization and Windows-connected durable tasks. No private paths, project information, source code, conversation identifiers or contents, screenshots, raw logs, or credentials are included.

Additional reproduction reported on 2026-10-03: follow-up submission to the same existing durable task fails from Windows and also after switching to Linux under WSL, with invalid turn/start params: AbsolutePathBuf deserialized without a base path.

The user inspected a working-directory value with this shape (identifiers redacted):

/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/C:\Users\<user>\Documents\Codex\<date>\task-<n>

The user suspects the mixed path is persisted with the task, explaining why changing the submission environment does not help. This is a hypothesis: the complete failing turn/start payload and the receiving parser platform were not captured. The displayed mixed path itself begins with /, so it does not by itself identify the rejected AbsolutePathBuf field. Also, this displayed directory is from an affected task; its exact relationship to the specific editor task awaiting follow-up has not yet been independently verified.

Previously inspected local cwd/TEMP values were valid absolute paths. Please investigate environment-native path mapping versus top-level runtimeWorkspaceRoots and explicit sandboxPolicy.writableRoots in durable follow-ups, and provide field-specific sanitized diagnostics and a supported recovery preserving the existing task/history/Git work.

No All Approve/Full Access workaround has been tested or claimed for this reproduction. Parsing failure is separate from later action-approval decisions. Exact app/bundled-runtime versions for this new reproduction are not yet captured.

This report intentionally omits private session IDs, actual usernames/paths, project contents, credentials, screenshots and raw logs.

Additional same-task evidence from a Windows diagnostic on October 3, 2026, prepared with Codex assistance at the owner's request.

Diagnostic versions: Desktop 26.930.31428, Windows package 26.930.3748.0, CLI 0.160.0.

After the owner selected Approve for me, a direct owner message started a turn in the affected durable test record. One native send_message_to_thread follow-up also completed and returned the requested harmless acknowledgment. Its configuration log showed requestPermissionProfile=:workspace.

Later native follow-ups to the same record failed before a turn started:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Code -32602, method turn/start, failureReason=invalid_config.

The failed request's configuration log showed:

requestPermissionProfile=null
requestSandboxPolicyType=workspaceWrite
requestSandboxWritableRootCount=1

A read-only check immediately afterward still found the task's persisted activePermissionProfile=:workspace. Reopening the same task and submitting once more reproduced the error. This suggests that selecting the preset alone may not keep subsequent native requests on the profile-based path. The complete failing payload was not captured, so the exact rejected field remains unknown.

Important scope limit: this record originated from a failed Dot-side creation that left readable metadata. Dot could read it, but cloud_threads.send_message returned CloudThreadNotFoundError / NOT_FOUND. That may reflect incomplete creation, rather than the behavior of healthy Dot-created tasks. A separate healthy delegated task was later successfully continued and read through Dot's cloud_threads interface. These cases should not be merged into a claim that all Dot continuations fail.

Please include this successful-then-failing same-record sequence in the Windows durable-task regression tests, and advise how to diagnose effective profile selection and recover affected records through supported APIs without rewriting history. No Full access setting was used.

This comment contains no private filesystem paths, user/device/account/task/environment identifiers, browser URLs or contents, screenshots, credentials, project contents, or raw logs/transcripts.

Additional reproduction on October 4, 2026: direct follow-ups to dot-created Windows tasks still fail after updating the desktop app.

Environment

Windows reported version: 10.0.26200
Current desktop package: 26.930.3930.0
Current desktop-bundled CLI: 0.160.0
A separate standalone CLI is installed at 0.154.0. This is not the bundled desktop CLI version, and I am not claiming that the standalone installation handles the failing UI request.
Before the update: desktop package 26.930.2377.0 and bundled CLI 0.159.0-alpha.12.1

Reproduction

Connect a Windows computer to dot and ask dot to create a task on that computer.
Allow the initial task turn to finish.
Open that conversation in the desktop app and submit a plain-text follow-up.
The UI displays:
Error submitting message
invalid turn/start params: AbsolutePathBuf deserialized without a base path

Expected: I should be able to continue the task directly from its conversation.

Observed:

The initial task runs, and dot can successfully relay follow-ups to its own task.
The conversation remains readable, but my direct UI submissions fail.
The conversation is shown as cloud/durable, although execution reports an actual Windows working directory. The label alone does not establish where execution happens.
Updating the app did not resolve the direct-submission failure.

Post-update evidence
Three correlated turn/start failures for the same task were recorded on October 4, 2026 at:

20:31:39.339 UTC
20:31:44.199 UTC
20:31:50.038 UTC

All returned errorCode=-32602 with the AbsolutePathBuf message above.

The logged cwd has this redacted mixed-platform shape:
/tmp/codex-cloud-agent-/app_servers/thread_service/workspace/C:\Users<USER>\Documents\Codex<DATE>\task

Direct execution reports the actual Windows workspace as:
C:\Users<USER>\Documents\Codex<DATE>\task

Shortly before these failures, the local stdio connection initialized successfully at 20:25:51.012 UTC, and the durable WebSocket connection initialized at 20:25:54.421 UTC. This makes a simple disconnected-computer explanation less likely, although initialization alone does not prove every connection path is healthy.

Possible area to investigate
The observed path mismatch suggests Windows/cloud path serialization or routing at the direct follow-up boundary. I have not captured the complete failing request payload or identified the exact rejected field. Please check cwd and permission-policy/workspace-root handling rather than assuming cwd alone is responsible.

Could you confirm whether this is the same defect tracked here, and provide a supported fix for existing affected tasks that preserves their history and permission controls?

Related reports:
#49753
#50428

Usernames, machine names, full task/environment IDs and unrelated project information are omitted. Full identifiers are available privately for support correlation.

I’m seeing this on Codex Desktop 26.930.3930.0, Windows x64, when replying to an existing durable task directly from the desktop sidebar.

The task history opens and thread/resume succeeds, but six manual follow-ups failed before a turn was admitted:

invalid turn/start params: AbsolutePathBuf deserialized without a base path

code=-32602, method=turn/start, pendingCountAfter=0

The inspected composer diagnostics show followUp=local mode=local and a computed cwd with this redacted shape:

/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/C:\Users\<redacted>\.codex\.chatgpt-projects\<redacted>\<project>

The actual Windows checkout exists. Dot-originated delegated continuations still reach the same task; direct desktop replies do not. This was an existing-task reply, not a new-task creation attempt.

The mixed computed path is observed, but the full rejected RPC payload was not logged, so I can’t confirm which AbsolutePathBuf field is rejected. No permission changes, folder moves, or replacement-task workaround have been tested in this reproduction.

A supported way to repair or continue the existing task while preserving its local changes would be helpful.

Still reproducible on October 5, 2026 with Windows package 26.930.3930.0. Sending a direct follow-up to an existing task fails with: invalid turn/start params: AbsolutePathBuf deserialized without a base path.
Updating the app, restarting the computer, reopening the task, and switching away and back have not resolved it. Development has been blocked since October 3.
Could a maintainer confirm a supported fix or recovery for affected tasks that preserves their history, pending work, and permission controls?

Additional sanitized reproduction from October 6, 2026, with newer Windows versions and isolated parser checks.

Environment:

Desktop app: 26.930.61225 (build 13232)
Windows package: 26.930.7945.0
Installed Windows-native runtime: codex-cli 0.160.1
Affected existing task: durable host, WebSocket transport. The durable server build and the app's selected Windows-native/WSL mode were not independently verified.

Observed behavior:
An existing Windows task remains readable and accepts dot-originated delegated messages, but direct Desktop composer follow-ups fail before a turn starts. Six failures were recorded with:

invalid turn/start params: AbsolutePathBuf deserialized without a base path
method=turn/start; code=-32602; failureReason=invalid_config

The observed cwd has this sanitized structure:

/tmp/codex-cloud-agent-<instance>/app_servers/thread_service/workspace/C:\Users\<user>\Documents\Codex\<date>\task

The corresponding native Windows directory exists. Adjacent serialization diagnostics showed workspaceWrite, one sandbox writable root, zero runtime workspace roots, and no explicit permission-profile override.

Isolated diagnostics:
The installed Windows 0.160.1 parser was tested with an empty disposable diagnostic home, no inherited credential variables, and a nonexistent synthetic task. "Parsed" below means the request reached "thread not found"; no real task turn or approval ran.

Native or mixed cwd alone: parsed.
Native or mixed cwd with a native Windows sandboxPolicy.writableRoots entry: parsed.
Native or mixed cwd with a mixed cloud/Windows sandboxPolicy.writableRoots entry: AbsolutePathBuf error.
Native cwd with a POSIX sandbox writable root: the same error.
Native cwd with a native runtimeWorkspaceRoots entry: parsed; a mixed entry produced the error.
Cwd-only thread/settings/update, with native or mixed cwd: parsed.

The isolated parser returned -32600 / "Invalid request"; the live Desktop failure uses -32602 / "invalid turn/start params". These are distinct wrappers.

This narrows the hypothesis: a mixed sandbox writable root reproduces the installed Windows parser error, while mixed cwd alone does not. The actual live writable-root value, full rejected payload, and durable server build were not logged, so the live offending field and root cause remain unconfirmed. Cwd-only settings parsing is not evidence of a working recovery; no live settings update was applied.

Please investigate platform-aware normalization of cwd and permission/workspace roots across durable-task creation and Desktop follow-up submission. A supported, non-destructive recovery for existing affected tasks is needed that preserves history and current permission controls. No existing task records, configuration, security settings, or files were modified by this investigation; no destructive action was run.

This comment omits private paths and identifiers, account details, screenshots, raw logs, and session files.

Additional controlled same-task evidence on Windows Desktop 26.930.7945.0

I reproduced this again on Windows using a single existing durable/aeon child task and performed a controlled same-task permission-state test.

Environment:

Windows Desktop package: 26.930.7945.0
Bundled CLI: 0.160.1
Native Windows local executor
The affected task has a valid Windows environment cwd of the form:
C:\Users\<redacted>\Documents\Codex\<date>\task
Its cached top-level durable cwd still has the mixed shape:
/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/C:\Users\<redacted>\Documents\Codex\<date>\task

Before normalization

The affected durable child used:

activePermissionProfile=null
approvalPolicy=on-request
approvalsReviewer=auto_review
sandboxPolicy.type=workspaceWrite
one writable root (initially /tmp)

A failing follow-up logged:

requestRuntimeWorkspaceRootCount=0
requestSandboxPolicyType=workspaceWrite
requestSandboxWritableRootCount=1
then turn/start -> -32602 invalid_config
AbsolutePathBuf deserialized without a base path

The composer failure also showed the mixed durable cwd shape above.

Controlled same-task normalization

For the same task, with backups taken before each change, I normalized only permission-related persisted state to match a previously healthy local :workspace configuration observed on the same machine:

activePermissionProfile=:workspace
approvalPolicy=on-request
approvalsReviewer=user
sandboxPolicy.type=workspaceWrite
writableRoots=[]
networkAccess=false
excludeTmpdirEnvVar=false
excludeSlashTmp=false

I also removed the host-level durable composer override:

permission-selection-by-host-id:durable = { kind: "agent-mode", agentMode: "full-access" }

The local host's full-access selection was left unchanged.

This durable override removal was based on older state backups from the same installation, where the local host had full-access but the durable host override was absent. Those older logs also contain a healthy :workspace resume with:

requestPermissionProfile=:workspace
approvalPolicy=on-request
approvalsReviewer=user
writableRootCount=0

Result after normalization

The normalized settings persisted across Desktop restarts.

Important behavior change:

No new AbsolutePathBuf entry appeared in local Codex Desktop/app-server logs.
No new failed item was written to queued-follow-ups.
The durable host-level full-access override did not reappear.
The task still failed to submit from the Desktop UI, now only with a generic:
Something went wrong. Request ID: <redacted>
That new request ID did not appear in local Codex Desktop logs or local task state.

This suggests the original AbsolutePathBuf failure can be influenced by the client-side permission/sandbox override shape, but after normalizing those fields the same durable task still fails earlier in the durable/cloud submission path, before the request reaches the local app-server.

Interpretation

This strengthens the earlier permission-profile correlation, but also suggests there may be two layers:

a Windows path/AbsolutePathBuf failure when a client-supplied sandbox override is serialized for the durable task;
a separate durable/aeon submission or routing failure that remains even after the local permission state is normalized.

The local executor itself remains healthy: ordinary local execution and a separately verified local bridge continue to work with native Windows cwd paths.

No credentials, account identifiers, machine names, private conversation content, raw task/thread IDs, or real user paths are included here.

October 7 follow-up: fresh dot-created Windows task remains blocked at `turn/start`

A fresh dot-created task completed its initial turn after a desktop restart, but neither the native continuation tool nor direct Desktop composer submissions could start its next turn. This adds a fresh-task reproduction on the current versions to the existing report.

Environment

Windows x64, version 25H2, build 26200.9457.
Installed Windows/MSIX package: 26.930.7945.0.
Bundled desktop app metadata: 26.930.61225, build 13232 (read from installed resources; About dialog not collected).
Installed Windows CLI: 0.160.1; the durable server build was not independently verified.
Task metadata: hostId=durable; creation selected the intended connected Windows computer environment.

Observed sequence

Restart the desktop app, then create one fresh computer task from a dot using cloud_threads.create and the selected connected-computer environment.
The initial turn completes. In this case it only inspected task metadata and stopped before Computer Use initialization because it could not confirm the control-host binding from that metadata.
Use mcp__codex_app__send_message_to_thread to continue the same task. An explicit hostId=durable attempt and a second attempt with the optional host preference omitted both fail with:

invalid turn/start params: AbsolutePathBuf deserialized without a base path

Submit the follow-up directly in the same task's Desktop composer. Local logs independently record repeated failures before execution:

method=turn/start code=-32602 failureReason=invalid_config
message="invalid turn/start params: AbsolutePathBuf deserialized without a base path"
[Composer] submit failed mode=local followUp=local

Read the task again through the official task tools: it remains at its original completed turn; no continuation was admitted.

The composer log records this sanitized cwd shape:

/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/C:\Users\<user>\Documents\Codex\<date>\task

Adjacent configuration diagnostics record:

requestPermissionProfile=null
requestRuntimeWorkspaceRootCount=0
requestSandboxPolicyType=workspaceWrite
requestSandboxWritableRootCount=1
resolvedApprovalPolicy=on-request
resolvedApprovalsReviewer=auto_review

Control evidence and limitations

The local Windows app-server process remained running, and official task-read requests succeeded. A running process alone does not establish the health of every durable route.
The desktop resume log associates this task with the same environment selected at creation and records node_repl as ready. The task also reported the deferred mcp__node_repl__js entry point. These establish discovery/startup evidence only.
After restart, an ordinary local chat successfully used the official node_repl / @oai/sky entry to enumerate windows and the official Chrome entry to read a public page. No private window titles or page contents are included.
The fresh dot task never executed import('@oai/sky') or sky.list_windows(). Its Computer Use functionality remains untested; this reproduction does not establish a new missing-tool or Windows API failure. See [Windows][dot/Work] Computer tasks lack browser/desktop tools: durable MCP startup failures and follow-up path error #49488 for the related earlier delegated-tool reports.
A pre-existing compatibility workaround was active: unmodified vendor resources were mirrored outside the MSIX package through CODEX_ELECTRON_RESOURCES_PATH and CODEX_ELECTRON_BUNDLED_PLUGINS_RESOURCES_PATH, with relevant binary hashes checked against the installed package. Signed app binaries were not patched. A clean-install comparison was not performed.
The user additionally reported Codex app-server is not available. Its exact failing operation was not captured, so it should be treated as a separate user-reported symptom pending correlation.

Requested investigation

Please identify the rejected turn/start field and how Windows cwd / permission roots are serialized and restored across the durable/local boundary. The mixed cwd and policy fields are observations; the full rejected request payload was not captured, so the offending field and root cause remain unconfirmed.

A supported recovery for existing affected tasks that preserves history and permission controls is needed. Fresh task creation and a desktop restart did not avoid the continuation failure in this reproduction.

Testing has been stopped. This comment contains manually selected, sanitized fields only; no raw logs, session files, screenshots, credentials, private conversation content, usernames, machine names, real local paths, or task/environment/request identifiers are attached.

Navigation Menu

Repository navigation

Windows Native: durable-task follow-ups fail with AbsolutePathBuf; mixed paths and permission-profile correlation #49477

Summary — updated October 2, 2026

Environments

Confirmed observations reported in this issue

Related October 2 reproduction: #49488

Hypotheses and unresolved questions

Workaround status

Duplicate notice and related reports

Requested maintainer investigation and expected behavior

Environment

Observed behavior

Scope and workaround

Requested fix

Additional data point: the thread's permission preset correlates with the failure (26.928.3736.0)

Additional controlled same-task evidence on Windows Desktop 26.930.7945.0

Before normalization

Controlled same-task normalization

Result after normalization

Interpretation

October 7 follow-up: fresh dot-created Windows task remains blocked at `turn/start`

Environment

Observed sequence

Control evidence and limitations

Requested investigation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Native: durable-task follow-ups fail with AbsolutePathBuf; mixed paths and permission-profile correlation #49477

Description

Summary — updated October 2, 2026

Environments

Confirmed observations reported in this issue

Related October 2 reproduction: #49488

Hypotheses and unresolved questions

Workaround status

Duplicate notice and related reports

Requested maintainer investigation and expected behavior

Activity

github-actions commented on Sep 30, 2026

TheLucidBaron commented on Sep 30, 2026

Environment

Observed behavior

Scope and workaround

Requested fix

alecwardd commented on Oct 1, 2026

Additional data point: the thread's permission preset correlates with the failure (26.928.3736.0)

WQMYH commented on Oct 1, 2026

Jasmine210220 commented on Oct 2, 2026

Jasmine210220 commented on Oct 2, 2026

SevxLabs commented on Oct 2, 2026

platypustheory commented on Oct 2, 2026

counter612 commented on Oct 3, 2026

counter612 commented on Oct 3, 2026

ZouBadCode commented on Oct 3, 2026

BIG-legion commented on Oct 3, 2026

enigmaticenter commented on Oct 4, 2026

dingusbacon commented on Oct 5, 2026

YardSI commented on Oct 5, 2026

haymovie commented on Oct 7, 2026

dongyicheng178-pixel commented on Oct 7, 2026

Additional controlled same-task evidence on Windows Desktop 26.930.7945.0

Before normalization

Controlled same-task normalization

Result after normalization

Interpretation

Littledogewww commented on Oct 7, 2026

October 7 follow-up: fresh dot-created Windows task remains blocked at turn/start

Environment

Observed sequence

Control evidence and limitations

Requested investigation

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

October 7 follow-up: fresh dot-created Windows task remains blocked at `turn/start`