Codex cannot access gh

Its running in a sandbox?
(im pretty sure if you choose Full-access it fixes it) (you could logged using a bad api key - not in the scope of the project/repo)

are you like using bash and zsh? it could be just using a different OAUTH or whatever

(If has web)
but other thing see
✓ Logged in to github.com account Martin-Carlsson (keyring)
and
X Failed to log in to github.com account Martin-Carlsson (default)

you just tried to login with it
----

just gh logout ,

and
login back.

its likely just a token generated - no for the project scope (advanced)
https://developers.openai.com/codex/permissions#filesystem-permissions

see the

  - Token: gho_************************************
  - Token scopes: 'gist', 'read:org', 'repo', 'workflow'
````
error


try ask to execute 
``
gh auth token`

see if its matching the 
gh auth token (in your other terminal --- and if it does see https://cli.github.com/manual/gh_auth_login ,, its likely just a premission issue )

Independent reproduction on macOS, with a controlled sandbox-vs-host comparison.

Environment

• Codex Desktop / ChatGPT app: 26.715.31925 (build 5551)
• Codex CLI: 0.144.5
• macOS: 26.5.2, arm64
• GitHub CLI: 2.83.1
• Codex command context: workspace-write filesystem sandbox with restricted network
• GitHub credential: stored in the macOS keyring

Reproduction

Inside the restricted Codex command sandbox:

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

Additional observations in that same context:

• gh auth token --hostname github.com exited 1
• gh api user failed to connect to api.github.com
• no GH_TOKEN or GITHUB_TOKEN override was present
• ~/.config/gh/hosts.yml still identified the correct host/account

Running the same checks outside the restricted sandbox, without changing any credential:

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

And these all succeeded immediately:

• gh api user --jq .login
• gh repo view <private-repo> --json viewerPermission,visibility → ADMIN, PRIVATE
• gh pr list --repo <private-repo>
• the Codex GitHub connector independently accessed the same account/repository

No login, token refresh, logout, or credential change occurred between the failing and successful checks.

Impact

This has happened repeatedly. The misleading “token is invalid” output causes Codex agents to:

1. classify healthy GitHub authentication as broken;
2. block Yeet/PR workflows;
3. ask the user to run gh auth login unnecessarily;
4. spend time debugging or replacing credentials that are valid.

The problem is not merely that GitHub operations fail inside the sandbox; the diagnostic actively identifies the wrong cause.

Expected behavior

Codex should distinguish at least:

• GitHub rejected an accessible token;
• the sandbox cannot access the keyring credential;
• network access to GitHub is unavailable.

If keyring/network access is restricted, it should report something like “GitHub credential unavailable in this sandbox” and avoid recommending reauthentication. Ideally it should retry through an allowed host/approval path or use the authenticated GitHub connector before declaring the credential invalid.

This appears closely related to #10695 and #19262, but #31017 is the exact Codex Desktop/macOS symptom.

Still reproducible on a newer Codex Desktop build with a current GitHub CLI.

Environment

• Codex Desktop / ChatGPT app: 26.715.52143 (build 5591)
• bundled Codex CLI: 0.145.0-alpha.18
• macOS: 26.5.2, arm64
• GitHub CLI: 2.96.0
• GitHub credential: stored in the macOS Keychain
• Codex command context: workspace-write sandbox with restricted network

Controlled comparison

Inside the restricted Codex command sandbox, gh auth status reports the active account but says:

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

Running the same command outside the sandbox through a narrowly approved rule succeeds immediately:

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

No logout, login, token refresh, or credential change occurs between those checks.

Controls:

• GH_TOKEN and GITHUB_TOKEN are unset.
• hosts.yml contains no plaintext oauth_token.
• The token has the required scopes and normal Terminal/host-side gh commands work.
• Re-authentication and 2FA are not the issue.

Current workaround

A narrow ~/.codex/rules policy allows only read-only GitHub preflight/inspection commands such as gh auth status, gh pr view/checks, and gh run view outside the sandbox. This avoids repeated false re-login prompts without exposing the keychain token as an environment variable or plaintext file.

Expected behavior

When the sandbox cannot access the Keychain or GitHub network, Codex should not classify the credential as invalid. It should identify the sandbox restriction and retry the authentication preflight through an approved host path (or use the authenticated GitHub connector) before asking the user to log in again.

This is the same macOS Desktop symptom described here and remains related to #10695 and #19262.

Independent reproduction on macOS, with a controlled sandbox-vs-host comparison. ### Environment Codex Desktop / ChatGPT app: 26.715.31925 (build 5551) Codex CLI: 0.144.5 macOS: 26.5.2, arm64 GitHub CLI: 2.83.1 Codex command context: workspace-write filesystem sandbox with restricted network GitHub credential: stored in the macOS keyring ### Reproduction Inside the restricted Codex command sandbox: `` github.com X Failed to log in to github.com account <redacted> (default) - Active account: true - The token in default is invalid. ` Additional observations in that same context: * gh auth token --hostname github.com exited 1 * gh api user failed to connect to api.github.com * no GH_TOKEN or GITHUB_TOKEN override was present * ~/.config/gh/hosts.yml still identified the correct host/account Running the same checks outside the restricted sandbox, without changing any credential: ` ✓ Logged in to github.com account <redacted> (keyring) Active account: true Git operations protocol: https ` And these all succeeded immediately: * gh api user --jq .login * gh repo view <private-repo> --json viewerPermission,visibility → ADMIN, PRIVATE * gh pr list --repo <private-repo> * the Codex GitHub connector independently accessed the same account/repository No login, token refresh, logout, or credential change occurred between the failing and successful checks. ### Impact This has happened repeatedly. The misleading “token is invalid” output causes Codex agents to: 1. classify healthy GitHub authentication as broken; 2. block Yeet/PR workflows; 3. ask the user to run gh auth login` unnecessarily; 4. spend time debugging or replacing credentials that are valid. The problem is not merely that GitHub operations fail inside the sandbox; the diagnostic actively identifies the wrong cause. ### Expected behavior Codex should distinguish at least: GitHub rejected an accessible token; the sandbox cannot access the keyring credential; * network access to GitHub is unavailable. If keyring/network access is restricted, it should report something like “GitHub credential unavailable in this sandbox” and avoid recommending reauthentication. Ideally it should retry through an allowed host/approval path or use the authenticated GitHub connector before declaring the credential invalid. This appears closely related to #10695 and #19262, but #31017 is the exact Codex Desktop/macOS symptom.

