codex - 💡(How to fix) Fix Make Codex state storage backend configurable beyond SQLite

What variant of Codex are you using?

CLI

What feature would you like to see?

Please consider making Codex's persistent state/log storage backend configurable, instead of hard-coding SQLite-only runtime state.

Today Codex exposes sqlite_home, which helps relocate SQLite files, but it does not solve cases where multiple Codex instances need to share the same state across machines or cluster nodes. In those environments, ~/.codex / $CODEX_HOME is often placed on a shared filesystem, and multiple Codex processes may run concurrently on different hosts. SQLite/WAL semantics on shared filesystems can become a bottleneck or a correctness/reliability risk under concurrent writers.

A useful design would be a pluggable storage backend, for example:

[state]
backend = "sqlite" # default, current behavior

[state.sqlite]
path = "/local/scratch/$USER/codex-state"

# Optional future backend
[state.postgres]
url = "postgres://codex:[email protected]/codex"
pool_size = 10

The goal is not necessarily to remove SQLite. SQLite should remain the default for single-machine/local-first use. The request is to allow an optional server-grade backend, such as PostgreSQL, for users running Codex across multiple nodes, shared workstations, remote dev boxes, or managed enterprise environments.

Why this helps:

• safe concurrent writers across nodes
• central state for shared/remote Codex usage
• better operational tooling: backups, retention, vacuuming, monitoring
• configurable connection pooling and durability behavior
• cleaner enterprise deployment where home directories are network-mounted

This request is related to, but broader than, several SQLite-specific reliability/performance issues:

• #20213 — multi-terminal Codex CLI freezes due to SQLite lock contention
• #16270 — state/log SQLite DBs growing unboundedly and causing write lock contention
• #22444 — logs SQLite WAL growth and stale processes keeping large deleted WAL files open
• #21750 — state SQLite corruption/recovery behavior

Additional information

For now, the workaround is to keep sqlite_home and log_dir on node-local storage instead of a shared filesystem. That avoids many SQLite shared-FS problems, but it also means Codex state is no longer shared across machines. A configurable backend would support both local-first and cluster/enterprise deployments cleanly.