[Bug]: New Codex runtime entries can disable existing shadow-home providers

Summary

T3's Codex shadow-home setup only links entries that already exist in the shared home when materialization runs. If a later Codex update creates a new top-level runtime entry in both the shared and shadow homes, the next materialization rejects the shadow copy and disables the provider.

Codex 0.147 introduced queue_1.sqlite, which triggers this today. The same failure can recur when Codex adds another home entry.

Reproduction

1. Configure the documented multi-account layout: one shared homePath and another account using that homePath plus a separate shadowHomePath.
2. Start with no queue_1.sqlite in either home and let T3 materialize the shadow home.
3. Run Codex 0.147 against both effective homes. Codex creates a regular queue database in each.
4. Refresh provider status or restart T3.

The shadow-home provider becomes disabled:

Driver 'codex' failed to create instance: Cannot create Codex shadow home entry 'queue_1.sqlite' because '<shadow-home>/queue_1.sqlite' already exists and is not a symlink.

A minimal unit repro is to create regular sharedHome/queue_1.sqlite and shadowHome/queue_1.sqlite files, then call materializeCodexShadowHome(layout).

Why it happens

T3 lists the current shared-home entries, then ensureSymlink rejects any existing regular shadow entry. There is no recovery path; the conflict becomes a provider creation error.

Codex added the queue DB in openai/codex@b87981a. In the affected installation, the shared DB and two shadow DBs were automatically created within six seconds, confirming this was runtime-created state rather than a copied home.

Expected behavior

Codex upgrades that add runtime entries should not disable existing shadow-home providers. T3 should reconcile ownership safely or offer a targeted recovery path without silently deleting user data.

Acceptance criteria

• New Codex home entries created after an earlier materialization do not leave providers disabled.
• The solution is resilient to future filenames rather than only adding queue_1.sqlite to an allowlist.
• Existing data is preserved; SQLite families such as the base DB, WAL, and SHM are handled together.
• Tests cover creation between materialization passes and an existing regular shadow entry.

Environment

• T3 main at 1a003e383ac6b10258b8100c2617d938c4f06c69
• Codex CLI 0.147.0
• macOS 26.5.2, Apple Silicon

Workaround

With related processes stopped, backing up and removing the shadow queue_1.sqlite, queue_1.sqlite-wal, and queue_1.sqlite-shm files allows T3 to create the shared link. This is manual, potentially data-destructive, and does not address future Codex entries.

Start in apps/server/src/provider/Drivers/CodexHomeLayout.ts, reading materializeCodexShadowHome and ensureSymlink at the referenced lines. Reproduce the issue with regular queue_1.sqlite files in sharedHome and shadowHome, then add unit coverage for entries created between materialization passes and existing regular shadow entries. Done means future runtime-created entries are reconciled without disabling providers or losing SQLite-related data.