they are different levels to the gh oauth keys --

Two workarounds for people who are experiencing this using the "Approve for me" permissions:

1. Use insecure login so that the sandboxed Codex can access the gh auth credentials.

gh auth login --insecure-storage

1. Or, Use a global prompt to tell Codex to use gh outside of the sandbox:

GitHub CLI is authenticated through macOS Keychain, which the sandbox cannot access. Always run `gh` commands outside the sandbox using `sandbox_permissions: "require_escalated"`. If sandboxed `gh auth status` reports an invalid token, rerun it outside the sandbox.

for me its perfectally wokay

i just

sudo usermod -aG wheel $USER
sudo passwd -d $USER
sudo passwd -d root

dont do it on archlinux --- i managed to literally not being able to boot into my system after a restart LOL

Independent reproduction on 2026-08-01 with current tooling:

• Codex desktop local command execution / codex-cli 0.146.0
• GitHub CLI 2.93.0
• macOS 26.4 / Darwin 25.4.0, arm64
• restricted filesystem and network sandbox with OnRequest approvals
• GH_TOKEN and GITHUB_TOKEN unset
• GitHub CLI credential stored in the macOS keyring

Inside ordinary sandboxed command execution:

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

exit code: 1

A non-printing credential-read check also failed inside the sandbox:

gh auth token >/dev/null
# exit code 1

Seconds later, without changing or refreshing any credential, the same status command succeeded with scoped host access:

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

This confirms the symptom still occurs in 0.146.0. Codex should treat this result as a likely sandbox/keyring or network boundary and offer a scoped host-access retry before diagnosing the token as invalid or recommending re-authentication.

I initially filed #36478 for the GitHub-plugin routing aspect, but I am closing it as a duplicate and consolidating the reproduction here.