Repository navigation
Keep the Codex state database on compute-local disk - #877
Merged
Merged
Conversation
Codex opens its SQLite databases on every app-server start. Under the hosted state directory, which lives on NFS workspace storage, a new Codex Session's native_prepare took 1.48-1.74 s on mx (n=5); with CODEX_SQLITE_HOME under the Runtime home on the VM's own disk it took 0.38-0.44 s (n=5). Nothing the Session needs is lost when the compute is replaced: Codex rebuilds the thread index and history views from the rollouts in CODEX_HOME and reads dynamic tools from the rollout, and goals, whose state lives only in SQLite, are disabled.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every Codex app-server start opens its SQLite databases (thread index, history projection, logs and others) from
CODEX_SQLITE_HOME, which defaults toCODEX_HOME. On hosted placementsCODEX_HOMEsits in the state directory on NFS workspace storage, so a new Codex Session spent about 1.1 s just opening them.The adapter now points
CODEX_SQLITE_HOMEat the Session's directory under the Runtime home on the compute's own disk.CODEX_HOME, with the rollouts, config and native history, stays in the state directory. The variable is added to the tool environment's skip list next toCODEX_HOME, and the Codex Runtime guide states the placement and its reason.Measured on mx (microsandbox on NFS, MiniMax-M2.7, n=5 each),
executor native_preparefor a new Codex Session:CODEX_HOMEon NFS)Why compute replacement loses nothing the Session needs:
thread/queue/*API, which the adapter does not call.Live check on mx: a Codex Session remembered a code word. Then, inside its VM, its SQLite directory was emptied and the app-server killed. The next Turn started a new executor, which recreated the databases. It resumed the same rollout and answered with the code word. A plain suspend and resume keeps the VM's memory and disk, so it never reaches this path.
Verification on mx, from a checkout bundle of this tree: hosted acceptance 9/9 for Codex and 9/9 for Claude Code. Locally,
go vetandgo testpass forapps/daemon/internal/agent/codexandapps/daemon/internal/dispatch.Need help on this PR? Tag
@codesmith-botwith what you need.