[Bug]: Codex ChatGPT connection fails on Windows without Developer Mode: shadow home symlinks fail with EPERM#14325

Triage

Confirmed on v0.0.44 (451afcb). Nothing after that commit touches this path, and there is no open PR.

Managed ChatGPT instances use an auth-overlay shadow home (CodexManagedHome.ts: any instance id other than codex gets providers/codex/<id>/shadow). materializeCodexShadowHome then symlinks every non-private entry of ~/.codex into that directory, including the known directories it creates itself (sessions, sqlite, skills, and the rest). ensureSymlink calls Effect's FileSystem.symlink, which has no Windows link-type argument and ends up as fs.symlink with no type. On Windows that is a real symlink, so a normal user without Developer Mode gets EPERM. The status check catches that and replaces it with "Could not check Codex right now," which matches the trace (sessions → refreshSnapshot). The built-in CLI provider (instanceId === "codex") stays in direct mode and does not hit this.

Developer Mode only has to stay on because the entry list is rebuilt from readDirectory on every refresh. A new file such as ..codex-global-state.json.bak.tmp-* is not in PRIVATE_ENTRY_NAMES or SHADOW_LOCAL_ENTRY_NAMES, so one unprivileged create fails the whole provider check. #14321 is the same sign-in flow, but it is the model catalog, not this.

Junctions, as in antigravityAuthSupport.ts, cover directories only, and they have to go through node:fs because Effect cannot pass "junction". Files still need a link, and a hard link or copy is not a symlink: the next refresh's readLink returns EINVAL, readLinkState treats that as NotSymlink, and config.toml (anything outside mcp-oauth-locks) fails with CodexShadowHomeEntryConflictError. Skipping transient *.tmp-* names, or not failing the check when an unknown entry cannot be linked, is still required for the recurrence.

Still reproduces on 0.0.46-nightly.20261005.2702 (Windows 11 Pro 10.0.26200, standard non-elevated user, codex-cli 0.160.1). The "ChatGPT - Personal" managed instance showed "Authenticated as … · ChatGPT · Could not check Codex right now." The server trace had the same CodexShadowHomeFileSystemError / EPERM on ~\.codex\sessions (14 times), and the shadow directory stayed empty.

Notes for anyone else hitting this:

• The Developer Mode toggle moved and may not persist. On 25H2 it's under Settings → System → Advanced → For developers (ms-settings:developers). On this machine, turning the toggle on did not create HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock at all, and symlink creation still failed. Setting the value directly from an elevated shell worked:

  1	reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /t REG_DWORD /f /v AllowDevelopmentWithoutDevLicense /d 1

  After restarting T3 Code, the shadow home was populated with symlinks, the EPERM errors stopped, and the provider check passed.
