Codex CLI 0.124.0 misreports `gh auth status` as invalid inside Codex session

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

• #17991
• #19190

Powered by Codex Action

I have a related Windows data point.

In my case, GitHub auth is valid outside the Codex tool-call environment:

• Codex CLI: 0.125.0
• OS: Windows 11
• Shell: PowerShell
• gh: C:\Program Files\GitHub CLI\gh.exe
• No GH_TOKEN / GITHUB_TOKEN environment variables are set
• Auth is keyring-backed

External checks succeed:

gh auth status -> exit 0
gh api user -> sean3808 / id 21366418
gh api rate_limit -> authenticated core limit 5000

The same account also works from Git Bash and from Claude Code using both PowerShell and Git Bash.

However, inside a Codex sandbox/tool-call context I previously saw gh auth status report the saved account as invalid. After switching/running outside that restricted context, the same gh installation and same Windows account report valid auth again.

So this looks consistent with the issue being a Codex runtime / sandbox / spawned-process environment problem rather than an actually invalid GitHub token.

One distinction from the original report: this happened without GITHUB_TOKEN; auth is coming from the Windows keyring. That suggests the problem may affect keyring-backed gh auth as well, not only env-token auth.

MacOS 26.4 here and having the same issue.

Same issue here...

• Codex app: 26.513.31313
• OS: Windows 11

<img width="249" height="85" alt="Image" src="https://github.com/user-attachments/assets/5547b61c-be30-459b-af73-17d1ae9ff734" />

<img width="391" height="158" alt="Image" src="https://github.com/user-attachments/assets/e613fefe-5f5a-443b-a856-010a94e01671" />

<img width="139" height="107" alt="Image" src="https://github.com/user-attachments/assets/da581701-9f22-4154-9690-90cdee7bf637" />

also having the same issue CLI reports invalid but outside in any terminal reports valid account and logged in

Ubuntu 24.04, same issue.

$ gh --version
gh version 2.92.0 (2026-04-28)
https://github.com/cli/cli/releases/tag/v2.92.0

Codex VS Code Extension: 26.519.32039

Note: Change permission from "Default permissions" to "Full access" solved this issue, and gh auth status reported success when ran by Codex. Seems like a sandbox-related issue.

Confirmed another macOS data point while investigating #27740:

• Codex Desktop: 26.608.12217
• Bundled Codex CLI: 0.138.0-alpha.7
• macOS: Darwin 25.3.0 arm64 arm
• GitHub CLI: 2.93.0
• Auth: keyring-backed

Inside a network-restricted Codex tool sandbox, gh auth status reported the saved account/token as invalid. Running the same command outside that sandbox immediately succeeded:

Logged in to github.com account 0xdevalias (keyring)

The credential was valid. The misleading “invalid token” result was caused by GitHub CLI being unable to verify it from the restricted execution context.

This was separate from #27740’s sidebar bug, which failed earlier at gh --version because shell-environment loading timed out and left gh absent from PATH.

Potential workarounds, in increasing scope:

1. Add an allow rule to ~/.codex/rules/default.rules:

``python
prefix_rule(
pattern = ["gh", "auth", "status"],
decision = "allow",
justification = "Allow GitHub CLI authentication checks",
)
``

Restart Codex after editing the rule. This allows the exact command to run outside the sandbox without repeated prompts. It does not grant network access inside the sandbox, so Codex must still request escalation when networking is restricted.

1. Define a scoped permission profile in ~/.codex/config.toml:

```toml
default_permissions = "github-workspace"

[permissions.github-workspace]
extends = ":workspace"

[permissions.github-workspace.network]
enabled = true

[permissions.github-workspace.network.domains]
"github.com" = "allow"
"api.github.com" = "allow"
```

Restart Codex, then select/use the github-workspace profile. This preserves workspace-level filesystem access while limiting network access to GitHub. Additional domains may be required for some gh operations.

1. As a broader (much less secure) fallback, you could enable network access for every command using the normal workspace sandbox by adding this to ~/.codex/config.toml:

``toml
[sandbox_workspace_write]
network_access = true
``

Restart Codex afterward. This is less desirable because it grants unrestricted outbound network access to all commands in workspace-write, rather than only GitHub-related commands.

The product should ideally distinguish an unreachable authentication endpoint from an actually rejected credential instead of presenting both as “token invalid.” Managed runtime policy may also override local network settings, so the effective permission profile should be visible in diagnostics.

This also happens in the desktop app on Windows. It completely breaks the built-in Github skill for pushing, CI, etc.

still an issue