fix(codex): honor split SQLite state homes

[Ingwannu]

Summary

• resolve Codex SQLite state with the same precedence Codex uses: root sqlite_home in the effective config.toml, then CODEX_SQLITE_HOME, then the effective CODEX_HOME
• make history provider defaults, history jobs, write admission, and native-residue checks address the same call-time state_5.sqlite
• preserve an explicit SQLite home in systemd, launchd, Task Scheduler, and WinSW service artifacts, including Windows drive/UNC paths rendered from non-Windows repair tooling
• document the split-home boundary, backup identity, storage-cleanup non-authority, and decision rationale

Root cause

OpenCodex rebuilt CODEX_HOME/state_5.sqlite independently in several paths. Codex can place SQLite thread state in another root, so a Windows Desktop + WSL installation could make the history writer, admission snapshot, and residue check reason about a database different from the one Codex actually opened.

The fix centralizes one call-time resolver and passes the selected database identity through the existing history job/worker boundary. It deliberately does not give storage cleanup authority over an external SQLite root.

User impact

History migration and provider synchronization now follow the active Codex SQLite database in split-home installations. Background services retain the explicit install-time SQLite destination instead of silently falling back to CODEX_HOME.

Verification

• focused SQLite/history/admission/residue/service tests: 129 passed, 0 failed
• bun run typecheck: passed
• bun run privacy:scan: passed
• docs production build: 221 pages
• focused service/WinSW/SQLite rerun: relevant changed-path coverage passed; one pre-existing codex-shim environment test failed because Bun re-inherited this host's real service token, and the same failure reproduced unchanged on clean origin/dev
• full CPU-limited suite attempt: 10,666 passed, 10 skipped, 13 failed, 2 follow-on errors; it took 753s versus the suite's ~210s idle expectation. Twelve failures were 5-second endpoint/admission timeouts under the constrained/busy run, while the remaining shim failure is the clean-dev reproduction above.
• git diff --check: passed

Closes #1401

[github-actions]

✅ Deterministic PR hygiene checks passed.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 5a316750-597c-4426-9edd-97ec37929a79

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Wibias]

Request changes based on a full review of the current head.

Merge blocker:

resolveCodexSqliteHome() treats every config.toml read/parse failure as if no authoritative sqlite_home existed, then falls through to CODEX_SQLITE_HOME or CODEX_HOME. That is unsafe for the exact data-integrity problem this PR is fixing. ENOENT means the config is absent and fallback is valid; EACCES, EIO, ENOTDIR, or another read failure means OpenCodex does not know which database Codex selected. Falling back in that state can make history/admission/native-residue operations inspect or mutate a stale or unrelated state_5.sqlite.

Please fail closed for unreadable/indeterminate authoritative config while allowing the genuine-missing (ENOENT) case to fall through. Add regressions for at least:

• missing config -> environment fallback is allowed;
• unreadable config (for example EACCES) -> SQLite-home resolution fails closed and no fallback DB is selected.

The overall resolver centralization and service propagation look sound; I did not find a conventional credential or privilege-escalation issue. After the fix, refresh onto current dev and rerun exact-head CI.