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

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

• #22969
• #22971
• #21659

Powered by Codex Action

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.

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.

1. 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.

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.

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