0.133.0-alpha.1 migration drops existing live goals without backfill
What version of Codex CLI is running?
Old live TUI process: codex-cli 0.132.0-alpha.1
New process after update: codex-cli 0.133.0-alpha.1
What subscription do you have?
ChatGPT Pro
Which model were you using?
gpt-5.5 high
What platform is your computer?
Darwin 25.2.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Ghostty 1.3.1, no multiplexer.
Codex doctor report
Current 0.133.0-alpha.1 install reports overallStatus: ok.
{
"overallStatus": "ok",
"codexVersion": "0.133.0-alpha.1",
"checks": {
"installation": { "status": "ok" },
"config.load": {
"status": "ok",
"details": {
"feature flag overrides": "memories=true, mentions_v2=true, goals=true, prevent_idle_sleep=true"
}
},
"state.paths": {
"status": "ok",
"details": {
"state DB integrity": "ok",
"log DB integrity": "ok",
"goals DB integrity": "ok"
}
}
}
}
What issue are you seeing?
A /goal session started in 0.132.0-alpha.1 stores its active goal in state_5.sqlite.thread_goals.
After updating to 0.133.0-alpha.1 and starting a new Codex process against the same CODEX_HOME, the newer process applies migration 34 and drops state_5.sqlite.thread_goals.
The old TUI remains open and still shows Pursuing goal, but /goal fails:
■ Failed to read thread goal: thread/goal/get failed in TUI
What steps can reproduce the bug?
I reproduced this with isolated temp HOME, CODEX_HOME, npm prefix, and npm cache.
ROOT=/tmp/codex-goal-db-transition
rm -rf "$ROOT"
mkdir -p "$ROOT"/{home,codex-home,npm-prefix,npm-cache,work}
cp ~/.codex/auth.json "$ROOT/codex-home/auth.json"
cp ~/.codex/config.toml "$ROOT/codex-home/config.toml"
chmod 600 "$ROOT/codex-home/auth.json"
HOME="$ROOT/home" \
CODEX_HOME="$ROOT/codex-home" \
npm_config_prefix="$ROOT/npm-prefix" \
npm_config_cache="$ROOT/npm-cache" \
npm install -g @openai/codex@0.132.0-alpha.1
HOME="$ROOT/home" \
CODEX_HOME="$ROOT/codex-home" \
"$ROOT/npm-prefix/bin/codex" --no-alt-screen -C "$ROOT/work"
In the old TUI:
/goal db transition check
Interrupt the first turn with Esc, leaving the old TUI open and the goal active.
Before updating, the active goal row is in state_5.sqlite.thread_goals:
sqlite3 "$ROOT/codex-home/state_5.sqlite" ".tables"
sqlite3 -header -column "$ROOT/codex-home/state_5.sqlite" \
"select thread_id, objective, status, tokens_used, time_used_seconds from thread_goals"
Observed:
thread_id objective status tokens_used time_used_seconds
------------------------------------ ------------------- ------ ----------- -----------------
019e472e-8fe3-78e1-969a-b8db7e9c8b5a db transition check active 0 5
Then update the isolated install and start a new process against the same CODEX_HOME:
HOME="$ROOT/home" \
CODEX_HOME="$ROOT/codex-home" \
npm_config_prefix="$ROOT/npm-prefix" \
npm_config_cache="$ROOT/npm-cache" \
npm install -g @openai/codex@alpha
HOME="$ROOT/home" \
CODEX_HOME="$ROOT/codex-home" \
"$ROOT/npm-prefix/bin/codex" --no-alt-screen -C "$ROOT/work"
After the new TUI initializes, migration 34 is applied:
sqlite3 -header -column "$ROOT/codex-home/state_5.sqlite" \
"select version, description, success from _sqlx_migrations order by version desc limit 4"
Observed:
version description success
------- ---------------------------- -------
34 drop thread goals 1
33 thread goal stopped statuses 1
32 threads preview 1
31 drop device key bindings 1
The new goals DB exists, but the prior active goal row is not present:
sqlite3 "$ROOT/codex-home/goals_1.sqlite" ".tables"
sqlite3 -header -column "$ROOT/codex-home/goals_1.sqlite" \
"select thread_id, objective, status, tokens_used, time_used_seconds from thread_goals"
Observed:
_sqlx_migrations thread_goals
# no rows
Return to the old still-running 0.132.0-alpha.1 TUI and run:
/goal
Observed:
■ Failed to read thread goal: thread/goal/get failed in TUI
What is the expected behavior?
Existing goal rows should survive the goals_1.sqlite split.
A newer process should not make an already-running older goal session unable to read, clear, or complete its active goal.
Additional information
Likely related to #23300, feat: dedicated goal DB.
That PR:
- creates
goals_1.sqlite - creates
goals_migrations/0001_thread_goals.sql - applies
state/migrations/0034_drop_thread_goals.sql - notes that there is intentionally no backfill for existing goal rows
Related but not exact duplicates:
- #20841: same user-facing
thread/goal/get failed in TUI, closed as SQLite state/log DB issue - #20598: goal set/get failures
- #23340: long-running
/goallog growth and loop behavior
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