[codex-web] Code-review settings shows false global permission warning and 404 for unrelated org installation

Summary

Codex Web shows a global “Action required — Update your GitHub permissions to enable code reviews” warning even though code review is fully functional for the user's personal repositories.

Clicking Update selects an unrelated GitHub App installation owned by an organization where the user is only a regular member, then redirects to a personal-account installation URL that returns GitHub 404.

Environment

• Product: Codex Web
• Page: https://chatgpt.com/codex/cloud/settings/code-review
• Subscription: ChatGPT Pro
• Platform: macOS
• Browser: Brave
• GitHub App: ChatGPT Codex Connector

Account state

The authenticated GitHub identity has access to two ChatGPT Codex Connector installations:

1. A personal-account installation owned by the authenticated user.

   • It has the required permissions.
   • Personal repositories are enabled in Codex.
   • Automated Codex reviews complete successfully on pull requests.

2. A separate organization installation.

   • The authenticated user is a regular organization member, not an owner.
   • The user cannot manage or uninstall this organization-owned installation.
   • This organization is unrelated to the user's desired personal-repository code-review setup.

GitHub's Authorized GitHub App page reports that the connector is installed on both accounts, while Codex Settings → Connectors reports the connection as the personal GitHub identity.

Steps to reproduce

1. Authorize the ChatGPT Codex Connector with a GitHub identity that:
   • owns a healthy personal installation; and
   • is a non-owner member of an organization with a separate connector installation.
2. Confirm that Codex reviews a pull request in a personal repository successfully.
3. Open https://chatgpt.com/codex/cloud/settings/code-review.
4. Observe the global Action required permission warning.
5. Click Update.
6. Observe a redirect to:
   https://github.com/settings/installations/<ORGANIZATION_INSTALLATION_ID>
7. GitHub returns 404 because that user-scoped route does not represent a manageable personal installation and the user is not the organization owner.

Actual behavior

• A healthy personal installation is presented as globally requiring action.
• Personal code review continues to work despite the warning.
• The Update action targets an unrelated organization installation.
• The generated GitHub URL returns 404.
• Organization repositories appear disabled, but their installation state incorrectly produces a global warning above healthy personal repositories.
• GitHub provides no per-organization toggle on the user's app authorization page; revoking authorization would also break the healthy personal installation.

Expected behavior

• Evaluate permission health per installation/account rather than treating one inaccessible installation as a global blocker.
• Do not show a global permission warning when the installation serving the user's selected personal repositories is healthy.
• Scope warnings to the affected installation or repositories.
• Allow users to ignore/exclude an organization installation they do not own without leaving the organization or revoking their personal connector.
• Generate a route appropriate to the installation's account type and the user's role.
• If organization-owner approval is required, explain that in Codex instead of linking a non-owner to a GitHub 404.

Privacy

Account names, organization names, repository names, installation IDs, and screenshots are intentionally omitted. They can be provided privately to OpenAI if needed.

Possibly related

• #15274 — includes an organization permission-update flow that reaches GitHub 404, but the primary failure there is different.
• #36473 — requests clearer organization-installation links and state.
• #38146 — describes ambiguity when one GitHub identity can access multiple installations.

Start at Codex Web's code-review settings page and trace the connector installation selection and permission-warning flow described in the reproduction steps. Reproduce the case with healthy personal and unrelated organization installations, then verify that warnings and Update links are scoped to the affected installation and that non-owner organization users receive an appropriate explanation instead of a GitHub 404.