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

I can confirm this issue on Windows, with an additional sidecar-only variant that may be relevant to the proposed fix in #7201.

Environment

• T3 Code Nightly: 0.0.34-nightly.20260820.1141
• Codex CLI: 0.148.0
• OS: Windows 11 Pro, version 10.0.26200, x64
• Provider setup: two Codex provider instances using one shared home and a separate shadow home for the second account
• Authentication: ChatGPT subscription authentication
• The default Codex provider remains usable, but the shadow-home provider is disabled

Sanitized configuration:

Observed behavior

This has recurred across several recent T3 Code Nightly and Codex updates.

On startup or provider refresh, the secondary Codex provider is disabled during materializeCodexShadowHome. T3 encounters a regular SQLite runtime sidecar in the shadow home where it expects a symbolic link, then aborts provider creation.

Exact error

The corresponding server trace reports:

Previous occurrences on the same machine failed on other members of the same class of runtime files:

Because materialization stops at the first conflict, the filename displayed by T3 does not represent the complete set of conflicting entries.

Shadow-home state at failure time

A complete inspection of the shadow-home root found eight regular SQLite sidecar files:

The problem was therefore not limited to queue_1.sqlite.

Importantly, the corresponding base database entries were still symbolic links to the shared Codex home:

In this occurrence, the divergence was specifically:

This is slightly different from the original #5817 reproduction, where the shadow base database itself is described as becoming a regular file.

Recurrence evidence

Retained local logs show repeated failures on at least two consecutive days:

• August 19: repeated provider-creation failures on memories_1.sqlite-shm
• August 20: repeated provider-creation failures on logs_2.sqlite-shm
• An earlier retained error also references queue_1.sqlite

The problem has returned after multiple manual recoveries and subsequent updates or restarts. It is not an isolated stale file left by a single interrupted process.

Different SQLite families become affected at different times. Some sidecars already existed from the previous day, while others were created or rewritten during the next T3/Codex run.

Impact

• The complete secondary Codex provider is marked disabled.
• Provider creation fails before the account can be used.
• The provider remains unavailable across refreshes and restarts.
• The first conflicting filename changes between occurrences.
• Removing only the filename shown in the UI is insufficient because additional regular sidecars may remain.
• The default provider and shared Codex home continue to work.
• The secondary account authentication file remains valid.
• The failure occurs during shadow-home materialization, before normal provider use.

Recovery confirmation

For diagnostic purposes, I backed up and moved all eight regular *.sqlite-wal and *.sqlite-shm files out of the shadow home. I did not modify the private auth.json or models_cache.json files.

I then disabled and re-enabled only the affected provider instance.

After rematerialization:

This immediately restored the provider, confirming that the regular SQLite sidecars directly caused provider creation to fail.

However, the same class of conflict has returned after later updates or runs, so this procedure is only a temporary recovery.

Relation to PR #7201

PR #7201 appears to target the same underlying class of failure:

https://github.com/pingdotgg/t3code/pull/7201

Its stated goal—keeping newly created Codex SQLite state shadow-local and treating a base database plus its WAL/SHM sidecars as one family—matches the recurring behavior observed here.

However, my captured state includes a sidecar-only divergence: the shadow base .sqlite entry remained a symbolic link while its -wal and -shm entries were regular files.

The PR description and diff appear to select shadow-local ownership when the shadow base database is already a regular file. I cannot confirm whether it also covers the observed case where only the WAL/SHM members have become regular files.

This Windows reproduction may therefore be useful for validating #7201 against both forms:

1. A regular shadow base database plus its sidecars.
2. A symlinked shadow base database with regular shadow WAL/SHM sidecars.

I am not proposing a separate implementation here. I am documenting the additional observed state so that the existing fix can be evaluated against the complete failure mode.

Adding updated Windows findings here as requested when #17005 was closed as a duplicate.

Environment

• Windows, T3 Code desktop
• T3 Code: 0.0.46-nightly.20261007.2787
• Codex CLI: 0.161.0
• Multiple Codex provider instances sharing a Codex home, with separate shadow homes for authentication

Observed failure

Three Codex providers failed to initialize with this sanitized error:

Inspection confirmed the sidecar-only state already described in this issue: base SQLite databases were symlinks to the shared home, while some -shm and -wal files were regular files in the shadow homes. Some WAL files were nonempty.

In the installed build, materializeCodexShadowHome attempts to link shared-home entries, and ensureSymlink rejects these existing regular files. The initial creation of the conflicting files was not captured; no fresh-install reproduction or repository regression test was run.

Workaround and verification

The conflicting files were backed up and moved out of the shadow homes, allowing T3 to recreate the links. Each affected provider's launch arguments were also configured to set sqlite_home explicitly to the shared Codex directory.

