WAL does stop corruption, but codex's lock handling is the shaky part, since it sets busy_timeout to 5000 and doesn't retry SQLITE_BUSY. issues 20213 and 35555 seem to show that under concurrent use, and 35555 was still open as of august. the journal_mode stall in 35704 only involves one process, so I'd treat it as a side note
unquoting the pattern inside excluded should make state_*.sqlite match and survive schema bumps, so test that on a scratch copy first.
keep each DB with its wal and shm files in the same folder. and check with sqlite3 whether unified history is in state_5.sqlite, because if it is, excluding the DBs loses most of the benefit
Thanks, you're right. WAL supports concurrent access, but depending on how Codex handles locking, running multiple instances at the same time can lead to startup failures or temporary hangs.
In my case, I switch to another account when one runs out of usage. Since I don't run both instances at the same time, I haven't encountered these issues so far. They could occur if you run both simultaneously.
I've updated the post to clarify this. Thanks for pointing it out!
OnlineProxy
WAL does stop corruption, but codex's lock handling is the shaky part, since it sets busy_timeout to 5000 and doesn't retry SQLITE_BUSY. issues 20213 and 35555 seem to show that under concurrent use, and 35555 was still open as of august. the journal_mode stall in 35704 only involves one process, so I'd treat it as a side note
unquoting the pattern inside excluded should make state_*.sqlite match and survive schema bumps, so test that on a scratch copy first. keep each DB with its wal and shm files in the same folder. and check with sqlite3 whether unified history is in state_5.sqlite, because if it is, excluding the DBs loses most of the benefit