Summary
On Windows x64 agit-v0.2.0, agit login --with-token can authenticate against a loopback test endpoint but then fails to save credentials even when AGIT_HOME is under a user-owned directory with only the current user, SYSTEM, and Administrators in its ACL. The error is:
cannot save the signed-in credentials: ... Private state grants access to another Windows user; use a private AGIT_HOME
The same failure occurs with AGIT_HOME in two different private directories under the user profile. No actual AgentGit Hub token was used in this reproduction.
Reproduction context
- Windows 11 x64, NTFS system drive.
C:\ has an Authenticated Users:(M) ACE; the user profile and chosen AGIT_HOME directories do not grant that group access.- Portable official v0.2.0 release archive verified against the published
SHA256SUMS; no global agit setup.
AGIT_HOME points to an ordinary, non-reparse directory under the current user's profile.- Sign-in uses a loopback-only synthetic
/api/auth/login and /api/auth/me fixture with fake identity/token values.
The request reaches the mock service, and the CLI receives an accepted response. Saving the returned synthetic credentials fails with exit code 4. Source inspection suggests validate_path traverses every ancestor and validate_acl rejects destructive access by non-trusted SIDs on ancestors; the system-drive root appears to trigger this. We did not instrument the release binary to prove which ancestor fails. We did not change system ACLs or use real credentials.
Expected
A supported secure way to store credentials on Windows when a broad system-drive-root ACE exists, without weakening ACLs or concealing the physical path through a drive mapping. If refusing is intentional, please document a safe supported storage location/procedure and identify the rejected ancestor in the diagnostic.
Additional observation
After a throwaway synthetic identity was saved through a temporary mapped-drive test only, versioned import, branch history, and fork --resume --no-launch native Codex-session materialization worked. We did not use that mapping for real credentials because it would bypass ancestor validation rather than resolve the underlying security question.
Summary
On Windows x64
agit-v0.2.0,agit login --with-tokencan authenticate against a loopback test endpoint but then fails to save credentials even whenAGIT_HOMEis under a user-owned directory with only the current user, SYSTEM, and Administrators in its ACL. The error is:The same failure occurs with
AGIT_HOMEin two different private directories under the user profile. No actual AgentGit Hub token was used in this reproduction.Reproduction context
C:\has anAuthenticated Users:(M)ACE; the user profile and chosenAGIT_HOMEdirectories do not grant that group access.SHA256SUMS; no globalagit setup.AGIT_HOMEpoints to an ordinary, non-reparse directory under the current user's profile./api/auth/loginand/api/auth/mefixture with fake identity/token values.The request reaches the mock service, and the CLI receives an accepted response. Saving the returned synthetic credentials fails with exit code 4. Source inspection suggests
validate_pathtraverses every ancestor andvalidate_aclrejects destructive access by non-trusted SIDs on ancestors; the system-drive root appears to trigger this. We did not instrument the release binary to prove which ancestor fails. We did not change system ACLs or use real credentials.Expected
A supported secure way to store credentials on Windows when a broad system-drive-root ACE exists, without weakening ACLs or concealing the physical path through a drive mapping. If refusing is intentional, please document a safe supported storage location/procedure and identify the rejected ancestor in the diagnostic.
Additional observation
After a throwaway synthetic identity was saved through a temporary mapped-drive test only, versioned import, branch history, and
fork --resume --no-launchnative Codex-session materialization worked. We did not use that mapping for real credentials because it would bypass ancestor validation rather than resolve the underlying security question.