Failed to read thread goal: thread/goal/get failed in TUI

[txtttx]

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

pro 5x

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.1.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

cursor

What issue are you seeing?

■ Failed to read thread goal: thread/goal/get failed in TUI

What steps can reproduce the bug?

Uploaded thread: 019debd9-2372-7f23-92b9-9f34002a6355

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• Setting a goal is not working with Failed to set thread goal: thread/goal/set failed in TUI #20598

Powered by Codex Action

[txtttx]

@etraut-openai Thanks for the suggestion. I tried to move state_5.sqlite to state_5.sqlite_backup and let it rebuild. But it doesn't help

[etraut-openai]

OK, thanks for trying. I'm investigating your logs (thanks for uploading!) and that's hinting at a problem with the logs_2.sqlite file.

[txtttx]

OK, thanks for trying. I'm investigating your logs (thanks for uploading!) and that's hinting at a problem with the logs_2.sqlite file.

Thanks for the suggestion. I moved logs_2.sqlite to backup. Codex can start up much faster, but I still hit the TUI bug.

New thread ID: 019debf3-7108-78c1-97af-8b3dfdb48951

[etraut-openai]

Did you move all of the logs_2 files including the logs_2.sqlite-wal and logs_2.sqlite-shm sidecars? The latest log you uploaded hints at having inconsistent db state. Try moving all of those files to backup.

[txtttx]

Did you move all of the logs_2 files including the logs_2.sqlite-wal and logs_2.sqlite-shm sidecars? The latest log you uploaded hints at having inconsistent db state. Try moving all of those files to backup.

Thanks it resolved the issue. For whoever hit this problem, I moved logs_2.sqlite* and state_5.sqlite* to backup folders.

[Dhi13man]

Additional 0.130.0 Linux signal

Confirming the same failure still occurs on Linux with codex-cli 0.130.0 and
goals experimental true.

The useful reproducer was:

codex app-server --listen off

That exposed the underlying init failure:

failed to initialize sqlite state db: failed to initialize state runtime at ~/.codex: migration 1 was previously applied but has been modified

Local isolation:

• Moving only state_5.sqlite* did not clear the migration error.
• Moving logs_2.sqlite* too cleared the state runtime failure.
• backfill_state.status = complete
• Current thread exists in threads
• PRAGMA integrity_check returned ok for the recreated state and logs DBs
• Goal reads stopped failing after the TUI was restarted

Failure mapping:

flowchart TD
    Start([TUI starts]) --> Init[Init StateRuntime]
    Init --> StateDb[Open state_5.sqlite]
    StateDb --> LogsDb[Open logs_2.sqlite]
    LogsDb --> Check{Migration checksum valid?}
    Check -->|No| NoHandle[State handle missing]
    NoHandle --> GoalGet[Call thread goal get]
    GoalGet --> Error[Show goal read failure]
    Check -->|Yes| Backfill[Backfill sessions]
    Backfill --> Goals[Goal reads work]

Loading

I do not see the exact app-server init signal above, so adding it here. The confusing part is that
the TUI points at thread/goal/get, while the actionable failure is state runtime initialization. In
this case, the blocking DB was logs_2.sqlite*, not only state_5.sqlite*.

Suggested product-side fix: surface the state-runtime migration error in the TUI, include the failing
DB name, and document recovery for both state_5.sqlite* and logs_2.sqlite*, including -wal and
-shm sidecars.