Description
On Windows, gh auth status fails in a sandboxed Codex shell session with an invalid token error, but succeeds in a full-access session on the same machine for the same user and the same gh binary.
This appears to be a sandbox/session integration issue with Windows Credential Manager or keyring visibility, not a GitHub CLI auth problem.
Environment
- OS: Windows
- Codex CLI:
0.129.0-alpha.15
- GitHub CLI installed and already authenticated
gh binary path in both contexts: C:\Program Files\GitHub CLI\gh.exe
Steps to reproduce
-
Authenticate GitHub CLI on Windows:
gh auth login -h github.com
-
Confirm auth works in a normal or full-access context:
-
Run the same command from a sandboxed Codex shell session:
-
Compare diagnostics in both contexts:
where.exe gh
cmdkey /list
Expected behavior
A sandboxed Codex session should be able to use the same valid GitHub CLI login as a full-access session for the current Windows user.
gh auth status should succeed in both contexts.
Actual behavior
In the sandboxed session:
github.com
X Failed to log in to github.com account <account> (default)
- Active account: true
- The token in default is invalid.
In the full-access session:
github.com
? Logged in to github.com account <account> (keyring)
Additional difference:
- In sandboxed session,
cmdkey /list did not show the expected GitHub CLI credential targets.
- In full-access session,
cmdkey /list showed entries like:
LegacyGeneric:target=gh:github.com:<account>LegacyGeneric:target=gh:github.com:
Notes
- The same
gh binary was used in both contexts.
- GitHub CLI host metadata was present at
%APPDATA%\GitHub CLI\hosts.yml.
- This looks like the sandboxed session cannot access the same Windows credential/keyring context that full-access can.
Impact
This breaks GitHub-dependent Codex workflows on Windows in sandboxed mode even when gh auth is valid outside sandbox.
Description
On Windows,
gh auth statusfails in a sandboxed Codex shell session with an invalid token error, but succeeds in a full-access session on the same machine for the same user and the sameghbinary.This appears to be a sandbox/session integration issue with Windows Credential Manager or keyring visibility, not a GitHub CLI auth problem.
Environment
0.129.0-alpha.15ghbinary path in both contexts:C:\Program Files\GitHub CLI\gh.exeSteps to reproduce
Authenticate GitHub CLI on Windows:
Confirm auth works in a normal or full-access context:
Run the same command from a sandboxed Codex shell session:
Compare diagnostics in both contexts:
Expected behavior
A sandboxed Codex session should be able to use the same valid GitHub CLI login as a full-access session for the current Windows user.
gh auth statusshould succeed in both contexts.Actual behavior
In the sandboxed session:
In the full-access session:
Additional difference:
cmdkey /listdid not show the expected GitHub CLI credential targets.cmdkey /listshowed entries like:LegacyGeneric:target=gh:github.com:<account>LegacyGeneric:target=gh:github.com:Notes
ghbinary was used in both contexts.%APPDATA%\GitHub CLI\hosts.yml.Impact
This breaks GitHub-dependent Codex workflows on Windows in sandboxed mode even when
ghauth is valid outside sandbox.