Codex GitHub Plugin Shows Zero Repositories? Fix Repository Access

If the Codex GitHub plugin says your account is connected but discovers zero repositories, and a write then fails with 403 Resource not accessible by integration, stop reconnecting the same account. GitHub user authorization and GitHub App installation are separate access layers. A successful sign-in does not prove that the app is installed on the repository owner or allowed to access the target repository.

A fresh Codex report shows this exact split: reconnecting appeared to succeed, repository discovery returned zero installations, and GitHub showed no app installation on the target repository. The safe fix is to verify the app installation and repository selection in GitHub, obtain organization approval when required, and retest with a read-only repository lookup before attempting another write.

Separate Account Authorization From Repository Installation

GitHub documents two distinct grants:

• Authorization lets an app identify you and act on your behalf within the account permissions you approved.

• Installation places the GitHub App on a personal account or organization and defines which repositories it can access.

You can authorize an app without installing it, and you can install it without authorizing it. That is why a connector can look connected while its repository inventory is empty.

Use the observed boundary to choose the next check:

Do not treat a successful local clone or gh command as proof that the connector has access. Local Git, GitHub CLI, OAuth authorization, and a GitHub App installation can all use different credentials.

Preserve the Failure Before Changing Access

Record the smallest useful evidence:

1. Codex app and CLI versions.

2. GitHub plugin version.

3. Repository owner and repository name.

4. Whether discovery returns zero repositories, omits only the target, or includes it.

5. The exact operation that returned 403.

6. Whether GitHub lists the app under the personal account or organization that owns the repository.

Do not paste tokens, cookies, authorization headers, or private repository contents into a support issue. The repository name can also be redacted if the failure reproduces against a disposable public test repository.

Verify the GitHub App Installation

Open GitHub in the browser and inspect the account that owns the target repository. For a personal repository, review the user's installed GitHub Apps. For an organization repository, have an organization owner review the organization's installed GitHub Apps and third-party access policy.

Confirm all four conditions:

• the intended GitHub App is installed on the correct personal account or organization;

• the installation is active rather than only requested or awaiting approval;

• the installation includes the target repository, or is configured for all repositories; and

• the granted repository permissions cover the operation Codex is trying to perform.

If the app is absent, return to Codex's official GitHub connection flow and follow the installation or request link it provides. Do not guess a GitHub App slug or install an unrelated marketplace app. GitHub says organization members who cannot install an app can request installation from an owner, and the owner can change the requested repository selection before approving it.

If the app is already installed with Only select repositories, edit that installation and add only the repository Codex needs. Avoid switching to all repositories merely to make the error disappear.

Retest Discovery Before Retesting a Write

After the installation or repository selection changes, fully start a new Codex task. Ask for one read-only lookup:

Use the connected GitHub plugin. List the GitHub App installations available to this connection, then find OWNER/REPOSITORY and read its default branch and repository visibility. Do not create or edit files, issues, pull requests, comments, labels, settings, or workflows. If the repository is not visible, stop and report which access layer is missing.

Success means the target repository appears and its read-only metadata returns. If discovery still shows zero repositories, another write attempt will add noise without proving anything new. Recheck the selected GitHub owner, pending organization approval, and repository selection.

If the repository appears, ask the plugin to read one known file such as README.md. This confirms content-read access without changing external state.

Diagnose a Remaining 403 Without Broadening Credentials

GitHub returns 403 when a GitHub App token does not have the permission required by an endpoint. GitHub's permissions documentation also notes that a REST response can include X-Accepted-GitHub-Permissions, which identifies accepted permissions for the endpoint. The Codex plugin may not expose that header, so preserve the operation name and response rather than guessing.

Use this decision sequence:

1. Confirm that the target repository is visible through the connector.

2. Review the app's granted repository permissions in GitHub.

3. Compare the failing operation with the permission it requires, such as Contents, Issues, or Pull requests.

4. If an updated permission request is pending, have the installation owner review it.

5. Retry only the same bounded operation after access changes.

An older Codex report provides a useful control case: the connector returned the same 403 for issue creation while authenticated gh issue create succeeded against the same repository. That result isolated the connector credential path; it did not prove that every 403 has the same cause.

If GitHub CLI is already installed and authenticated, you can run a read-only comparison:

gh auth status
gh repo view OWNER/REPOSITORY --json nameWithOwner,visibility,viewerPermission

Do not install GitHub CLI, mint a personal access token, or broaden organization access solely for this comparison. If the local check succeeds while the connector cannot read the repository, report both sanitized results to the existing Codex issue.

Avoid These False Fixes

• Do not reconnect repeatedly without checking the GitHub App installation.

• Do not assume access to public repository pages grants connector write access.

• Do not replace a repository-scoped installation with all-repository access by default.

• Do not create a broad personal access token to bypass a missing GitHub App grant.

• Do not modify local Git remotes or SSH keys when connector discovery itself is empty.

• Do not run another write canary until read-only discovery and content access succeed.

Local Git can remain healthy while the connector is unavailable. Keep local credentials and connector credentials separate so a narrow app-installation problem does not become a wider credential change.

Verify the Repair

Use a fresh task and verify in order:

1. The connection lists at least one GitHub App installation.

2. The target repository appears in discovery.

3. The plugin reads repository metadata.

4. The plugin reads one expected file.

5. A user-approved, bounded write succeeds only if the original job requires it.

If steps 1 through 4 pass but step 5 still returns 403, the failure is no longer a zero-repository installation problem. Preserve the successful reads, failing operation, app permissions, version numbers, and UTC timestamp for the connector issue.

Monitor the Codex Fix With Aident Loadout

Aident Loadout can query the connected GitHub issue surface without placing a provider token in your prompt. Give Codex the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then use this bounded prompt:

Check my Aident Loadout account and Vault status. Find a connected read-only GitHub issue Action, inspect its current schema, and preflight it. Return the state, updated time, maintainer-authored comments, linked fixes, and release references for openai/codex issue 37330. Do not create or edit issues, post comments, change labels, change files, or ask me for a provider key.

Success is measurable: one current issue record returns, no GitHub write occurs, and no credential appears in the output. Ready to monitor the access fix safely? Set up Aident Loadout and run the read-only check.

Sources

• OpenAI Codex issue 37330: reconnect succeeds, discovery is empty, and writes return 403

• OpenAI Codex issue 21387: connector write returns 403 while authenticated GitHub CLI succeeds

• GitHub Docs: About using GitHub Apps

• GitHub Docs: Installing a GitHub App from a third party

• GitHub Docs: Requesting a GitHub App from an organization owner

• GitHub Docs: Choosing permissions for a GitHub App

Refresh this guide when issue 37330 changes state, Codex documents the GitHub plugin installation flow, the plugin exposes actionable installation or permission errors, or a fresh version no longer reproduces empty discovery after reconnect.