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:
- Create a shared SQLite database with a corresponding symlink in a shadow home.
- Place regular
-shm and -wal files in the shadow home, with corresponding entries in the shared home.
- 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.
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
-shmand-walfiles 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.2787Environment
0.161.0Steps 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:
-shmand-walfiles in the shadow home, with corresponding entries in the shared home.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:
Inspection found that the base SQLite databases were symlinks to the shared home, while some
-shmand-walfiles were regular files in the shadow homes. Some WAL files were nonempty.The installed
materializeCodexShadowHomeimplementation attempts to link shared-home entries, andensureSymlinkrejects 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_homeexplicitly 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.