Codex Says Your GitHub CLI Token Is Invalid? Check the Sandbox First

If GitHub CLI works in your normal macOS terminal but Codex reports The token in default is invalid, do not log out or replace the credential yet. First run the same non-secret checks in both execution contexts. If the host succeeds and Codex fails with the same gh binary and account, the evidence points to an execution-boundary problem, not a proven bad token.

This failure is active in OpenAI's Codex issue tracker. One report shows gh auth status succeeding in the user's terminal while the same account appears invalid to Codex. A related report reproduced keychain-backed gh commands failing inside the sandbox and succeeding with narrowly scoped host access. These reports establish the symptom and a useful classifier. They do not prove that every GitHub authentication error is caused by the sandbox.

Match the symptom before changing authentication

This guide fits when:

• the problem occurs in Codex Desktop or a Codex-managed command;

• gh uses a credential stored in the macOS Keychain;

• Codex says the active token is invalid or asks you to authenticate;

• the same repository and account work from an ordinary terminal;

• the failure blocks operations such as listing pull requests, checking CI, or creating a PR.

There are three different failure classes that can look similar:

Do not use the first error message as the diagnosis. Complete the two-context comparison.

1. Test the normal terminal without exposing the token

Open Terminal outside Codex and run:

command -v gh
gh --version
gh auth status --active --hostname github.com
gh api user --jq .login

Expected result: gh auth status identifies the intended active account and gh api user returns its login.

The API check matters. GitHub CLI documents gh auth status as an account and authentication-state check, while gh api user proves that an authenticated request succeeds. A status message alone is not enough if the stored credential is stale or rejected.

Never add --show-token, run gh auth token, paste a token into a prompt, or print a credential while collecting diagnostics. Record only the executable path, version, hostname, account name, exit status, and redacted error.

2. Ask Codex to run the same checks

In the affected Codex task, ask it to run the same four commands without printing secrets:

command -v gh
gh --version
gh auth status --active --hostname github.com
gh api user --jq .login

Compare the results line by line:

• If command -v gh differs, you are testing different installations.

• If the versions differ, align or explicitly account for that difference before blaming authentication.

• If the active accounts differ, select the intended account in the host terminal with gh auth switch.

• If the host passes and Codex alone fails, preserve that result. Re-authentication is not yet justified.

• If both contexts fail, repair the host-side GitHub CLI setup before returning to Codex.

OpenAI's Codex repository documents platform sandboxes, including Seatbelt on macOS. A process inside that boundary can observe different filesystem, network, environment, or credential-store access than the same command launched directly by the user. That is why identical commands are the decisive control.

3. Check configuration identity without reading credentials

Different configuration roots can also produce different active accounts. In both contexts, inspect the variable name and path only:

printf 'GH_CONFIG_DIR=%s\n' "${GH_CONFIG_DIR:-<default>}"
gh auth status --hostname github.com

To see whether token variables are present without printing their values:

env | sed 's/=.*//' | grep -E '^(GH_TOKEN|GITHUB_TOKEN)$' || true

GitHub CLI documents that GH_TOKEN and then GITHUB_TOKEN take precedence for github.com. It also documents the default configuration directory when GH_CONFIG_DIR is unset. A difference here can explain why two gh processes choose different authentication sources.

Do not copy a token into the repository, .env, shell history, task prompt, or diagnostic log to make the outputs match. If unattended execution needs a token, configure it in the owning runner's secret boundary or use a managed OAuth connection.

4. Retry only the exact command with scoped access

When the host passes and Codex fails, request a retry of the smallest GitHub command with the additional permission needed to access the existing credential context. For example, retry only:

gh auth status --active --hostname github.com

Then verify one read-only API call:

gh api user --jq .login

Do not grant broad permanent access merely to make one status probe pass. Keep the approval tied to the exact command or reviewed command family, and inspect the requested scope before approving it.

If the scoped retry succeeds, continue with one read-only repository operation before attempting a write:

gh repo view OWNER/REPO --json nameWithOwner,url

Replace OWNER/REPO with the intended repository. Success confirms that Codex can now use the expected account against the expected repository. It does not authorize a push, PR creation, or merge by itself.

5. Repair authentication only when the host control fails

If the ordinary terminal also fails, fix that independent host problem. Start with the active account:

gh auth status --hostname github.com
gh auth switch --hostname github.com
gh api user --jq .login

If the intended account is selected but authentication still fails, use GitHub CLI's supported login flow:

gh auth login --hostname github.com --web
gh auth status --active --hostname github.com
gh api user --jq .login

This is the point where re-authentication is appropriate, because the host control proved that the problem is not isolated to Codex. Keep tokens out of command arguments and logs. GitHub recommends environment-based authentication for headless use, but the value belongs in a secret manager or runner configuration, not in source control.

6. Use a connected GitHub Action for durable agent workflows

Local gh is useful when you intentionally want the agent to operate through the host CLI. For scheduled or repeatable work, a connected Action can remove the dependency on a local keychain being visible from every sandboxed process.

Follow https://aident.ai/SETUP.md and connect GitHub through its OAuth boundary. Then ask the agent to:

1. search the capability catalog for the exact GitHub read or write operation;

2. inspect the Action schema and connected account;

3. preflight the exact input;

4. run a read-only identity or repository check first;

5. request explicit approval before any operation that changes GitHub state.

This is not a reason to bypass repository policy. It gives the agent a reviewed integration path whose authentication is separate from a caller-local Keychain. For the tradeoffs, see GitHub MCP Server vs Aident Loadout. If the connection sees no repositories, use the narrower Codex GitHub plugin repository-access guide. For credential-boundary design, continue to MCP API Keys vs OAuth.

7. Verify the recovery before trusting automation

After either scoped access or a repaired host login, verify in this order:

gh auth status --active --hostname github.com
gh api user --jq .login
gh repo view OWNER/REPO --json nameWithOwner,url
gh pr list --repo OWNER/REPO --limit 5

Expected results:

• every command uses the intended account;

• the repository name and URL are correct;

• the read-only PR list succeeds;

• no token value appears in output;

• no login prompt or credential mutation occurs during the verification.

Only then resume the original GitHub task. Preserve the command that failed, the context where it failed, and the exact recovery that made it pass. That evidence is more useful than a blanket instruction to log in again.

Conclusion

When gh works in a normal macOS terminal but Codex says the token is invalid, compare the same non-secret status and API checks in both contexts. A host-pass and Codex-fail result indicates an execution-boundary problem until proven otherwise. Retry the smallest command with scoped approved access or use a connected GitHub Action. Re-authenticate only when the host control also fails, and never expose the token while diagnosing the boundary.

Sources

• OpenAI Codex issue #31017: Codex cannot access gh

• OpenAI Codex issue #36478: Route keyring-backed gh commands through scoped host access

• OpenAI Codex issue #10695: GitHub skill cannot access keychain-backed authentication

• OpenAI Codex repository: experimenting with the Codex sandbox

• GitHub CLI manual: gh auth status

• GitHub CLI manual: environment variables

• GitHub CLI manual: gh auth login