After T3 reloaded the settings, all three provider connection probes succeeded. No regular SQLite sidecar conflicts remained at that check. Long-term recurrence has not yet been tested.

This confirms the failure on the versions above and records the observed recovery. It is not a recommendation to delete SQLite sidecars or a claim that a permanent upstream fix has been verified. Related shared-directory approach: #9229.

Another entry for this issue, from Codex 0.161.0: cloud-config-bundle-cache.json. This one should not be linked, either.

Environment

• T3 Code: 0.0.46-nightly.20261007.2774 (desktop)
• Codex CLI: 0.161.0
• macOS 27.0.1, Apple Silicon
• Two Codex accounts: the default ~/.codex, and a second instance with shadowHomePath set to ~/.codex-t3/work

What happened

After a T3 restart, the second instance showed only "Disabled" in Settings → Providers, with its toggle still on. Its status cache had stopped updating at the restart. The settings were unchanged.

cloud-config-bundle-cache.json existed as a regular file in both the shared home and the shadow home. In the installed build, PRIVATE_ENTRY_NAMES is auth.json and models_cache.json, so materializeCodexShadowHome tries to link this file and ensureSymlink rejects the regular copy. I did not find the error text in the server trace. I am going by the file state and the code.

Why linking is the wrong fix for this file

The file is per-account. It holds chatgpt_user_id, account_id, and the workspace's signed enterprise config_toml and requirements_toml, with a one-hour expiry. If it were shared, one account could pick up another account's workspace policy. It belongs with auth.json and models_cache.json.

Linking also does not last. I deleted the shadow copy and turned the provider off and on. The provider came back, but within seconds there was a regular file in the shadow home again, and the shared copy had not changed. So the next restart would disable the provider again.

Workaround

A small job deletes the shadow copy every two minutes, so a restart does not find one. Codex fetches the bundle again when it needs it. This only matters until the file is treated as private.

Suggested fix

Add cloud-config-bundle-cache.json to PRIVATE_ENTRY_NAMES. This is a narrower case than the fix this issue asks for. The general fix should also not default to linking: a new per-account file is safer kept local than shared.

Windows reproduction: split WAL files can lose committed writes

Adding a data-loss reproduction for the sidecar-only variant already described here.

Environment: Windows 11 x64 (10.0.26200), T3 Code Nightly 0.0.46-nightly.20261013.3040, Codex CLI 0.162.1, Node 24.14.0. Two Codex accounts were configured with a shared home and a shadow home.

In addition to provider-creation conflicts (db-backups in this installation), archived Codex databases failed SQLite integrity checks. Codex's retained logs explicitly reported corruption in thread_history_1.sqlite. The precise historical corruption timing was not captured, so the fixture below establishes a reproducible unsafe write mechanism rather than proving the origin of every damaged page.

Reproduction

A fixture invoking T3's actual materializeCodexShadowHome implementation from the installed server reproduced this sequence:

1. Create and close a WAL-mode SQLite database in the shared home. At materialization time its -wal and -shm files do not exist.
2. Materialize the shadow. T3 links the base database, but there are no sidecars to link.
3. Open the shared database and commit a row, keeping that connection open.
4. Open the same physical database through the shadow path and commit a different row.
5. Close both connections and reopen the shared database.

Both inserts succeed, but only one of the two committed rows remains. The shadow connection uses its own regular WAL/SHM files for the linked base database. This does not require overlapping transactions, a crash, an authentication failure, or model inference.

Here is a standalone Node reproduction of the resulting file layout. Run as an .mjs file on Windows with file-symlink support. It uses only a fresh temporary directory:

Observed: the assertion fails with 1 !== 2. The same write check with two independent physical provider databases retains both writes. The actual-T3 fixture also retained 1/2 with the shadow layout and 2/2 with independent homes.

The relevant main-branch code still enumerates only entries currently present in the shared home: CodexHomeLayout.ts. SQLite explains why multiple names and separate journals/WAL files are unsafe.

An acceptance test should cover a linked base database whose sidecars were absent during materialization, then verify both committed writes survive. Handling an existing regular sidecar conflict alone would not establish database safety. Independent direct homes were used as the local workaround, preserving the account credentials and available rollouts; this does not claim to preserve the intended ongoing shared-history behavior of shadow homes.

Reproduction and diagnosis assisted by GPT-6.1-Sol in Codex desktop.

Follow-up to my earlier report: the providers became unavailable again on Windows, but this time with a different shadow-home failure mode.

Environment

• T3 Code: 0.0.46-nightly.20261013.3066 (desktop, Nightly)
• Codex CLI: 0.162.1 (verified with the CLI configured in T3)
• Windows 11 Pro 25H2, build 26200.9457, x64
• Three enabled Codex account instances sharing one homePath (<user-home>/.codex), each with a separate shadowHomePath (<t3-userdata>/providers/codex/<account-instance>/shadow). Paths and account identifiers are placeholders.
• All three instances retained an explicit sqlite_home override pointing to the shared Codex directory, with cli_auth_credentials_store="file".

