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

[armaghanshahzad]

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

[blonestar]

I can confirm a similar /resume failure is still reproducible.

Environment

• OS: Windows 10.0.26200.8246
• Shell: PowerShell / Windows Terminal
• Codex CLI: reproduced on 0.125.0, 0.126.0-alpha.7, and 0.126.0-alpha.8
• Model: gpt-5.5 high
• CODEX_HOME: C:\Users\B*****\.codex-openai

Symptom

Running codex, then opening /resume, initially displays the resume picker and the first page of sessions.

It then reaches:

Loading older sessions...

and exits with:

Error: thread/list failed during TUI session lookup

Important detail

This is not only codex resume <thread_id>. The failure happens while the TUI resume picker is paginating / loading older sessions, before selecting a thread.

Version verification

This was reproducible on stable 0.125.0 and still reproduces after upgrading through the alpha builds.

Current installed version:

codex-cli 0.126.0-alpha.8
@openai/codex@0.126.0-alpha.8

Recent logs show thread/list running under alpha.8:

app_server.client_name="codex-tui"
app_server.client_version="0.126.0-alpha.8"
rpc.method="thread/list"

The recorder successfully resumes many rollout files with parse errors: 0 up to older sessions around March 12, then the TUI still exits with:

Error: thread/list failed during TUI session lookup

Local cleanup already attempted

I already tried cleaning obvious local data problems:

• archived/moved previously detected bad historical rollout files
• removed those IDs from session_index.jsonl
• normalized old DB threads.rollout_path values from \\?\C:\... to C:\...
• verified the normalized rollout files exist
• restarted stale Codex desktop/app-server processes
• reproduced again on a fresh 0.126.0-alpha.8 CLI session

The picker still crashes during older-session pagination.

Expected behavior

thread/list should tolerate, skip, normalize, or degrade invalid legacy Windows rollout/path data instead of failing the entire /resume picker.