[Bug]: Windows Codex shadow-home providers fail on regular SQLite sidecars beside symlinked databases #17005

Area

apps/server

Summary

Codex shadow-home providers fail to initialize on Windows when SQLite sidecar files are regular files, even though the base databases are symlinks to the shared Codex home.

Related: #5817 and #9229. This report adds an observed Windows sidecar-only case: the base databases were already symlinks, while -shm and -wal files were regular shadow-home files. It may belong under #5817 if maintainers consider it the same underlying issue.

Version or commit

T3 Code desktop: 0.0.46-nightly.20261007.2787

Environment

• Windows
• Codex CLI: 0.161.0
• Multiple Codex provider instances sharing a Codex home, with separate shadow homes for authentication

Steps to reproduce

The failure was observed on an existing installation; the initial creation of the conflicting files was not captured.

A suggested regression test is:

1. Create a shared SQLite database with a corresponding symlink in a shadow home.
2. Place regular -shm and -wal files in the shadow home, with corresponding entries in the shared home.
3. Run shadow-home materialization again.

This test case is derived from the observed filesystem state; it has not been run against the repository's test suite.

Expected behavior

Provider initialization should handle this state safely without disabling the account or discarding database updates.

Actual behavior

Three Codex providers were disabled during initialization with the following error. Local paths have been replaced with placeholders:

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

Inspection found that the 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.

The installed materializeCodexShadowHome implementation attempts to link shared-home entries, and ensureSymlink rejects these existing regular files.

Impact

Blocks use of the affected Codex provider instances until manually resolved.

Workaround and verification

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

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

This is a report of the local workaround and observed recovery, not a recommendation to delete SQLite sidecars or a claim that a permanent upstream fix has been verified.