New findings

• The explicit sqlite_home override pointing to the shared Codex directory was still configured on all three affected providers.
• The initial failure was a CodexShadowHomeFileSystemError wrapping EPERM: operation not permitted, symlink. T3 attempted to link a newly present, non-runtime configuration backup from the shared home into each shadow home. That single file blocked initialization of all three providers.
• Unlike the earlier regular-file conflicts, inspection found no conflicting regular shadow entries at that point; the required links were missing.
• After relocating the backup outside the mirrored directory and reloading the providers, two authenticated successfully. The remaining provider then failed to create links for memories_1.sqlite-shm and memories_1.sqlite-wal.
• A direct attempt to create those missing links without administrator privileges returned Windows error 1314: a required privilege is not held by the client. Creating only those two links with administrator permission and reloading the remaining provider restored it.

Verification and implication

All three affected providers subsequently showed Authenticated in T3, and the provider connection probes succeeded. The backup was preserved with its contents verified unchanged.

The sqlite_home override alone did not prevent T3's shadow-home initialization from requiring links for SQLite sidecars and other shared-home entries. This is a related Windows link-creation/permissions failure, distinct from the existing regular-file conflict reported earlier. It may warrant separate tracking at maintainers' discretion.

This was a local recovery, not a verified permanent fix. No database-integrity testing was performed, and I am not claiming data loss or corruption in this installation. Personal paths, account details, and identifiers are omitted.

Follow-up: this recurred on newer versions after the previous successful repair.

Environment

• T3 Code: 0.1.1-nightly.20261019.3373 (desktop, Nightly)
• Codex CLI: 0.163.0
• Windows, x64
• Three enabled Codex account instances sharing one Codex home, each with a separate shadow home. Account names, identifiers, and personal paths are omitted.
• All three still had an explicit sqlite_home override pointing to the shared Codex directory.

Observed recurrence

All three providers failed shadow-home initialization on goals_1.sqlite-shm, with CodexShadowHomeEntryConflictError reporting that the entry already existed and was not a symlink.

Inspection found 12 regular SQLite sidecar files across the three shadow homes:

• goals_1.sqlite-shm and goals_1.sqlite-wal in all three.
• thread_history_1.sqlite-shm and thread_history_1.sqlite-wal in two.
• memories_1.sqlite-shm and memories_1.sqlite-wal in the remaining one.

The two regular thread-history WAL files were nonempty: 4,152,992 and 4,144,752 bytes. Links for the shared project-metadata-locks directory were also missing in all three shadow homes, but this directory was not established as a failure trigger; initialization failed on the SQLite conflict first.

Recovery verification

The repair preserved the 12 regular sidecar files, restored 19 conflicting or missing links in total, and reloaded the affected providers. Subsequent shadow-home initialization and provider connection probes succeeded. A follow-up filesystem inspection found no remaining regular SQLite sidecar conflicts or missing shared-entry links at that check.

This confirms recurrence after an earlier successful link repair, with the explicit shared sqlite_home configuration still present. It does not establish when or why each sidecar became a regular file, nor prove that the override was honored by every database operation. Restoring the links remains a recovery workaround, not a verified permanent fix.

No database-integrity testing was performed, and no data loss or corruption is claimed for this installation. No raw logs, credentials, or account identifiers are attached.

Triage inspected current main at b5a226e49c and all six comments. Runtime reproduction was not performed. The general reconciliation requested here changes which files the multi-account authentication overlay shares versus keeps private; the reported per-account cloud configuration cache makes that boundary material. This reaches the automated triage rule requiring maintainer review for authentication/credential changes. Leaving this issue open for Julius; no fix or data migration was attempted.

Reproduced on Linux with Codex 0.163.0 and main 3b95e7831b. Started the real dev server with disposable shared/shadow Codex homes and two provider instances. Initial materialization succeeded; Codex created regular runtime entries in both homes. After restarting, shadow provider creation failed with CodexShadowHomeEntryConflictError on the first conflicting entry, .tmp. Both homes also contain regular queue_1.sqlite databases. No account credentials were required for this reproduction.

Windows data from three machines on 0.1.2-nightly.20261022.3541 (same commit as v0.1.2), Codex CLI 0.163.0. This adds two things to the thread. The first is the mechanism that keeps recreating the regular sidecars. The second is a reproduction showing that keeping the regular sidecars in place, which is what #23472 does, loses committed writes on Windows.

Exact error (Limerence, Windows 11, 2026-10-22T20:59:20Z, after a T3 restart)

