›_ Codex Issues
Codex Issues / #21821

Windows sandboxed sessions cannot access valid gh keyring auth that works in full-access mode

Open 💬 7 comments Opened May 8, 2026 by OnerrotRamo
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Authenticate GitHub CLI on Windows:

``powershell
gh auth login -h github.com
``

  1. Confirm auth works in a normal or full-access context:

``powershell
gh auth status
``

  1. Run the same command from a sandboxed Codex shell session:

``powershell
gh auth status
``

  1. Compare diagnostics in both contexts:

``powershell
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.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #20917

Powered by Codex Action

vroonhof · 2 months ago

FWIW I get the same under linux (WSL2)

escape0707 · 2 months ago

@vroonhof I currently do:

$ readlink ~/.local/bin/gh
/mnt/c/Program Files/GitHub CLI/gh.exe

And for the Windows side, the reason is in Windows sandbox, Codex is running with identity CodexSandboxOnline. This is different from your Windows user identity and thus gh can only communicate with Windows Credential Store with that identity's view and can't see your token.

The fix is to reauthenticate in Codex sandbox without sandbox escalation. And maybe you should also use --clipboard to extract the 8bit auth code and pre supply all parameters.

So I now have two token with each of their user identity associated in Windows Credential Store, and my WSL use gh.exe.

tungdd2710 · 1 month ago

One workaround worth testing is to make the sandbox avoid the Windows keyring path entirely and use a process-scoped token for the one command/run.

From a normal full-access shell where keyring auth works:

$env:GH_TOKEN = gh auth token
gh auth status

Then run the Codex task in the same process environment, or pass only the minimal token value needed for the command. This should force GitHub CLI to use GH_TOKEN instead of trying to reach Windows Credential Manager from inside the sandbox. I would not persist this globally; keep it scoped to the shell/process and clear it afterward:

Remove-Item Env:GH_TOKEN

For diagnosis, the useful comparison is:

gh auth status --show-token
gh auth token | Measure-Object -Character
cmdkey /list | Select-String -Pattern "github|gh:"
[Environment]::GetEnvironmentVariable("GH_TOKEN")
[Environment]::GetEnvironmentVariable("GITHUB_TOKEN")

If GH_TOKEN works but keyring does not, that narrows this to credential-manager visibility rather than GitHub CLI config parsing. A product-side fix could either broker the host credential into the sandbox or detect keyring-backed gh auth and suggest a scoped GH_TOKEN fallback before workflows fail.

escape0707 · 1 month ago

@tungdd2710 Supplying token with environment variables is not very safe. Check my edited comment.

tungdd2710 · 1 month ago

Agreed for persistent/user-wide environment variables. I should have been more explicit: I meant this only as a short-lived diagnostic in a throwaway shell, not as the normal workaround.\n\nFor day-to-day use, your edited approach of authenticating from inside the sandbox identity is safer because the token stays in the credential store view that the sandboxed gh process can access.\n\nIf someone still uses GH_TOKEN to confirm the failure mode, keep it process-scoped only:\n\npowershell\n = gh auth token\ngh auth status\nRemove-Item Env:GH_TOKEN\n\n\nDo not set it at User/Machine scope and do not write it into shell profiles. If that diagnostic works while keyring auth fails, it is enough evidence that the problem is credential-store identity/visibility rather than gh config parsing.

escape0707 · 1 month ago

@tungdd2710 Stop talking like a 🤖. 👎