• Workaround without Developer Mode: the built-in codex instance (direct mode, uses the CLI's own codex login) does not build a shadow home and works without symlink privileges.
• To confirm you have this bug and not #14333, look for EPERM: operation not permitted, symlink in ~\.t3\userdata\logs\server.trace.ndjson.

I did enable Developer Mode in Windows and it's working properly

If anyone here wants a workaround

Rechecked on 2026-10-26: still present in 0.1.2 (latest release), nightly 0.1.3-nightly.20261026.3717 and main (0712398). The link code is unchanged, and the regression tests in #22573 still fail against main.

Following the close note on #15277, I opened a smaller fix: #22573. On Windows only, a directory falls back to a junction when Windows refuses the symlink, and an entry that cannot be linked is skipped instead of failing the check. It changes one source file plus tests. I verified it on Windows 11 with Developer Mode off, including Connect with ChatGPT and a thread running end to end; details are in the PR.

One trade-off needs a maintainer call: without Developer Mode, top-level files such as config.toml and AGENTS.md are not shared into managed accounts.

_{Written by Claude Code (Claude Opus 5.5) on behalf of @braziliansalsa, via t3 triage.}

Fresh triage: this is a reported Windows compatibility bug, not a reported exploitable vulnerability.

Inspected the server source on Linux at 07d38b8. CodexHomeLayout.ensureSymlink still calls FileSystem.symlink(target, link) without a Windows link type; materializeCodexShadowHome still rebuilds shared entries on refresh while keeping auth.json private. This is source inspection, not a Windows runtime reproduction: this host cannot run the reported Windows 11 desktop/Developer Mode sequence.

Leaving this open for maintainer handling. Changing the managed account's credential-isolating shadow-home materialization falls under the triage flow's protected-surface stop. The existing proposed fix also needs a decision on which shared files remain available without Developer Mode.

Rechecked on 2026-10-29: this recurred on nightly 0.1.4-nightly.20261029.3853 via PR #26286 ("Codex shadow homes share thread writer locks with the main home", merged 2026-10-28T04:58:30Z), which added thread-writer-locks to KNOWN_SHARED_DIRECTORIES — the same ensureSymlink → fileSystem.symlink(target, link) path this issue already tracks, with no Windows link-type argument.

Environment: Windows 11 Pro 10.0.26300 x64, standard (non-admin) user, T3 desktop app, codex-cli 0.165.0-alpha.1.2 bundled runtime.

Observed error (T3 provider status UI):

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\AllowDevelopmentWithoutDevLicense did not exist at all on this machine (Developer Mode had never been turned on). Creating it and enabling Developer Mode unblocked a fresh symlink creation immediately (verified in a new session without any T3/app restart), confirming this is the same EPERM-without-privilege cause already diagnosed here.

Additional evidence for the proposed junction-fallback fix (#22573): on this exact shadow home, fsutil reparsepoint query shows every pre-existing shared entry (cache, logs, mcp-oauth-locks, sessions, etc.) is a directory junction (IO_REPARSE_TAG_MOUNT_POINT), while the new thread-writer-locks link that failed and was later created is a true NTFS symlink (IO_REPARSE_TAG_SYMLINK). A junction-on-Windows fallback for directory entries, as #22573 proposes, would have avoided this recurrence entirely.

Workaround applied: enabled Windows Developer Mode; provider recovered.

Confirming the same recurrence on 0.1.8-nightly.20261106.4262 (c55db3e9c7), Windows 11, standard non-admin user, Developer Mode never enabled.

It is exactly the #26286 case, and nothing else. shadow\thread-writer-locks is the only entry that needed a link. The ten pre-existing shared entries (archived_sessions, cache, logs, mcp-oauth-locks, plugins, sessions, shell_snapshots, skills, sqlite, worktrees) are all already junctions on this machine (fsutil reparsepoint query → tag 0xa0000003), so they never exercised the privilege. Only the newly added thread-writer-locks went through the real-symlink path, and it failed every refresh:

182 failed materializeCodexShadowHome spans in the retained trace, from 14:27:30Z to 16:14:54Z, roughly one a minute for the whole window. The provider showed as unavailable and sessions launched during it failed to start.

The file is unchanged on main. apps/server/src/provider/Drivers/CodexHomeLayout.ts at c55db3e9c7 is byte-identical to main at 6577c6b6 (sha256 A946F1940EC378B8002A9DFA2365081ACC01601D8E244523CD90D36D4A23C41B): ensureSymlink still calls FileSystem.symlink(target, link) with no link type, and thread-writer-locks is still in KNOWN_SHARED_DIRECTORIES. This is live on main today, not only in the nightlies that were reported.

Repair, and what it says about #22573. Creating the missing link by hand recovered the provider on the next refresh:

materializeCodexShadowHome succeeded at 16:15:54Z, with no restart, and has succeeded 16 times since (latest 16:31:45Z). fs.readlinkSync returns the absolute target T3 compares against, so a junction satisfies readLinkState and the target comparison here. That means the directory half of #22573 is sufficient for this entry; the "skip unlinkable entries" half is not needed for it, though it is still needed for top-level files such as config.toml.

One asymmetry worth knowing for the fix: older builds made the pre-existing entries as junctions, this build tried a true symlink for the new one, so a single shadow home can end up with both link kinds. Both pass the readLink comparison — that is the state on disk here now, and nothing objects to it.

The trigger is structural rather than a fluke, though: any future addition to KNOWN_SHARED_DIRECTORIES, or any refresh that has to link an entry the shared home did not have before, fails on an unprivileged Windows account until someone with admin rights creates the link by hand.

_{Written with an AI assistant (OpenCode) on behalf of @grenmango51.}