Another file that hits this: .codex-global-state.json.
Setup: T3 Code (Nightly) 0.1.7-nightly.20261102.4093, Linux (Arch), codex-cli 0.166.0, a second Codex instance with a T3-managed shadow home.
What happened: the provider went to Disabled with:
| 1 | Driver 'codex' failed to create instance: Cannot create Codex shadow home entry '.codex-global-state.json' |
| 2 | because '~/.t3/userdata/providers/codex/<id>/shadow/.codex-global-state.json' already exists and is not a symlink. |
Codex saves this file by writing ..codex-global-state.json.tmp-<ms>-<uuid> and renaming it over the path, so the rename replaced the link with a regular file. .codex-global-state.json.bak was replaced the same way. The shadow copy was newer than the shared one and had every key the shared copy had, plus 12 more entries under electron-persisted-atom-state.
On #23472: as I read it, that PR keeps the provider enabled here, but the shadow home then keeps its own .codex-global-state.json for good. So after the first save, this file quietly stops being shared between accounts. Two options that avoid both the failure and the silent fork:
- If the file is meant to be shared: reconcile instead of failing. Keep the newer copy in the shared home, back up the other one, and restore the link. That gives the same result as a working link (last writer wins).
- If it's meant to be per-account: add it to
PRIVATE_ENTRY_NAMES, likemodels_cache.json, so that's explicit.
Workaround in the meantime: I'm running a small inotify watcher that does the reconcile-and-relink step for regular files that exist in both homes. It skips SQLite files and directories. Happy to share it if useful.