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

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

• #20917

Powered by Codex Action

FWIW I get the same under linux (WSL2)

@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.

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.

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

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.

@tungdd2710 Stop talking like a 🤖. 👎

This also happens on Mac too. Experiencing this for the last few weeks. I have to escalate outside sandbox for the token to be valid.

Independent reproduction from the ChatGPT/Codex Windows desktop app. This is still reproducible with a substantially newer bundled CLI.

Environment

• ChatGPT/Codex Windows desktop app, Windows-native elevated sandbox
• Windows 10.0.26200.0
• Bundled/available Codex CLI: 0.147.0
• GitHub CLI: 2.96.0
• gh.exe: C:\Program Files\GitHub CLI\gh.exe
• No GH_TOKEN, GITHUB_TOKEN, GH_HOST, or GH_CONFIG_DIR override was present

Reproduction and comparison

From a normal Windows PowerShell session under the interactive user:

gh auth status --active --hostname github.com
✓ Logged in to github.com (keyring)

gh api user --jq .login
<expected login>

From the Codex elevated sandbox, using the same gh.exe and the same GitHub CLI host metadata:

whoami
<machine>\CodexSandboxOffline

gh auth status --active --hostname github.com
The token in default is invalid.

gh api user --jq .login
HTTP 401: Requires authentication

Re-running the same gh checks from Codex with execution explicitly escalated outside the sandbox succeeds immediately using the existing Windows keyring credential. No reauthentication is required.

User-visible impact

This is not only a low-level CLI failure in the desktop app. Across multiple repositories, Codex observes the sandboxed gh auth status result, concludes that the user's valid token has expired, and recommends or initiates gh auth login / device-code authentication again. This makes authentication appear to fail inconsistently per repository even though the interactive user's credential remains valid globally.

Git operations can also continue to work through Git Credential Manager while gh pr, gh issue, gh repo, and gh api fail in the sandbox, which makes the diagnosis especially confusing.

Expected behavior

When Windows gh authentication is keyring-backed, Codex should either:

1. run gh outside the dedicated sandbox identity after requesting approval, or
2. detect that the credential is unavailable because of sandbox identity isolation and present that specific explanation.

It should not classify this condition as an expired/invalid user token or recommend repeated device-code login before verifying from the interactive-user context.

Current workaround

I added global Codex guidance requiring every gh invocation to use sandbox_permissions = "require_escalated", plus prompt rules for gh, gh.exe, and the resolved absolute executable path. This avoids the false reauthentication flow, but it is a configuration workaround rather than a product-level fix.

Confirmed this is still reproducible in the Windows desktop app.

Environment

• Codex Windows app: 26.810.7004.0
• Windows: 25H2, build 26200.9168
• GitHub CLI: 2.97.0
• Authentication stored in Windows Credential Manager/keyring
• GH_TOKEN and GITHUB_TOKEN unset

Observed behavior

From a workspace-write sandbox, a fresh process reports:

gh auth status
X Failed to log in
The token in default is invalid.

An authenticated repository GraphQL request from the same sandbox returns HTTP 401.

Running the same commands with access to the normal Windows user keyring immediately succeeds:

✓ Logged in (keyring)
Token scopes: gist, read:org, repo, workflow

Repository and release API operations then work normally. A fresh git credential fill also retrieves the GitHub credential through the GitHub-specific gh auth git-credential helper when keyring access is available.

Impact

The false “token is invalid” result can cause an agent to initiate unnecessary GitHub device-login flows repeatedly, even though the saved credential is valid. This interrupts otherwise autonomous GitHub work and consumes user time and task usage.

Verified workaround

Before recommending gh auth login, rerun gh auth status --hostname github.com outside the restricted sandbox with Windows keyring access. If that succeeds, continue authenticated gh operations in that context. Also distinguish GitHub HTTP 5xx responses from authentication failures; transient 503 responses occurred separately during this reproduction.

No credentials, account identifiers, repository identifiers, local paths, or session logs are included in this confirmation.

Aside of automatic issue submit, this is very annoying. it happens for me several times per day, wasting credits and my time.

Additional reproduction from Codex Desktop on Windows (2026-08-21), specifically inside the workspace-write sandbox:

• gh auth status reports the active account but says: The token in default is invalid.
• gh issue view 19 --repo ale-arc/kito fails with HTTP 401: Requires authentication.
• The authenticated GitHub connector in the same Codex task can fetch ale-arc/kito#19 successfully.

This isolates the failure to gh CLI access to the Windows credential store/keyring from the sandbox identity, rather than repository visibility, network reachability, or an actually invalid token.

Expected behavior: Codex should detect/report sandbox credential-store isolation and either route GitHub operations through its authenticated connector or run gh outside the sandbox only after explicit approval. It should not classify the user's credential as invalid or trigger repeated login guidance.

No credentials or account identifiers are included.