Skip to content

on mac after codex update： Codex cannot access its local database. #24006

Open
Open
on mac after codex update： Codex cannot access its local database.#24006
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

Description

@garrettXu
garrettXu
opened on May 22, 2026

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

it conn't open

What subscription do you have?

pro

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Codex cannot access its local database.
The app cannot finish launching until its SQLite database is accessible.

Database path: Path unavailable in app-server startup error

Close other Codex applications, then click Retry to check whether access has been restored.

Error: (code=1, signal=null).
Most recent error: Error: failed to initialize sqlite state runtime under /Users/xxx/.codex: failed to initialize state runtime at /Users/xxxx/.codex: error returned from database: (code: 11) database disk image is malformed

What steps can reproduce the bug?

when i update use app, it cann't work

What is the expected behavior?

No response

Additional information

No response

Activity

  1. garrettXu
    added
    appIssues related to the Codex desktop app
    on May 22, 2026
  2. github-actions
    added
    bugSomething isn't working
    app-serverIssues involving app server protocol or interfaces
    on May 22, 2026

  3. github-actions commented on May 22, 2026

    @github-actions
    github-actionsBot
    on May 22, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. Toolenaar commented on May 22, 2026

    @Toolenaar
    Toolenaar
    on May 22, 2026

    Same Issue a simple reinstall does not fix it. Anyone have a fix ?

  5. rbbp23 commented on May 22, 2026

    @rbbp23
    rbbp23
    on May 22, 2026

    Same issue here... I tried renaming logs_2.sqlite like people said in the other tickets, but no luck. I can't start de app anymore.

  6. pioneerLEE commented on May 23, 2026

    @pioneerLEE
    pioneerLEE
    on May 23, 2026

    Same issue here too

  7. olaaroub commented on May 26, 2026

    @olaaroub
    olaaroub
    on May 26, 2026

    I got the same issue today, did anyone fix it?

  8. FeVeR-Store commented on May 26, 2026

    @FeVeR-Store
    FeVeR-Store
    on May 26, 2026

    Renaming state_5.sqlite had the effect.

  9. jiahao-oai commented on May 29, 2026

    @jiahao-oai
    jiahao-oai
    on May 29, 2026

    You can fix it by

    mv ~/.codex/state_5.sqlite ~/.codex/state_2.sqlite

  10. inRush commented on Jun 1, 2026

    @inRush
    inRush
    on Jun 1, 2026

    You can use codex cli to start it again, codex cli will automatically fix this problem

  11. valentina-di-vincenzo commented on Jun 1, 2026

    @valentina-di-vincenzo
    valentina-di-vincenzo
    on Jun 1, 2026

    Same issue here after an update. Renaming worked.

  12. neverforgit commented on Jun 4, 2026

    @neverforgit
    neverforgit
    on Jun 4, 2026

    You can use codex cli to start it again, codex cli will automatically fix this problem

    I did not have the ~/.codex/state_*.sqlite files present, so that does not work.

    But @inRush's solution worked for me. Thank you!

    System: macOS 26.5 arm64

  13. wangskyone commented on Jun 18, 2026

    @wangskyone
    wangskyone
    on Jun 18, 2026

    Workaround: reset Codex SQLite state

    I ran into an issue where Codex could no longer open, and the root cause appeared to be related to its local SQLite state files.

    The workaround that fixed it for me was:

    1. Find all .sqlite files under any .codex directory.
    2. Rename those .sqlite files to keep them as backups, for example:
    file.sqlite -> file.sqlite.bak
    1. Restart Codex and let it generate fresh SQLite database files automatically.

    After doing this, Codex was able to start normally again.

    Note that this may reset some local Codex state, but the original SQLite files are still preserved as .bak backups in case they are needed later.

  14. aliyovic commented on Jun 19, 2026

    @aliyovic
    aliyovic
    on Jun 19, 2026

    i asked Codex Cli to fix it :

    What fixed it was not just renaming the .sqlite files. The missing piece was that Codex’s recovery flow expected this
    directory to exist:

    ~/.codex/db-backups

    In your case it did not exist, so “Back Up and Rebuild” failed with:

    Recovery failed: ENOENT: no such file or directory, mkdir 'db-backups'

    Here’s the exact summary you can post:

    I was able to fix this by manually creating Codex’s missing backup directory and moving the active SQLite database
    files out of the way.

    The error dialog said Codex could not access its local SQLite database, and the recovery step failed with:

    Recovery failed: ENOENT: no such file or directory, mkdir 'db-backups'

    What worked:

    mkdir -p ~/.codex/db-backups/manual-backup

find ~/.codex ~/.codex/sqlite -maxdepth 1 -type f \
  \( -name '*.sqlite' -o -name '*.sqlite-wal' -o -name '*.sqlite-shm' \) \
  -exec mv {} ~/.codex/db-backups/manual-backup/ \;

Then I clicked Retry / restarted Codex, and Codex recreated fresh SQLite files automatically.

Notes:

- I backed up the files instead of deleting them.
- Moving only .sqlite files was not enough because SQLite also had -wal and -shm sidecar files.
- The key extra fix was creating ~/.codex/db-backups, because Codex’s built-in recovery was failing when that
  directory was missing.


One caveat: the simple command above flattens files from `~/.codex/sqlite` into the same backup folder. What I
actually ran preserved the `sqlite/` subfolder too, but for most users the simpler version is probably enough unless
there are filename collisions.

  15. quinpeer commented on Jun 22, 2026

    @quinpeer
    quinpeer
    on Jun 22, 2026

    Claude fixed my issue:

    The dialog was misleading — your database was never actually corrupt (integrity_check and quick_check both returned ok). The real problem was a crash-looping process stack: a background codex app-server daemon and a codex-aar helper kept dying and respawning, each grabbing a lock on state_5.sqlite, so every relaunch failed to initialize the sqlite runtime. The in-app "Back Up and Rebuild" button couldn't help because it had its own bug (ENOENT … mkdir 'db-backups' — it tries to create that folder from a working directory that no longer exists).

    What I did:

    • Killed the entire Codex.app process tree.
    • Confirmed all databases were released.
    • Folded the stray large write-ahead log back into logs_2.sqlite (wal_checkpoint(TRUNCATE)), verified integrity.
    • Relaunched Codex — the app-server is now stable and got all the way past DB init into normal network operation. No more sqlite/db-backups errors in the log.

  16. simontomkins commented on Jul 6, 2026

    @simontomkins
    simontomkins
    on Jul 6, 2026

    Fully close the app, then in the terminal run

    pkill -f Codex
pkill -f codex

    Then try restarting the app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions