codex - 💡(How to fix) Fix Codex App 0.135.0 goal migration drops state_5.thread_goals but runtime still queries it

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

0.135.0

What subscription do you have?

plus

What platform is your computer?

No response

What issue are you seeing?

What happened

After updating Codex CLI/App to 0.135.0, the Goal feature became unusable. The UI shows “Unable to set goal”, and goal-related runtime paths log SQLite errors:

error returned from database: (code: 1) no such table: thread_goals

Restarting the app does not fix it.

Evidence

state_5.sqlite migrations show:

• version 29: thread goals, installed on 2026-04-28
• version 33: thread goal stopped statuses, installed on 2026-05-31 06:33:55
• version 34: drop thread goals, installed on 2026-05-31 06:33:55

At the same timestamp, goals_1.sqlite was created with:

• version 1: thread goals, installed on 2026-05-31 06:33:55

But goals_1.sqlite.thread_goals was empty.

Runtime logs continued to show code reading from a DB/schema where thread_goals no longer exists:

• codex_core::goals: failed to read thread goal at turn start
• codex_core::goals: failed to read thread goal for continuation
• codex_app_server::request_processors::thread_lifecycle: failed to read thread goal for resume snapshot

All with:

no such table: thread_goals

Expected behavior

After migration, all goal read/write paths should use the new goal store, or the migration should preserve a compatibility table/view until all runtime paths are updated.

Actual behavior

The migration drops state_5.sqlite.thread_goals, creates goals_1.sqlite.thread_goals, but runtime code still attempts to read thread_goals from the old location. As a result, setting or reading goals fails.

Local workaround tested

After backing up the local Codex state files, manually recreating an empty compatibility table in state_5.sqlite restored get_goal from throwing an error; it now returns goal: null.

This suggests the runtime still expects state_5.sqlite.thread_goals to exist.

What steps can reproduce the bug?

What happened

After updating Codex CLI/App to 0.135.0, the Goal feature became unusable. The UI shows “Unable to set goal”, and goal-related runtime paths log SQLite errors:

error returned from database: (code: 1) no such table: thread_goals

Restarting the app does not fix it.

Evidence

state_5.sqlite migrations show:

• version 29: thread goals, installed on 2026-04-28
• version 33: thread goal stopped statuses, installed on 2026-05-31 06:33:55
• version 34: drop thread goals, installed on 2026-05-31 06:33:55

At the same timestamp, goals_1.sqlite was created with:

• version 1: thread goals, installed on 2026-05-31 06:33:55

But goals_1.sqlite.thread_goals was empty.

Runtime logs continued to show code reading from a DB/schema where thread_goals no longer exists:

• codex_core::goals: failed to read thread goal at turn start
• codex_core::goals: failed to read thread goal for continuation
• codex_app_server::request_processors::thread_lifecycle: failed to read thread goal for resume snapshot

All with:

no such table: thread_goals

Expected behavior

After migration, all goal read/write paths should use the new goal store, or the migration should preserve a compatibility table/view until all runtime paths are updated.

Actual behavior

The migration drops state_5.sqlite.thread_goals, creates goals_1.sqlite.thread_goals, but runtime code still attempts to read thread_goals from the old location. As a result, setting or reading goals fails.

Local workaround tested

After backing up the local Codex state files, manually recreating an empty compatibility table in state_5.sqlite restored get_goal from throwing an error; it now returns goal: null.

This suggests the runtime still expects state_5.sqlite.thread_goals to exist.

What is the expected behavior?

No response

Additional information

No response