codex - 💡(How to fix) Fix Codex App: Goal setting fails immediately, including /goal clear, likely due to thread resume parsing older rollout metadata

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App version: 26.519

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 Pro x64

What issue are you seeing?

The Codex App fails to set or clear goals. Any /goal command fails immediately with the UI toast message:

"Doel instellen mislukt"

This happens even with a minimal harmless test goal and also with /goal clear.

I asked Codex to inspect its own local app state and logs. The analysis suggests this is not caused by my project, prompt length, or local project settings. The app sends thread/goal/get and then thread/goal/set requests, but the goal is not persisted.

Codex found a local goal database at:

C:\Users<REDACTED>.codex\goals_1.sqlite

The database contains a thread_goals table, but the table remained empty after the failed goal attempts.

The strongest clue is that thread/resume fails shortly before the goal operation with:

failed to parse rollout line: unknown variant 'thread_name_updated'

Codex also found older rollout files containing this event type, for example:

rollout-2026-04-30T22-51-03-019de028-cdd0-7513-8c5f-353a4dc3a173.jsonl rollout-2026-05-06T10-16-14-019dfc5b-e7c8-7412-a189-9b32b478dd43.jsonl

In config.toml, Codex did not find a feature flag disabling goals.

My conclusion is that this looks like a Codex Desktop compatibility bug when resuming older thread history. The app appears to stumble on the older thread_name_updated rollout event, and the goal path fails before anything is written to the goal database.

<img width="301" height="99" alt="Image" src="https://github.com/user-attachments/assets/812adb51-a948-4c22-8810-0231b079f7c4" />

What steps can reproduce the bug?

1. Open Codex App on Windows.
2. Open an existing thread with older history.
3. Try to set any goal, for example:

/goal Test goal mode.

1. Codex immediately shows the UI toast:

"Doel instellen mislukt"

1. Try clearing goals with:

/goal clear

1. The same error appears again.
2. Try a longer realistic goal prompt. The same error appears.
3. Ask Codex to inspect local logs and state.
4. Logs show thread/goal/get and thread/goal/set requests being sent.
5. The local goals_1.sqlite database exists and contains a thread_goals table, but no successful persisted goal appears.
6. Shortly before the goal failure, thread/resume fails with:

failed to parse rollout line: unknown variant 'thread_name_updated'

1. The affected older rollout files contain a thread_name_updated event.

What is the expected behavior?

Codex should be able to set, get, and clear goals successfully.

For example:

/goal Test goal mode.

should create or update the active goal for the current thread.

Also:

/goal clear

should clear the active goal or report that no goal exists, instead of failing with the same "failed to set goal" style UI error.

If older rollout metadata contains an unknown event such as thread_name_updated, Codex should either ignore that event, migrate the rollout format, or show a clear recovery message. It should not break the goal feature for the thread.

Additional information

This issue does not appear to be related to prompt length or the content of the goal.

I first tried a detailed project goal, then a very short harmless test goal, and finally /goal clear. All failed with the same UI toast.

A minimal example that fails:

/goal Test goal mode.

Another command that also fails:

/goal clear

Codex local analysis summary:

• The UI sends thread/goal/get and thread/goal/set.
• A local SQLite goal store exists: C:\Users<REDACTED>.codex\goals_1.sqlite
• The thread_goals table exists but remains empty after the failed attempt.
• thread/resume fails shortly before the goal request with: failed to parse rollout line: unknown variant 'thread_name_updated'
• Older rollout files contain that event type.
• No config.toml feature flag was found that disables goals.

This looks like a compatibility or migration bug around older thread history / rollout metadata. A safe fallback might be to ignore unknown rollout event variants during thread resume, or migrate older rollout records before goal operations run.

I can provide screenshots and sanitized log snippets if useful.