codex - 💡(How to fix) Fix Codex Desktop on Windows: existing history thread opens/resumes inconsistently; thread/goal/get returns "goals feature is disabled"

What version of Codex is running?

• Codex Desktop: 26.513.31313
• Codex CLI recorded in the thread metadata: 0.131.0-alpha.9

What subscription do you have?

Not included in this public report.

Which model were you using?

gpt-5.5

What platform is your computer?

Windows 10 Pro 22H2, build 19045, x64.

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

Codex Desktop on Windows. The workspace shell is PowerShell.

What issue are you seeing?

After a recent Codex Desktop update, some existing history conversations frequently fail to open correctly from history / resume flows. The underlying local data still exists and appears valid, but the Desktop UI reports/opening behavior is inconsistent.

Example affected conversation:

• conversationId: 019e2fa5-0472-7cd3-a672-368b01774be1

Local inspection suggests this is not a corrupt rollout file:

• rollout JSONL exists under %USERPROFILE%\.codex\sessions\...
• rollout size: ~21.82 MB
• line count: 8389
• JSON parse errors: 0
• largest line: 357913 bytes
• image/base64-containing lines: 3
• state_5.sqlite PRAGMA integrity_check: ok
• threads table contains the conversation id with archived = 0
• thread/read and thread/resume are routed successfully in Desktop logs

However, Desktop logs show this error during resume/open:

method=thread/goal/get errorCode=-32600
error={"code":-32600,"message":"goals feature is disabled"}
Failed to hydrate thread goal after resume
maybe_resume_success conversationId=019e2fa5-0472-7cd3-a672-368b01774be1 ... markedStreaming=true

There are also early warnings for this conversation:

No cwd found for local task conversationId=019e2fa5-0472-7cd3-a672-368b01774be1

One suspicious metadata detail: the threads.cwd value in SQLite is recorded with a Windows native namespace prefix like \\?\D:\..., while the rollout session_meta.cwd uses the normal D:\... form. The local session_index.jsonl also does not contain this conversation id, although state_5.sqlite does.

What steps can reproduce the bug?

1. On Windows Codex Desktop 26.513.31313, open/resume an existing history conversation that was created by Codex Desktop and has a local rollout JSONL.
2. The affected conversation has multiple compactions/rollbacks/aborted turns, but the JSONL parses cleanly.
3. Attempt to open the conversation from history or resume it.
4. Observe that Desktop attempts thread/read and thread/resume, then thread/goal/get fails with goals feature is disabled. The user-facing history/open behavior is unreliable even though the thread data is present and readable locally.

What is the expected behavior?

Existing history conversations with valid rollout JSONL and valid threads DB rows should open normally. If the goals feature is disabled, Desktop should not treat thread/goal/get hydration failure as a blocking/error condition for opening a thread.

Additional information

This may be related to #20841, but that report covers TUI/macOS. This report is for Codex Desktop on Windows and the history/open/resume path.

Potentially related areas:

• Desktop thread/goal/get hydration when goals are disabled
• Windows cwd normalization between \\?\D:\... and D:\...
• history/index consistency when state_5.sqlite contains the thread but session_index.jsonl does not

I intentionally omitted full logs and local project contents from this public issue, but the conversation id and the summarized diagnostics above should help identify the failing path.