Exact error
Match the message before using the fix
Error creating task Invalid request: AbsolutePathBuf deserialized without a base pathError starting chat — Invalid request: AbsolutePathBuf deserialized without a base pathQuick answer
Start here
First identify whether the workspace is native Windows or WSL. For a native Windows folder, use native Windows mode; a WSL-mode reporter restored chat creation by switching modes. If you are already native in VS Code, use Developer: Reload Window as a temporary recovery, then reopen the folder from a single path namespace. These are environment-scoped workarounds, not a confirmed universal fix.
Diagnosis
Why it happens
- Codex can receive a path without the base-path context needed to reconstruct an absolute workspace path.
- The public reports span both WSL bridging and native VS Code state, so mode mismatch is one cause, not the only cause.
- Opening the same project through both a drive-letter path and a WSL path can preserve incompatible workspace state across a resumed task.
Safest first
Fixes, in order
Match Codex mode to the workspace filesystem
Applies when: Use when a Windows folder is opened while Codex is in WSL mode, or the reverse
A Windows 10 reporter restored task creation by switching from WSL to native Windows for the affected workspace.
- Close the failed task.
- If the project path begins with a Windows drive letter, select native Windows mode.
- If the repository lives inside the WSL filesystem, open it from WSL and run Codex there.
- Create a new task after the mode change.
Expected: A new chat starts without the AbsolutePathBuf request error.
Reload the VS Code window
Applies when: Temporary recovery for a native Windows VS Code extension report
Reloading cleared the failing extension state for the reporter, but the error could return later.
- Save open files.
- Open the Command Palette.
- Run `Developer: Reload Window`.
- Reopen Codex and start a new chat in the same folder.
Expected: Chat creation works for the reloaded window. Treat recurrence as evidence that the underlying state remains unresolved.
Reopen the repository from one canonical path
Applies when: Use when the same repository has been opened through C:\, /mnt/c, a junction, or a symlink
Using one path namespace reduces ambiguity while collecting a reproducible upstream report.
- Close all windows for the repository.
- Choose either the native Windows path or the WSL path that actually owns the files.
- Open a fresh editor window from that path.
- Start a new task instead of resuming one created under a different mode.
Expected: The workspace and Codex runtime now use the same path namespace.
Verification
Prove the fix worked
- Create a new chat, not only a resumed one.
- Ask Codex to report the current working directory.
- Confirm the reported path belongs to the selected native or WSL environment.
Escalation
If it still fails
- Record native versus WSL mode, the exact folder path, Codex app/extension version, and whether Reload Window helps only once.
- Test a newly created empty folder in the same filesystem to separate workspace state from installation state.
- Attach those details to the relevant upstream issue; do not present a mode switch as a permanent fix if the project actually lives in WSL.
Scope
Environment and version notes
- The WSL-mode report used Codex Desktop on Windows 10; the separate native report used Windows 11 and the VS Code extension.
- Reload Window was temporary in the native report.
- Sources rechecked August 20, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.