Codex Desktop on Windows: existing history thread opens/resumes inconsistently; thread/goal/get returns "goals feature is disabled"

[edwinking81]

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.

[github-actions]

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

• Codex Desktop: clicking one completed session can break opening all existing sessions #22969
• Codx Chat History Bug after updating #22971
• Codex Desktop on Windows cannot resume local chats until app restart #21659

Powered by Codex Action

[edwinking81]

Additional sanitized diagnostics after comparing multiple affected conversations on the same Windows machine.

I checked three affected local conversation records:

• 019e2fa5-0472-7cd3-a672-368b01774be1
• 019e2fca-7877-7cc1-b2b9-43a726e345f1
• 019e3037-835b-74b0-93b2-4126c217070a

Common local data properties:

• All rollout JSONL files exist and parse cleanly: parseErrors = 0 for all three.
• File sizes vary widely, so this does not look like a simple large-file threshold issue:
  • ~21.82 MB, 8389 lines
  • ~3.29 MB, 1224 lines
  • ~1.63 MB, 549 lines
• All three have source = vscode in state_5.sqlite.
• All three have model = gpt-5.5 and reasoning_effort = xhigh.
• All three have cwd stored in SQLite using a Windows native namespace prefix like \\?\D:\..., while rollout/session metadata uses the normal drive path form. I am redacting the actual workspace path here.
• Two of the three had already been archived/moved to archived_sessions; one remained in sessions. The issue reproduces across both states.

Common Desktop log sequence when attempting to open/resume these conversations:

method=thread/read        errorCode=null
method=thread/resume      errorCode=null
method=thread/goal/get    errorCode=-32600
error={"code":-32600,"message":"goals feature is disabled"}
Failed to hydrate thread goal after resume
maybe_resume_success ... latestTurnStatus=completed markedStreaming=true

That last line looks especially suspicious: the latest turn status is completed, but Desktop records markedStreaming=true after resume. This may be putting the UI into a stale streaming/resume state even though the thread is complete.

I also checked whether a specific streamed final-output shape might be the trigger. The three affected examples all ended with normal completion summaries, Windows-style file links, and some Codex app directives such as ::git-stage, ::git-commit, or ::git-push. However, searching same-day Desktop logs shows thread/goal/get failures also occur on other conversation ids whose final assistant message did not contain git directives. So the app directives may be an additional UI stressor, but they do not appear to be a necessary trigger.

Current hypothesis from local evidence:

1. Primary suspect: Desktop attempts thread/goal/get during history open/resume even when the goals feature is disabled, and that failure is not fully non-blocking for the UI hydration path.
2. Secondary suspect: Windows cwd normalization between \\?\D:\... and D:\... may affect workspace/local task recovery.
3. Secondary suspect: resume state may incorrectly mark already-completed turns as streaming (latestTurnStatus=completed markedStreaming=true), leaving the Desktop UI in an inconsistent state.

I have intentionally omitted full logs, local project content, and full filesystem paths from this public comment. The conversation ids and summarized state/log patterns above should hopefully be enough to identify the failing path.

[edwinking81]

Additional reproduction detail from local troubleshooting:

I tried a low-risk local repair on one affected thread (019e3070-b326-73a3-906e-83741ad35972) and then a cloned repair-copy thread. Neither made the conversation open successfully.

What was tried, sanitized:

1. Normalized the affected thread's SQLite cwd from the Windows native namespace form (\\?\D:\...) to the normal drive path form (D:\...).

   • After attempting to open the thread again, Codex Desktop rewrote the SQLite cwd back to the \\?\D:\... form.
   • The open failure still reproduced.

2. Created a repair-copy thread with a fresh conversation id (019e30dc-94bc-7087-b97b-83865db6df4e):

   • Copied the rollout JSONL.
   • Replaced the old conversation id in the copied rollout.
   • Inserted a new row in threads.
   • Copied thread_dynamic_tools rows.
   • Added a new session_index.jsonl entry.
   • Verified SQLite integrity and JSONL parse success.
   • The cloned thread still failed with the same log pattern.

The repair-copy failure suggests the issue is not only the original conversation id, missing index entry, or a corrupt rollout file.

Important UI behavior observed by the user:

• Clicking/opening one of these affected conversations can make other normally-openable conversations fail to open in the same Desktop window/session.
• Clicking the UI retry button restores the ability to open those otherwise-healthy conversations.
• The originally affected conversation still fails after retry.

This makes the issue look like a global Desktop window / AppServerConnection / renderer hydration state leak triggered by the affected thread.

The repeated log pattern remains:

thread/read OK
thread/resume OK
thread/goal/get -> -32600 goals feature is disabled
Failed to hydrate thread goal after resume
maybe_resume_success ... latestTurnStatus=completed markedStreaming=true

The latestTurnStatus=completed markedStreaming=true combination appears especially relevant: the thread's latest turn is complete, but Desktop still marks the resumed thread as streaming. That stale streaming state may be leaking to the current window/session and blocking hydration of other threads until the retry path resets it.

Still omitting full logs and local project paths/content from this public issue.

[edwinking81]

Additional correlation from local diagnostics, sanitized:

I originally suspected this might be related to the Codex GitHub plugin, so I uninstalled/disabled that plugin. There is still a GitHub installed app/integration entry on the account, but the failure continues to reproduce. The stronger local correlation now appears to be with Codex Desktop executing git commit itself, not merely with GitHub/plugin usage.

Sample comparison:

Affected conversations that fail to reopen:

• 7/7 affected samples contain at least one actual Codex tool call running git commit.
• Counts of actual git commit tool calls in those affected samples: 1, 1, 4, 26, 6, 3, 4.
• The same affected samples also contain assistant final/app directives such as ::git-stage{...} and ::git-commit{...}; one also contains ::git-push{...}.
• One affected sample did not have a git directive in the final visible assistant message, but it did have earlier Codex-executed git commit calls and earlier ::git-commit directives in the rollout.

Unaffected conversations that still reopen normally:

• 3/3 control samples contain zero actual Codex tool calls running git commit.
• They may mention commits, inspect git state, or contain commit text from logs/docs, but no Codex-executed git commit tool call and no assistant ::git-commit{...} app directive.

Other notes:

• git status alone does not seem sufficient to trigger the problem.
• Textual mentions of commits do not seem sufficient to trigger it.
• The common splitter in my local samples is: Codex Desktop actually runs git commit, then the saved conversation includes Codex git app directives (::git-stage, ::git-commit, sometimes ::git-push).
• Hypothesis: the persisted git action/directive state is not replay/hydrated idempotently when reopening history. A bad conversation may then leave the current Desktop window in a poisoned state where other conversations fail to open until the UI Retry button is clicked; Retry clears the global effect for healthy conversations, but the original affected conversation still cannot be opened.

This makes the current workaround clear: avoid letting Codex Desktop execute git commit; let it prepare the command/message, and run the commit manually outside Codex until this is fixed.

[etraut-openai]

We've issued a hotfix to address this. Please update to the latest version.