0.133.0-alpha.1 migration drops existing live goals without backfill

Resolved 💬 1 comment Opened May 20, 2026 by ghost Closed May 20, 2026

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 /goal log growth and loop behavior

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