`CODEX_HOME` fails to load inside a Windows AppContainer/lowbox — `find_codex_home()`'s `canonicalize()` needs `\GLOBAL??` DOS-drive-letter access the sandbox denies

[yaakovsash1]

Summary

When CODEX_HOME is set and codex runs inside a Windows AppContainer (lowbox token), startup fails with:

WARNING: proceeding, even though we could not create PATH aliases: failed to canonicalize CODEX_HOME "<dir>": Access is denied. (os error 5)
Error loading configuration: failed to canonicalize CODEX_HOME "<dir>": Access is denied. (os error 5)

even though the process can otherwise read and write that same directory. The cause is find_codex_home() calling
PathBuf::from(val).canonicalize() on CODEX_HOME. std::fs::canonicalize on Windows resolves the final path via
GetFinalPathNameByHandleW(..., VOLUME_NAME_DOS), and an AppContainer token cannot resolve the C:\ DOS drive
letter because that requires access to \GLOBAL??\C: (the DosDevices symbolic link in the object namespace), which
lowbox tokens are denied. It is not a filesystem-ACL problem — granting the package/capability SID or ALL APPLICATION PACKAGES on the directory (or the drive root) does not help.

This matters because per-agent isolation on Windows (e.g. running multiple codex instances each confined to its own
CODEX_HOME inside its own AppContainer — the same AppContainer approach OpenAI's own Codex Windows sandbox uses) is
exactly the case that must set CODEX_HOME, and it's the only find_codex_home() branch that canonicalizes.

Root cause (isolated empirically)

Inside an AppContainer, we decomposed what canonicalize does with a native probe on the process's own
(read/writable) directory:

Step	API	Result inside AppContainer
Open the dir	CreateFileW(access=0, FILE_FLAG_BACKUP_SEMANTICS)	OK
Resolve NT path	GetFinalPathNameByHandleW(VOLUME_NAME_NT)	OK (\Device\HarddiskVolumeN\…)
Resolve DOS path	GetFinalPathNameByHandleW(VOLUME_NAME_DOS)	FAIL — Access denied (needs \GLOBAL??\C:)

So the dir open succeeds and NT-path resolution succeeds; only the DOS drive-letter resolution (which
std::fs::canonicalize uses) is denied. Plain std::fs::read/write on the same dir work — they don't do the
\GLOBAL?? resolution, so only canonicalize trips it.

The offending call is codex-rs/core/src/config.rs, find_codex_home():

pub fn find_codex_home() -> std::io::Result<PathBuf> {
    if let Ok(val) = std::env::var("CODEX_HOME") {
        if !val.is_empty() {
            return PathBuf::from(val).canonicalize();   // <-- fails inside an AppContainer
        }
    }
    // ... (the unset branch does not canonicalize)
}

Proposed fix (one-liner, no behavior change on normal setups)

Don't hard-fail on canonicalize; fall back to a pure-string absolutization that opens no handle and does no
\GLOBAL?? resolution. This is the well-established try_canonicalize pattern (used by cargo/rustc for exactly this
class of Windows/sandbox canonicalize unreliability — see rust-lang/rust#79449, cargo#11866, std::path::absolute
rust-lang/rust#91673):

if let Ok(val) = std::env::var("CODEX_HOME") {
    if !val.is_empty() {
        let p = PathBuf::from(val);
        // canonicalize() opens a handle + resolves the DOS drive letter via \GLOBAL??, which a
        // Windows AppContainer/lowbox token is denied. Fall back to a pure-string absolute path
        // (GetFullPathNameW on Windows) so CODEX_HOME works inside a sandbox.
        return p.canonicalize().or_else(|_| std::path::absolute(&p));
    }
}

std::path::absolute (stable since 1.79) is GetFullPathNameW-based on Windows — no directory handle, no object-
namespace lookup — so it succeeds in the AppContainer while remaining a no-op-equivalent for already-absolute paths on
normal setups. (If std::path::absolute isn't desired, dunce::canonicalize or a manual GetFullPathNameW are
equivalents; the key point is: don't require a handle-opening canonicalize on CODEX_HOME.)

Repro (Windows 11)

1. Create an AppContainer profile (CreateAppContainerProfile) → package SID.
2. Make a dir (e.g. C:\codex-home-test) and grant that package SID Full (so the process can read/write it), seed a
   normal ~/.codex into it, set CODEX_HOME to it.
3. Launch codex login status in the AppContainer via CreateProcess + PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES.
4. Observe the failed to canonicalize CODEX_HOME … Access is denied (os error 5) error, despite the process being
   able to read/write the dir. GetFinalPathNameByHandleW(VOLUME_NAME_NT) on the same handle succeeds; VOLUME_NAME_DOS
   fails.

Related

• Ties to the Codex Windows sandbox ACL/Error-5 issues (e.g. v0.107.0 Windows Sandbox ACL Failure (Error 5) and Unintended Permission Pollution on User Home Directory #13378 — the sandbox setup failing to establish drive-root
  access). This is the path-resolution counterpart: even with directory ACLs correct, canonicalize on CODEX_HOME
  fails on the \GLOBAL?? DOS-drive-letter step.

Environment

• Windows 11 (10.0.22631), codex CLI (Rust), running inside a per-agent AppContainer (lowbox token).

[yaakovsash1]

Here's a standalone, self-contained repro (no admin rights, no dependency on codex itself) that reproduces this in a single cargo run --release and also demonstrates the proposed std::path::absolute fallback succeeding in the same AppContainer:

https://gist.github.com/yaakovsash1/818d35ab51fb84aa48a67d37df4f4d09

It creates a throwaway AppContainer, stages a temp CODEX_HOME dir it grants the package SID read/write, then relaunches itself inside that AppContainer pointed at the dir. The child (Low IL) prints:

  std::fs::write(dir/probe.txt)                   = OK
  std::fs::read(dir/probe.txt)                    = OK
  CreateFileW(dir, access=0, BACKUP_SEMANTICS)    = OK
  GetFinalPathNameByHandleW(VOLUME_NAME_NT)       = OK (\Device\HarddiskVolume4\codex-canon-repro\home)
  GetFinalPathNameByHandleW(VOLUME_NAME_DOS)      = FAIL (os error 5)   <-- the denied step
  std::fs::canonicalize(dir)                      = FAIL (os error 5)   <-- THE BUG
  std::path::absolute(dir)                        = OK (C:\codex-canon-repro\home)   <-- THE PROPOSED FIX

So the directory is fully read/writable; only the DOS-drive-letter resolution std::fs::canonicalize relies on is denied, and std::path::absolute (GetFullPathNameW-based, no handle, no \GLOBAL??) works — confirming p.canonicalize().or_else(|_| std::path::absolute(&p)) would resolve it.