fix(server): keep new Codex SQLite state shadow-local

[matsvarn]

Problem

Codex can add a top-level SQLite runtime database after a shadow home was first materialized. If Codex creates regular copies in both homes, the next materialization rejects the shadow copy and disables that provider.

Root cause

The home layout treated each shared-home entry separately. It had no ownership rule for a new SQLite base file and its WAL and SHM sidecars.

Fix

Treat each top-level .sqlite base name, -wal, and -shm sidecar as one family. A regular shadow database keeps the complete family local. Both homes retain their files, and repeated materialization stays idempotent. Unrelated regular-file conflicts still return the existing typed error.

Tests

• Added a regression that materializes once, creates queue_1.sqlite, WAL, and SHM files in both homes, then materializes twice.
• Added a future SQLite filename case and verified missing shadow sidecars do not become shared links.
• Extended the unrelated-file conflict test to prove both copies remain unchanged and the layout can recover after the conflict is removed.
• Focused test: 9 passed.
• Focused format and lint: passed.
• Server typecheck: passed with no errors.

The regression test fails on the pinned base with CodexShadowHomeEntryConflictError for queue_1.sqlite.

Risks

Low. The rule applies only to top-level SQLite families whose shadow base is already a regular entry. It removes only family symlinks when local ownership is selected. Shared targets and regular files remain unchanged. Non-SQLite conflict behavior is unchanged.

Release note

Codex shadow-home providers no longer disable when new SQLite runtime databases appear.

Fixes #5817

Checklist

• This PR is small and focused
• I explained what changed and why
• UI screenshots are not applicable
• Animation or interaction video is not applicable

Implemented with GPT 5.6 Sol via Codex.

Note

Preserve shadow-local SQLite file families in materializeCodexShadowHome

• When Codex creates a new SQLite database in the shadow home between materialization passes, materializeCodexShadowHome now detects the base .sqlite file as a real (non-symlink) file and marks the entire family (base, -wal, -shm) as local.
• Any existing symlinks for the family are removed, and symlink creation is skipped for all family members, keeping the shadow-local database intact.
• Adds a sqliteFamilyBaseName helper in CodexHomeLayout.ts that strips -wal/-shm suffixes to resolve the base name of a SQLite file family.
• removePrivateSymlink is renamed to removeSymlink with generalized parameter naming to support both auth and SQLite family entries.

^{Macroscope summarized 979c487.}

---

Note

Low Risk
Scoped to auth-overlay shadow homes when a shadow .sqlite base is already a regular file; only removes symlinks for that family and leaves non-SQLite conflict behavior unchanged.

Overview
Codex shadow-home materialization no longer fails when Codex adds a top-level SQLite runtime database (and WAL/SHM sidecars) in the shadow home after the first pass.

materializeCodexShadowHome now treats each top-level *.sqlite name plus -wal and -shm as one SQLite family. If the shadow base file is already a real file (not a symlink), the whole family stays shadow-local: existing family symlinks are removed and symlink creation is skipped for those entries, while shared-home copies are untouched. Unrelated real-file conflicts (e.g. config.toml) still raise CodexShadowHomeEntryConflictError.

Adds regression coverage for inter-pass SQLite creation, partial sidecars, and recovery after a non-SQLite conflict; removePrivateSymlink is renamed to removeSymlink for reuse.

^{Reviewed by Cursor Bugbot for commit 979c487. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. 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: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5063c145-fb0d-49af-8cb3-659dd42de657

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.}

[macroscopeapp]

Approvability

Verdict: Approved 979c487

Straightforward bug fix that prevents SQLite state files created in the shadow home from being incorrectly replaced with symlinks. The change is well-scoped to one file with comprehensive test coverage demonstrating the fix.

^{You can customize Macroscope's approvability policy. Learn more.}

[FredericDierenBescherming]

Please merge this, its annoying af.
(for now i have a script cleaning them up every T3 start)

[t3dotgg]

Note

🤖 GPT-6 Astra (preview) responding on behalf of Theo

This was closed as part of an automated cleanup pass. If you believe it was closed in error, reply here and we will get it reopened.

Closing as a duplicate of #9229, the retained Codex SQLite-home fix. It uses the shared SQLite home and removes stale SQLite symlinks while preserving real files. This branch's repeated-setup and unrelated-conflict cases are recorded there. Review continues in that PR, so this is not a claim that the fix has shipped.

[ElliotDrel]

This is still hitting me repeatedly on a shared-home + shadow-home dual-account setup (Windows). Three separate occurrences so far:

1. goals_1.sqlite-shm
2. thread_history_1.sqlite-shm / thread_history_1.sqlite-wal
3. Most recently, state_5.sqlite itself — the base database file, not just a WAL/SHM sidecar:

   Driver 'codex' failed to create instance: Cannot create Codex shadow home entry 'state_5.sqlite' because 'C:\Users\...\.codex_mom\state_5.sqlite' already exists and is not a symlink.
   

Each time, the workaround is purging everything in the shadow home except auth.json and re-enabling the provider to force rematerialization. That's manageable but recurring every few days, and the base-file case (not just -wal/-shm) suggests the family-detection logic may need to also cover the case where the base .sqlite itself is the one that lands as a regular file first, before its sidecars exist. Happy to share the full shadow-home directory listing at failure time if useful for the fix.