[BUG] Claude GitHub integration needs org-installation-only mode and must not access repos outside selected app installation
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Right now, the Claude GitHub App can be installed on a work org with access restricted to selected repos, but the user authorization flow can still authorize Claude against the user's broader GitHub identity. There is no clear way to say: "Claude may use only this work org installation and must not discover or access any personal repositories".
For coding agents, this is a serious permission-boundary problem. Many users have both work and personal GitHub access on the same GitHub account. If Claude can use a user authorization path to discover or access repositories outside the selected GitHub App installation, then selected-repo app installation is not a sufficient safety guarantee.
If the Claude GitHub App is installed only on a work org and only for selected repos, then Claude should have no access to private repositories under the personal GitHub account, even if authorized by GitHub user identity to use the connector.
What Should Happen?
One should be able to configure Claude like this:
- Install the Claude GitHub App on a work org.
- Restrict the installation to selected work repositories.
- Authorize their GitHub user only to bind/use that org installation.
- Ensure Claude cannot discover, read, write, clone, open PRs against, or otherwise operate on any repository outside that selected installation scope.
In other words, the effective repository allowlist should be selected repos in the selected GitHub App installation, not anything the GitHub user can access.
Error Messages/Logs
Steps to Reproduce
The GitHub authorization flow does not provide a clear option to bind Claude only to a selected org installation.
There is no UI to say "authorize this app only for the work org installation" or "exclude my personal repositories".
This creates ambiguity about whether Claude is limited to the selected GitHub App installation or whether it can also use user-authorized access to reach other repositories available to the user.
In testing, Claude appeared able to access personal repositories even though the Claude app was not installed on the personal GitHub account. The integration is using the user authorization path, not only the selected GitHub App installation path.
Claude Model
_No response_
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
*
Platform
Anthropic API
Operating System
Other
Terminal/Shell
Other
Additional Information
Why this matters
For AI coding agents, "act on my behalf" is not a minor convenience permission. It is the core attack surface.
Repo-scoped GitHub App installation gives users the impression that access is limited to selected repositories. If the connector can also use a user authorization path to reach repos outside that installation, then the user-facing permission model is misleading and unsafe for anyone who uses the same GitHub account for work and personal repos.
This blocks safe adoption for users who want Claude on work repositories but do not want to expose personal repositories.
Requested fix
Please add a strict access mode with these guarantees:
- Allow users to bind Claude to a specific GitHub App installation, e.g. one org installation.
- Show the effective repository allowlist before authorization.
- Do not allow any user-token fallback to discover, read, write, clone, or operate on repositories outside that selected installation scope.
- Provide a clear UI distinction between identity authorization and repository/content authorization.
- Fail closed if a repo is not included in the selected installation.
Suggested product labels:
- "Use only this GitHub App installation"
- "Org-installation-only access"
3 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I don't think this is a duplicate of #71857.
#71857 is about org MCP connectors being attached to unmanaged personal Claude accounts. The core issue there is account/container governance: org tools can be used from a personal Claude account after OAuth succeeds with valid org identity.
This issue is about a different boundary: GitHub repository authorization. The concern is that the Claude GitHub integration appears able to discover/access repositories outside the selected GitHub App installation scope, via user authorization. In other words, even if the GitHub App is not installed on my personal GitHub account, and the work org installation is restricted to selected repos, Claude may still see personal repos available to my GitHub user.
The requested fix is also different:
They are related because both are permission-boundary problems for agent connectors, but they are not the same bug and would not necessarily be fixed by the same product change.
Thanks for the detailed writeup, and for separating identity authorization from repository/content authorization — that framing is the useful part here.
I looked at this against 2.1.233 on Linux. What you observed is the documented behavior today rather than a defect: cloud sessions act as the connected GitHub account, so a session can reach any repository that account can see. Installing the Claude GitHub App on selected repositories enables pull request webhooks for auto-fix; it is not a session-level access control. The terminal setup path is user-token based by construction as well. See https://code.claude.com/docs/en/claude-code-on-the-web#github-authentication-options
I did not reproduce the work-vs-personal part directly — that needs a GitHub identity holding both a work org installation and personal private repositories, and I'm not connecting a real account from a test machine — so this is confirmed against the documented model, not by a repro.
That said, your expectation is a reasonable one: a repo-scoped app installation strongly implies a scoped agent, and today the only way to bound access is on GitHub's side, by limiting what the connected account can see. We're treating the installation-bound mode you describe — bind to one installation, show the effective repository allowlist before authorization, fail closed outside it — as a product gap and passing it to the team that owns the integration. Leaving this open to track that.
🤖 Generated with Claude Code