Repository navigation
Codex Desktop Chronicle memory-writer drops App sqlite home when spawning codex exec --ignore-user-config #29953
Description
Summary
Codex Desktop's Chronicle memory-writer can write SQLite state to a different home than the main Codex App runtime.
The main Desktop/App runtime uses the App-managed SQLite home:
$HOME/.codex/sqlite
But a Chronicle memory-writer child process is launched through codex exec with:
--ephemeral --ignore-user-config --ignore-rules --sandbox read-only
When that child does not receive the App-resolved SQLite home through environment/config, it falls back to the top-level legacy SQLite path:
$HOME/.codex
This recreates top-level SQLite files such as:
$HOME/.codex/state_5.sqlite*
$HOME/.codex/logs_2.sqlite*
$HOME/.codex/goals_1.sqlite*
$HOME/.codex/memories_1.sqlite*
while the main App continues to use:
$HOME/.codex/sqlite/state_5.sqlite
$HOME/.codex/sqlite/logs_2.sqlite
$HOME/.codex/sqlite/goals_1.sqlite
$HOME/.codex/sqlite/memories_1.sqlite
This can leave the Desktop runtime with two SQLite homes and divergent thread/state inventory.
Important non-goal
This is not the same issue as the TRACE/WAL high-frequency logging problem in logs_2.sqlite.
This report is specifically about Desktop/Chronicle child processes losing the App-managed SQLite home when spawning codex exec --ignore-user-config.
Local evidence
Environment:
Codex CLI: 0.142.1
Codex Desktop bundled CLI: 0.142.0
CODEX_HOME=$HOME/.codex
App-managed SQLite home=$HOME/.codex/sqlite
With the App/runtime environment present:
codex doctor --jsonreports:
config.load.sqlite home = $HOME/.codex/sqlite
state.paths.sqlite home = $HOME/.codex/sqlite
state.paths.state DB = $HOME/.codex/sqlite/state_5.sqlite
state.paths.log DB = $HOME/.codex/sqlite/logs_2.sqlite
state.rollout_db_parity = ok
But when simulating a Desktop child process that does not inherit the App-managed SQLite home:
env -u CODEX_SQLITE_HOME codex doctor --jsonCodex CLI 0.142.1 reports:
config.load.sqlite home = $HOME/.codex
state.paths.sqlite home = $HOME/.codex
state.paths.state DB = $HOME/.codex/state_5.sqlite
state.paths.log DB = $HOME/.codex/logs_2.sqlite
state.rollout_db_parity = warning
This also recreates top-level SQLite files under $HOME/.codex/*.sqlite*.
Earlier local process-level evidence with Chronicle enabled showed the same shape: the main Codex App runtime opened only $HOME/.codex/sqlite/*.sqlite, while a codex_chronicle memory-writer child opened $HOME/.codex/*.sqlite.
The Chronicle child command shape included:
codex exec --json --skip-git-repo-check --ephemeral --ignore-user-config --ignore-rules --sandbox read-only ...
CODEX_SQLITE_HOME is honored even when --ignore-user-config is present. When the child process receives:
CODEX_SQLITE_HOME=$HOME/.codex/sqlite
the top-level SQLite files are not recreated.
Expected behavior
All internal Codex Desktop helper processes should use the same App-resolved SQLite home as the main Desktop/App runtime.
For Desktop-spawned internal helpers, --ignore-user-config should still ignore user config.toml and user rules, but it should not cause the helper to fall back to a different SQLite home than the one already selected by the App runtime.
Actual behavior
A Chronicle memory-writer helper launched through codex exec --ignore-user-config can fall back to $HOME/.codex as its SQLite home unless CODEX_SQLITE_HOME is present in its process environment.
That creates or updates a second SQLite home at the top level, separate from the main App SQLite home at $HOME/.codex/sqlite.
Workaround
A local workaround is to set the GUI launchd environment before starting Codex Desktop:
launchctl setenv CODEX_SQLITE_HOME "$HOME/.codex/sqlite"or to use a small LaunchAgent that sets the same value at login.
Disabling Chronicle also avoids the observed memory-writer path, but it does not fix the underlying App child-process environment/config propagation issue.
Proposed fixes
Option 1: Minimal Desktop/Chronicle fix
When Chronicle/app-server spawns the memory-writer codex exec child, explicitly pass the App-resolved runtime paths:
CODEX_HOME=$HOME/.codex
CODEX_SQLITE_HOME=$HOME/.codex/sqlite
or the equivalent resolved paths for that installation.
This is the smallest fix because CODEX_SQLITE_HOME is already honored by codex exec, including when --ignore-user-config is present.
Option 2: Structural App-managed runtime config fix
Separate App-managed runtime state from user config.
--ignore-user-config should continue to ignore user config.toml, user rules, and other user customizations, but Desktop internal helpers should still receive the App-managed SQLite home selected by the parent runtime.
For example, the Desktop parent could pass an explicit runtime config/env layer, or pass an explicit SQLite-home override when spawning internal helpers.
Related issue
This appears related in shape to Desktop-spawned subprocesses missing Codex environment variables:
The issue here is specifically Chronicle/memory-writer plus SQLite home divergence.
Activity
github-actions commentedon Jun 25, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zengzheqing commentedon Jun 25, 2026
Thanks for the duplicate suggestions. I reviewed both suggested issues, and I do not think this issue should be closed as a duplicate.
Requesting human maintainer triage here because this is a distinct Chronicle /
codex exec/ sqlite-home divergence path, even though it is related to the broader Desktop child-process environment propagation family.Why this is not a duplicate of #28479
#28479 is related at the Desktop/app-server child-process environment layer, but it is specifically about the Computer Use MCP process (
SkyComputerUseClient mcp) missingCODEX_HOME/CODEX_SQLITE_HOME, producingTransport closed/ app-server bridge failures.This issue is not about Computer Use, MCP startup, or
SkyComputerUseClient. The repro path here is Chronicle's memory-writer launching:When that internal Chronicle helper does not receive the App-managed sqlite home, it falls back to
$HOME/.codexand recreates top-level SQLite files while the main Desktop runtime continues using$HOME/.codex/sqlite.So the shared layer may be "Desktop-spawned helpers must receive App-managed runtime env", but the affected component, command path, user-visible state corruption risk, and minimal fix target are different.
Why this is not a duplicate of #28343
#28343 is about archived chat deletion showing a success toast while archived local state remains. It may show a related two-state-DB symptom, but the product path is different: archived-chat deletion UI/state management.
This issue is specifically about Chronicle/memory-writer creating or updating a second SQLite home because
codex exec --ignore-user-configloses the App-resolved sqlite home.Maintainer request
Please keep this open unless there is already a tracking issue that specifically covers Chronicle/memory-writer or
codex exec --ignore-user-configlosing Desktop/App-managed sqlite home.If maintainers prefer a broader tracking issue, I think the right parent would be something like:
The key distinction is that
--ignore-user-configcan keep ignoring userconfig.toml/ rules, but Desktop internal helpers should not silently fall back to a different SQLite home than the parent App runtime.Also, to avoid confusion: I am treating the GitHub Actions comment only as an automated duplicate suggestion, not as maintainer triage. The labels on this issue appear to have been applied separately from that duplicate suggestion.
boombx403-byte commentedon Aug 18, 2026
Hi @zengzheqing, I'm testing a local-first, read-only diagnostic tool (Codex Rescue Alpha5) against local session persistence and rollout anomalies. It evaluates schema compatibility, tool correlation, and state consistency without modifying the original rollout or SQLite databases.
If the affected session is still present locally, you can run:
No raw data is needed; please redact any private repository paths before sharing results.