[GitHub plugin] Route keyring-backed gh commands through scoped host access

Summary

The bundled GitHub plugin frequently runs gh inside the Codex sandbox first. When GitHub CLI authentication is stored in the macOS keychain, that sandboxed invocation reports that the active token is invalid. Running the exact same command with scoped host access succeeds immediately.

This produces a misleading authentication diagnosis and can make GitHub plugin workflows stop, recommend unnecessary re-authentication, or require the user to explicitly tell Codex to retry gh outside the sandbox.

This report is specifically about GitHub plugin command routing and error handling. The sandbox may intentionally isolate the host keychain; if so, plugin workflows that choose gh should account for that boundary.

Environment

• Surface: Codex desktop local command execution
• Codex CLI: 0.146.0
• GitHub CLI: 2.93.0
• Platform: macOS 26.4 / Darwin 25.4.0, arm64
• Sandbox: restricted filesystem and network, OnRequest approval policy
• GH_TOKEN and GITHUB_TOKEN: unset
• GitHub CLI credential storage: macOS keyring

Reproduction

1. Authenticate GitHub CLI normally on the host so the credential is stored in the macOS keyring.
2. Confirm GH_TOKEN and GITHUB_TOKEN are unset.
3. Ask Codex to perform a GitHub plugin workflow that falls back to gh, or directly have it run:

``sh
gh auth status
``

1. In ordinary sandboxed command execution, observe exit code 1:

```text
github.com
X Failed to log in to github.com account <account> (default)

• Active account: true
• The token in default is invalid.

```

1. A non-printing credential-read check also fails inside the sandbox:

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

1. Approve scoped host access and run the exact same status command again:

``sh
gh auth status
``

1. It succeeds immediately:

```text
github.com
✓ Logged in to github.com account <account> (keyring)

• Active account: true
• Git operations protocol: https

```

I reproduced this comparison in the same Codex task, seconds apart.

Actual behavior

GitHub plugin workflows can run gh inside the sandbox, interpret the resulting keychain isolation as an invalid token, and tell the user to re-authenticate. The command only works after the user redirects Codex to request host access.

Expected behavior

When a GitHub plugin workflow selects gh and the credential is keyring-backed, Codex should do one of the following while preserving the normal approval boundary:

1. request scoped host access for the specific gh command up front; or
2. recognize the sandbox-specific keyring/auth failure and immediately offer a host-access retry.

It should not claim that the token is invalid or recommend gh auth login until the same check has been attempted in a context that can access the configured credential store.

Ideally, the GitHub plugin skills would share one capability-aware policy for gh rather than handling this differently in publish, CI, and review workflows.

Impact

• valid GitHub authentication is misdiagnosed as broken;
• workflows stop unnecessarily or loop through re-authentication attempts;
• users must know the implementation detail that gh needs host access;
• unattended or multi-step GitHub workflows can fail even though the host credential is valid.

Related reports

• #31017 reports the same macOS invalid-token symptom.
• #35752 reports the same Codex-shell versus working host discrepancy on macOS.
• #10695 covers the Fix CI skill and keychain isolation.
• #35876 covers the publish skill and the same class of sandboxed gh prerequisite failure on Windows.
• #20917 requests a general per-command sandbox exclusion mechanism.

The additional request here is a plugin-level fix: when bundled GitHub workflows choose gh, they should route it through scoped host access or correctly recover from the sandbox-specific failure.