The same machine failed on goals_1.sqlite-shm after the restart at 19:15Z. The instance was down from 20:59:18Z to 21:04:07Z. Every T3 restart kills Codex and can cause this, so a setup that restarts T3 after each update hits it repeatedly.

Files found in the shadow home. In every case the base <db>.sqlite was a link into ~/.codex and the sidecars were regular files:

Why the files keep coming back

• Linux: SQLite's unix VFS resolves the symlink before naming -wal/-shm, so the sidecars land next to the real database. I tested this with node:sqlite (SQLite 3.53.1): no regular files appear in the shadow home and no writes are lost. The sidecar-only variant therefore occurs on Windows only.
• Windows: the win32 VFS names the sidecars from the path it was given (SQLite 3.50.4 and 3.53.4 tested).
  • If T3 materialized while the shared home had no <db>-wal/-shm, nothing is linked, and Codex creates regular sidecars in the shadow home. From then on its writes go to its own WAL. Two committed rows leave one row in the shared DB, which reproduces the 2026-10-13 comment above.
  • If the sidecar links do exist, they survive a killed process. But when the shadow Codex is the last connection and closes cleanly, SQLite deletes -wal/-shm by the shadow path. That removes T3's links, not the files they point to. The next open from the shadow creates regular files again. This explains the sidecar links disappearing between restarts.

Keeping the regular sidecars (#23472) loses newer writes

Below is a standalone node:sqlite script using a fresh temp dir. On Windows it uses a file symlink, as T3 does. On Linux a hard link gives the same SQLite file naming.

Output on Linux (hard link; node 24.18, SQLite 3.53.1):

Output on Windows (file symlink):

The 4152-byte shadow WAL (a 32-byte header plus one frame) holds one committed transaction. The process that wrote it was killed before checkpointing. Afterwards, the main Codex commits and closes cleanly. When the shadow opens the database again, SQLite recovers its own stale WAL, and the next checkpoint writes those pages over the newer ones. integrity_check still reports ok, so the loss is silent. Two other options are also unsafe. Replacing the regular sidecars with links drops the shadow's unapplied commits. Checkpointing the shadow WAL first is safe only if the real database has not changed since that WAL began.

What we run locally until this is fixed: a pre-launch sweep, run before T3 starts.

1. For each regular shadow sidecar beside a linked database, it counts committed frames on scratch copies.
2. If there are none, it moves the files.
3. If there are some, it applies them through the shadow path only when that provably adds rows: the real DB has no unapplied WAL frames of its own, and "real DB + shadow WAL" passes integrity_check and still contains every row of the real DB.
4. Otherwise it moves the files aside without applying them and flags the rows.
5. It also moves away a shared <db>-wal whose links were deleted, if every frame in it is already in the database. Otherwise the next open would replay it over newer pages.

None of this addresses the root cause. On Windows the shadow-home Codex should probably not open shared SQLite databases through a link at all. Opening them by their real path, for example through Codex's sqlite_home or CODEX_SQLITE_HOME pointing at the shared home, would give one WAL and one lock table per database. An earlier comment reports sidecars returning even with sqlite_home set, so that would need checking against the Codex version T3 runs.

Related, but a different failure point: #24486.

This tracker covers the materializeCodexShadowHome conflict — a regular shadow entry disabling that instance. #24486 covers what happens when materialization succeeds anyway: the SQLite base file is shared while -wal/-shm stay shadow-local, so the database is corrupted and the default codex provider (no shadow home) is the one that ends up failing with Codex App Server process exited with code 1 / os error 32, on a rebuild loop.

Relevant to this issue's acceptance criterion "SQLite families such as the base DB, WAL, and SHM are handled together": the implementation that addressed it here, #19861, was closed on 2026-10-19 without merging, so that criterion currently has nothing in flight.

Worth keeping distinct because an allowlist or self-heal change satisfies this tracker while leaving the WAL split intact — verified locally on 0.1.3-nightly.20261023.3553: with every conflicting shadow entry treated as replaceable, codex-2/codex-3 report ready and no CodexShadowHomeEntryConflictError is logged, while state_5.sqlite keeps being rebuilt into db-backups\sqlite-* every few minutes.

I saw the same shadow-home conflict with memories.lock.

Environment: T3 Code Desktop 0.1.4-nightly.20261028.3824, local server on macOS arm64, Codex CLI 0.165.0.

Observed: A secondary Codex provider was disabled because memories.lock existed as a regular file in both the shared home and the shadow home. Both files were empty. T3 reported that the shadow entry existed and was not a symlink.

Source: At commit eb751fa0730d6a51d56547cb7fcaf4822a7e0e3b, shadow-home setup treats memories as local, but does not classify memories.lock as local or replaceable. It attempts to link the shared entry and rejects the regular shadow file.

Workaround confirmed: Moved the shadow lock file aside, then disabled and enabled the provider. The provider returned.