Two historical commandExecution.cwd values decode as invalid Windows drive-relative path

What version of Codex CLI is running?

0.125.0

What subscription do you have?

enteprise

Which model were you using?

gpt-5.5

What platform is your computer?

Windows:

What terminal emulator and version are you using (if applicable)?

PowerShell

What issue are you seeing?

Codex 0.125.0 Windows Resume Decode Failure
Summary
@openai/codex / codex-cli 0.125.0 fails to resume a legacy Windows rollout created by codex-cli 0.112.0.

Error:

Error: thread/resume: thread/resume response decode error: AbsolutePathBuf deserialized without a base path
The same rollout can be resumed by codex-cli 0.112.0 on gpt-5.4.

Environment
OS: Windows
Current Codex: codex-cli 0.125.0
Legacy session writer: codex-cli 0.112.0
Target thread: 019cd475-5fc3-7511-b845-17231dcec7ba
User model config: model = "gpt-5.5", model_reasoning_effort = "xhigh"
Isolated Cause
The 0.125.0 app-server can produce a raw thread/resume response, but the 0.125.0 client fails while decoding it because the response contains two commandExecution.cwd fields that are not absolute Windows paths:

That value is drive-relative on Windows, not absolute. It is therefore invalid for AbsolutePathBuf.

The malformed fields came from historical rollout lines where old failed command executions recorded:

Original cloned rollout evidence:

line 56479 call_id=call_OrLlZ1Mb4EfF6ZrrYsBhdaOW
line 56480 call_id=call_Fytzdzztg3yAGnTZnYT5YcPI
turn_id=019d5f06-6f6d-7c92-8d35-5a7df40dbe95
Version Regression Signal
Generated protocol comparison:

0.118.0 v2.ThreadItem commandExecution.cwd: string
0.125.0 v2.ThreadItem commandExecution.cwd: AbsolutePathBuf
This means old tolerated string data can now break resume decoding if any historical command cwd is malformed or drive-relative.

Verification
Using a cloned Codex home only:

thread/resume with excludeTurns=true succeeds under 0.125.0.
Full raw 0.125.0 thread/resume response was captured without starting a model turn.
Scanner found exactly two invalid absolute-path fields, both commandExecution.cwd.
Clone-only normalization replaced:
C:\\Users\\admin\\D:\\ -> D:\\
C:\\\\Users\\\\admin\\\\D:\\\\ -> D:\\\\
Regenerated full 0.125.0 resume response then scanned clean:
turns=1823
command_executions=24569
bad_read_paths=0
other_bad_absolute_fields=0
Expected Fix
On resume/read/fork payload generation, 0.125.0 should not emit invalid AbsolutePathBuf values from legacy rollout history. Safe options:

Normalize historical malformed Windows cwd values before serializing v2 commandExecution.cwd.
If normalization is impossible, fall back to the thread cwd or omit/mark the command item instead of failing the whole resume.
Keep legacy command cwd as string or use a lossy legacy field when replaying older rollout records.
Local Workaround
The local workaround is to patch only the historical malformed cwd strings in the rollout JSONL after making a backup, then resume with latest Codex.

Guarded local script prepared:

C:\Windows\System32\codex-repair-resume-019cd475.ps1
C:\Windows\System32\codex-repair-resume-019cd475.cmd
The script refuses to run if a Codex process appears to still reference the target session

What steps can reproduce the bug?

codex resume 019cd475-5fc3-7511-b835-17231deec7ba but getting Use current directory (C:\Windows\System32)Error: Failed to resume session from C:
\Users\admin\.codex\sessions\2026\03\09\rollout-2026-03-09T22-16-27-019cd475-5fc3-7511-b835-17231deec7ba.jsonl

What is the expected behavior?

To be able to codex resume on the same session after upgrade to Codex 0.125.0

Additional information

_No response_