Claude Code with GitHub Enterprise Server: Setup and Limits

Claude Code connects to GitHub Enterprise Server (GHES), the self-hosted version of GitHub, on Team and Enterprise plans. An Owner in your Claude organization connects the instance once. After that, developers run cloud sessions and get automated pull request reviews on GHES repositories without configuring anything per repository. Claude Code reads the GHES hostname from the git remote in your working folder, so the day-to-day workflow looks the same as it does on github.com.

Local work needs none of this. If you open a GHES checkout in the desktop app or the terminal, Claude Code edits files and runs git with your own credentials like any other repo. The connection matters for the parts that run on the Anthropic side: cloud sessions, Code Review, and plugin marketplaces added through claude.ai.

The GitHub MCP server gap sounds bigger than it is. Run gh auth login --hostname with your GHES hostname, and Claude can use gh commands in its sessions to read issues, open pull requests and check CI. My take: the gh CLI is the better route anyway, because it is the same tool your developers already use against GHES.

You need the Owner or Primary Owner role in your Claude organization, plus permission to create GitHub Apps on your GHES instance. If those are two different people, get them on the same call. The setup takes minutes when both are in the room and days when they are not.

If your network blocks the redirect, choose Add manually instead. You create the GitHub App on GHES yourself with the same permissions, then paste the app ID, client ID, client secret, webhook secret and private key into the form. Claude generates the webhook URL after you save, and you copy it into the app's webhook settings on GHES with the same webhook secret.

For sessions that Anthropic hosts, your GHES instance has to be reachable from Anthropic infrastructure. That is how Claude clones your repos and posts review comments. If GHES sits behind a firewall, your network team needs to allowlist the published Anthropic outbound IP addresses. Allow all of them, not a sample: a connection test can pass even when the firewall blocks some.

Self-hosted environments clone from inside your own network instead, so they do not need that inbound access for the session itself. The catch is the steps that run before a session starts, like the repository picker. Those always run on the Anthropic side, so they still need to reach your GHES host. If your GHES is only routable internally, plan for that before you promise anyone cloud sessions.

This is separate from the proxy setup on each laptop. If your developers also sit behind a corporate proxy, the corporate proxy guide covers the variables and certificates for their local Claude Code.

Clone from GHES the way you always do. Open the folder in the Claude desktop app, which is where I tell most people to start, and work locally as normal. When you want a task to run in the cloud instead of on your laptop, the desktop app can send a local session to the cloud from its Open in menu. From the terminal, claude --cloud with a task description starts a new cloud session for the current repository. Claude reads the GHES host from your git remote and routes the session through your organization's connected instance.

The cloud session clones from GHES, does the work and pushes to a branch. You follow along at claude.ai/code, and when it is done you open a pull request there or run claude --teleport in your local checkout to pull the session down and keep going. Teleport checks that you are in a checkout of the same GHES repository before it fetches the branch. Claude Code on the web covers the cloud workflow in full, and the Code Review guide covers what the automated reviews look for.

This is the part I like most for teams. Host a plugin marketplace repo on GHES and you can ship your internal skills, commands and hooks to every developer. The structure is the same as a github.com marketplace. What changes is how each surface gets credentials.

Two rules save you an afternoon. First, always use the full git URL, because the owner/repo shorthand always points at github.com. Second, prefer HTTPS with your normal git credential helper. Claude Code runs git non-interactively and rejects SSH connections to hosts that are not already in the machine's known_hosts file, so SSH URLs fail quietly on fresh laptops.

For a company rollout, my pick is managed settings. Put the marketplace in extraKnownMarketplaces with a git source and the HTTPS URL, push it to every machine through your device management, and nobody has to add anything by hand. If you also restrict which marketplaces people can add, a strictKnownMarketplaces entry with a hostPattern source allows every marketplace on your GHES host without listing each repo. Claude Code plugins explained covers what goes inside the marketplace, and the settings.json guide covers where settings live.

One trap deserves its own line. On the claude.ai Browse tab, the Connect to GitHub option signs you in to github.com. It does not give access to GHES repos. Connect your GitHub Enterprise account from the repository picker instead, or, if you are an Owner, from the GitHub section of the Git providers page.