Codex Desktop Chronicle memory-writer drops App sqlite home when spawning codex exec --ignore-user-config

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 --json

reports:

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 --json

Codex 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:

• https://github.com/openai/codex/issues/28479

The issue here is specifically Chronicle/memory-writer plus SQLite home divergence.