›_ Codex Issues
Codex Issues / #24548

GitHub plugin connector shows unrelated installed accounts and a private repo after reinstall

Open 💬 2 comments Opened May 26, 2026 by fragpit

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.519.41501 (3044)

What subscription do you have?

chatgpt plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The official OpenAI GitHub plugin shows GitHub App installations for unrelated accounts after I removed my old manually configured GitHub MCP server and reinstalled the official GitHub plugin in Codex.

The connector reports two GitHub accounts that are not mine. It also returns repositories from those accounts, including a private repository with push=true.

This looks like a possible cross-account authorization or data isolation issue.

Environment:

  • Product: Codex Desktop / Codex app
  • Platform: macOS
  • Codex runtime: 0.133.0-alpha.1
  • Auth mode: ChatGPT auth
  • Plugin: github@openai-curated
  • GitHub plugin version: 0.1.0
  • Plugin repository from manifest: https://github.com/openai/plugins

What steps can reproduce the bug?

  1. Remove the old manually configured GitHub MCP servers from config.toml.
  2. Reinstall or enable the official OpenAI GitHub plugin, github@openai-curated.
  3. Restart Codex.
  4. Run codex doctor --json.
  5. Confirm that the old GitHub MCP server is gone. In my case, codex doctor shows one configured MCP server and mcp.config = ok.
  6. Call the official GitHub connector tool _list_installed_accounts.
  7. Actual result: it returns unrelated GitHub accounts.
  8. Call _list_installations.
  9. Actual result: it returns GitHub App installations for those unrelated accounts.
  10. Call _search_installed_repositories_v2("my-github-username").
  11. Actual result: it returns an empty list.
  12. Call _search_installed_repositories_v2("a").
  13. Actual result: it returns repositories from an unrelated account, including a private repository with push=true.

Additional observation:

Direct lookup for my public repositories can return metadata and permissions, but installed-account search still shows unrelated accounts. This suggests that different connector methods may be using inconsistent auth or installation state.

What is the expected behavior?

The GitHub connector should only show GitHub App installations and repositories for the GitHub account connected to my Codex account.

It should not show unrelated user accounts, unrelated GitHub App installations, or private repositories belonging to other users.

If the connector is not connected to my intended GitHub account, it should show a clear disconnected or re-authentication-required state, not another user's installations.

Because the connector returned an unrelated private repository with write permissions, please advise whether this should be handled as a private security report and what diagnostic bundle is safe to provide.

Additional information

_No response_

View original on GitHub ↗

2 Comments

SylvainWinning · 3 months ago

Given the expected behavior here involves another user's private repository and apparent write permission, I would treat this as potentially security-sensitive even if the root cause later turns out to be stale connector state or a UI/account mix-up.

The repo's SECURITY.md points security issues to OpenAI's Bugcrowd program. Until a maintainer says otherwise, I would avoid posting account names, installation IDs, repository names, raw connector responses, access tokens, or diagnostic bundles publicly in this issue.

One detail that may help triage without exposing private data: the local client code appears to preserve connector metadata only for the trusted Codex Apps MCP server and strips connector metadata from non-Codex MCP servers. So if _list_installed_accounts / _list_installations themselves return unrelated accounts from the official GitHub connector, this likely needs investigation at the connector auth/install-state boundary rather than only in custom MCP metadata normalization.

mh105 · 1 month ago

I can reproduce and explain one path behind this behavior. User A owns a private repository. User B creates a private fork and installs the Codex GitHub App on their personal account with access to that fork. GitHub’s GET /user/installations response for User A then includes User B’s App installation, because User A has explicit access to the private fork network. The Codex connector consequently returns User B as an accessible installation, with the fork as the single overlapping repository.

This may be consistent with GitHub’s API semantics, but presenting the raw result as connected/accessible installations is confusing and potentially unmanageable for private repositories with many personal forks. Codex should distinguish installations owned or administered by the authenticated user from third-party installations visible only through a shared repository or private fork. Ideally these should be filtered, grouped separately, or accompanied by an explanation of why each installation is visible.