›_ Codex Issues
Codex Issues / #35876

[bug] GitHub publish skill requires gh even when connector path is available

Open 💬 1 comment Opened Jul 29, 2026 by startwithwater

What version of Codex is running?

codex-cli 0.145.0, with GitHub plugin source inspected at openai/plugins@11c74d6ba24d3a6d48f54a194cd00ef3beea18f9.

What platform is your computer?

Windows 11 x64 using the elevated native Windows sandbox.

What issue are you seeing?

The GitHub yeet publish skill describes a connector-first workflow with gh used only as a fallback, but its prerequisites unconditionally require both an installed GitHub CLI and a successful gh auth status.

Those contracts conflict. A connector-backed publish can have everything it needs—local git for branch/commit/push plus the authenticated GitHub app for PR creation—yet the skill can stop before using that path because an unused fallback is unavailable.

Source: https://github.com/openai/plugins/blob/main/plugins/github/skills/yeet/SKILL.md

What steps can reproduce the bug?

  1. Run Codex in the elevated native Windows sandbox.
  2. Connect and authenticate the GitHub plugin.
  3. Use a local repository whose Git remote can fetch and push successfully.
  4. Store GitHub CLI authentication in the normal Windows keyring.
  5. Keep GH_TOKEN and GITHUB_TOKEN unset.
  6. Invoke the publish skill for a same-repository branch and PR.

gh auth status can report that the token is invalid inside the sandbox because the isolated sandbox identity cannot read the user's Windows keyring. The exact command succeeds outside the sandbox, confirming the credential itself is valid. Even though PR creation is covered by the connected GitHub app, the unconditional prerequisite makes the skill diagnose an authentication failure or request an unnecessary login.

What is the expected behavior?

  • Require a local Git repository and confirmed publish scope unconditionally.
  • Use local git for branch, commit, and push.
  • Prefer the connected GitHub app for supported repository and PR operations.
  • Require gh, and verify its authentication, only after selecting a specific CLI fallback that actually needs it.
  • If a sandboxed CLI auth check fails, distinguish sandbox/keyring access from an invalid credential before recommending re-authentication.

Additional information

A minimal one-file patch is published here:

https://github.com/startwithwater/plugins/commit/621238fb2130840f46a6581dfe493f40e7d2f6e5

It removes the two unconditional gh prerequisites, moves the checks to the actual fallback boundary, and prefers GitHub app metadata when resolving the base branch.

openai/plugins has Issues disabled, and GitHub rejected creation of a cross-fork PR with createPullRequest permission denied, so this tracker is the available public report channel.

The fix should not recommend globally exporting GH_TOKEN or storing a token in plaintext.

View original on GitHub ↗

1 Comment

JamesXNelson · 12 days ago

I hit the same underlying issue in Codex’s Linux network sandbox and prepared a broader follow-up patch:

https://github.com/JamesXNelson/gpt-plugins/commit/bcce6b76bdbd88c352d6901256bf03d479ec1359

In my case, gh auth status -h github.com reported an invalid token inside the sandbox, while the same check outside the sandbox succeeded and a read-only gh api -i user returned HTTP 200. Git fetch/push were using SSH independently of the PAT, and the connected GitHub app could create the PR, so repeated login requests were unnecessary.

The patch keeps connector-first publishing and adds explicit handling for:

treating gh auth status, gh api, and other gh calls as network operations;
retrying sandboxed auth/network failures outside the sandbox before diagnosing credentials;
never requesting login based only on a sandboxed failure;
requiring gh authentication only when an actual CLI fallback is selected;
distinguishing SSH Git credentials from gh PAT authentication and handling HTTPS separately;
accepting empty classic X-OAuth-Scopes headers for fine-grained PATs;
using safe read-only identity, repository-permission, and expiration-header diagnostics;
never exposing the complete token.

agents/openai.yaml is unchanged because the triggering/display contract did not change.

If cross-fork PR creation is still unavailable for openai/plugins, please feel free to cherry-pick the commit or point me at the preferred contribution route.