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:...@db.example.com/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.