Skip to content

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

Open
Open
Windows sandboxed sessions cannot access valid gh keyring auth that works in full-access mode#21821
Labels
CLIIssues related to the Codex CLIauthIssues related to authentication and accountsbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@OnerrotRamo
OnerrotRamo
opened on May 8, 2026

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:

    gh auth login -h github.com

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

    gh auth status

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

    gh auth status

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    windows-osIssues related to Codex on Windows systems
    authIssues related to authentication and accounts
    sandboxIssues related to permissions or sandboxing
    on May 8, 2026

  2. github-actions commented on May 8, 2026

    @github-actions
    github-actionsBot
    on May 8, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. vroonhof commented on May 12, 2026

    @vroonhof
    vroonhof
    on May 12, 2026

    FWIW I get the same under linux (WSL2)

  4. escape0707 commented on May 19, 2026

    @escape0707
    escape0707
    on May 19, 2026

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

  5. tungdd2710 commented on May 22, 2026

    @tungdd2710
    tungdd2710
    on May 22, 2026

    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.

  6. escape0707 commented on May 22, 2026

    @escape0707
    escape0707
    on May 22, 2026

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

  7. tungdd2710 commented on May 22, 2026

    @tungdd2710
    tungdd2710
    on May 22, 2026

    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.

  8. escape0707 commented on May 22, 2026

    @escape0707
    escape0707
    on May 22, 2026

    @tungdd2710 Stop talking like a 🤖. 👎

  9. lambegraham commented on Jul 31, 2026

    @lambegraham
    lambegraham
    on Jul 31, 2026

    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.

  10. yuweiyang9611 commented on Aug 15, 2026

    @yuweiyang9611
    yuweiyang9611
    on Aug 15, 2026

    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.

  11. tomaae commented on Aug 17, 2026

    @tomaae
    tomaae
    on Aug 17, 2026 – with ChatGPT Codex Connector

    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.

  12. tomaae commented on Aug 17, 2026

    @tomaae
    tomaae
    on Aug 17, 2026

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

  13. ale-arc commented on Aug 21, 2026

    @ale-arc
    ale-arc
    on Aug 21, 2026 – with ChatGPT Codex Connector

    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.

  14. aboozar-droid commented on Sep 14, 2026

    @aboozar-droid
    aboozar-droid
    on Sep 14, 2026 – with ChatGPT Codex Connector

    Affected user confirmation on current Windows Codex Desktop. This is reproducible and separate from repository state.

    Environment:

    • Windows 10 Pro 22H2 / build 19045 x64
    • Codex Desktop 26.908.4834.0
    • bundled CLI codex-cli 0.154.0-alpha.6.2
    • elevated native Windows sandbox

    Host PowerShell authentication is healthy:

    gh auth status
github.com
  ✓ Logged in to github.com account <redacted> (keyring)
  - Active account: true
  - Git operations protocol: https

    Inside the Codex sandbox, the same account is detected but authentication fails:

    github.com
  X Failed to log in to github.com account <redacted> (default)
  - Active account: true
  - The token in default is invalid.

    Additional isolation:

    • sandbox process identity is a dedicated CodexSandboxOffline account
    • USERPROFILE, APPDATA, and LOCALAPPDATA still point to the normal user's profile
    • no GH_TOKEN or GITHUB_TOKEN override is present (only GH_PAGER)
    • gh auth token --hostname github.com returns exit code 1 inside the sandbox
    • cmdkey /list | findstr /I "github gh:" returns no matching entries inside the sandbox
    • host PowerShell continues to read the same GitHub login successfully from Windows keyring

    This strongly suggests that the sandboxed process cannot access the normal user's Windows Credential Manager/keyring context even though profile environment variables point to that user.

    Impact: GitHub-dependent Codex workflows break despite valid host authentication. Combined with current Windows sandbox issues, this has required more than a full day of manual troubleshooting and repeated PowerShell fallbacks.

    Expected behavior: a sandboxed Codex session should be able to use the already-valid gh login for the current Windows user, or Codex should broker that credential safely. Re-authenticating separately inside each sandbox identity should not be required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIauthIssues related to authentication and accountsbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions