# GitHub MCP access for Cursor: who gets which repo

> GitHub MCP access for Cursor splits in two: GitHub grants the repositories, Elaichi governs which tools run and records every call.

**TL;DR** GitHub is not in Elaichi's catalog as of the October 2026 check. The route is adding GitHub's remote MCP server as your organization's own remote MCP connector, on the Gold plan. Repository-level permission comes from the GitHub account each engineer connects, not from an Elaichi rule. Elaichi's part is narrowing tools by role and recording every call in one audit log.

## Why the GitHub-in-Cursor request splits in two

An engineering lead asks for one thing. Cursor should reach the team's GitHub repositories. Each developer should reach only the repositories they already have. Written out as a search, it reads: GitHub MCP access for Cursor. It is two requests stacked on each other.

GitHub decides which repositories a person can touch. Nothing placed in front of GitHub widens that or narrows it. Elaichi decides something else: which tools reach GitHub, for which role, and what the audit log holds afterwards. One sentence of vocabulary before the rest: MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Mixing the two layers is the usual failure. A team writes a rule expecting it to cover a repository. The rule covers a tool name instead.

## Is GitHub in Elaichi's connector catalog?

No. On the catalog check of October 2026, GitHub is not in Elaichi's catalog. Datadog, Linear, GitLab, PostHog and Miro are in it as native MCP connectors. For those, the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it. GitHub is not one of them.

The route for GitHub is a remote MCP connector: your organization brings [GitHub's remote MCP server](/blog/github-mcp-server-for-a-company-with-sso/) in as its own connector. That needs the Gold plan and the connector:create permission. Among the built-in roles, only Org Owner and Org Admin hold it. It is also the one permission Elaichi flags as high trust, because connector governance binds a connector, not the host it calls.

The server must speak MCP over Streamable HTTP at a public HTTPS address with a real hostname. No IP literal, and no internal host. The URL cannot be changed after the connector is created, so a different server means a new connector. An organization can hold 25 of its own remote MCP connectors, and one connection can carry 500 tools. Test the connection yourself before you plan a rollout around it. [Running a vendor's MCP server behind Elaichi](/blog/vendor-mcp-servers-through-elaichi/) covers what that arrangement does and does not change.

## What GitHub MCP access for Cursor actually requires

Four pieces, in this order. One address in Cursor, https://api.elaichi.ai/mcp, the same string for every organization. One grant per developer: each person connects their client once and approves their own consent screen, and every call then acts as that person. Tools narrowed in Elaichi, by role. Repositories decided by GitHub, through the account each developer connected.

Cursor's own mechanics are documented. Cursor supports OAuth for MCP servers that require it. It reads remote servers from .cursor/mcp.json in a project or ~/.cursor/mcp.json in the home directory, with a url field ([Cursor MCP docs](https://cursor.com/docs/mcp), checked October 2026). Team admins distribute shared MCP servers from Dashboard > Plugins & MCPs, and MCP distribution and MCP policy are configured separately (same page, checked October 2026). For how that plays out across a whole team, see [one endpoint in Cursor instead of one per developer](/blog/cursor-mcp-one-endpoint-vs-per-developer/).

## Where repo-level permission actually comes from

From GitHub, through the account each developer connects. An Elaichi restriction rule has a mode, a target, a list of whole connectors and a list of single tools. It names connectors and tools. It does not name a repository, a branch or a GitHub organization.

Two consequences follow. A remote MCP connector discovers its tools per connection, using that connection's own credential, because different members' accounts can see different tools. A connection shared with other people runs every call on its owner's account, whoever makes the call. If each engineer's own GitHub permissions should apply, each engineer connects their own account. Nobody shares one connection around the team.

GitHub's own admin control for MCP sits elsewhere. Its MCP servers in Copilot policy is disabled by default, and it applies to users with a Copilot Business or Copilot Enterprise subscription ([GitHub docs](https://docs.github.com/en/copilot/concepts/context/mcp), checked October 2026). It is not the control that decides what Cursor reaches.

## Restriction one: turn off the tools nobody should run

On your organization's own remote MCP connector, the owner or a member with edit access can turn a tool off. They can also lower the tier Elaichi assigns it. A member with use access sees only the tools that are switched on. Each change writes a connector.tool_updated row to the audit log.

This is the blunt control, and it is the right first move. Tools that delete a repository or change organization settings come off the connector entirely, rather than being blocked role by role. A restriction rule targets a role, or one member. Nothing wider can be named as its target. So a connector-level switch is the only way to take one tool away from everybody in a single action.

Tiers matter here too. For a remote MCP tool, Elaichi reads the server's own annotations. Read-only makes it a read, and a tool explicitly marked non-destructive is a write. Anything else counts as destructive, including a tool with no annotations at all.

## Restriction two: a block rule per role, and the allowlist trap

Write the per-role rules next. To a restriction rule, a remote MCP tool is resource mcp with the upstream tool name as its method. The rule is evaluated for the person making the call.

Block rules are the safe default and the leaky one. A layer with only block rules has no allowlist, so everything it does not name passes. Block three write tools and the fourth stays reachable. An allow rule is tighter and sharper at once. Once a role carries any allow rule, every connector and tool that none of its allow rules names is blocked for that role, across the whole catalog. Give your Engineer role an allow rule for GitHub read tools and you also need allow rules for every other app that role uses.

Two timing facts belong in the rollout plan. A role, team, restriction or grant change reaches every surface in about two minutes. Revoking a share, disconnecting an account, and removing or suspending a member take effect on the next call. Removal or suspension also revokes that person's grants. A rule aimed at one member narrows rather than replaces: A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.

## Restriction three: choose the toolboxes at consent

The consent screen is the third control, and the one teams skip. "Run your connected tools" (mcp:tools) lets a client run every tier of connected tool, writes and deletes included. "Delete data and remove access" covers Elaichi's own deletes, not a connected app's. No checkbox on that screen holds Cursor to reading GitHub.

Two things do. One is a restriction. The other is the toolbox step. When "Run your connected tools" is ticked, consent offers "All my tools" or "Only the ones I pick". The second choice names one to 50 stored toolboxes the person can use. A grant limited to a toolbox of read tools reaches exactly those toolboxes, re-checked on every call.

Note what the client cannot do from its own side. In Elaichi, connected tools are never listed one by one, however few there are. A model finds them with search_tools and runs them with execute_tool. So a per-tool permission inside an AI client sees one execute_tool rather than one GitHub tool. Cursor asks for approval before using MCP tools by default ([Cursor MCP docs](https://cursor.com/docs/mcp), checked October 2026). That prompt cannot tell a GitHub read from a GitHub write. Per-app and per-tool control belongs in Elaichi.

## Can you lock a tool to one repository?

Only where the tool takes a repository argument, and only on calls that run through the toolbox entry carrying the lock. A toolbox entry can freeze an argument: the value is written into the entry, and frozen values win over whatever the caller sends.

Three limits before you lean on it. The freeze holds only on that entry, so the same tool reached another way uses that path's values. Anyone who can use the connection themselves also has the unfrozen tool in their All tools toolbox. The lock bites only when the connection's owner keeps the connection unshared, pins it into the entry, and shares the toolbox instead. And the AI can see that a value is frozen, and often see the value; what it cannot do is change it.

For a team where every engineer connects their own GitHub account, that shape does not apply. Their repository scope is GitHub's. [Restricting one tool or the whole app](/blog/per-tool-vs-per-app-restrictions/) is the decision sitting underneath this one.

## The audit query that proves it

One filter, and it is not the obvious one. Connected-tool calls sit in the audit log's Assistant category, because their action is assistant.toolbox_tool. The MCP category holds grants and OAuth events. Filtering to MCP shows who connected Cursor, not what Cursor ran.

Open the audit log, set the category to Assistant, set the actor to the engineer, and set a date range. Each connected-tool row records the acting person, the tool's advertised and catalog names, the connector and the connection the call reached. It also records the tool's classification, how approval was given, the surface (mcp for a client like Cursor), the MCP client's id and the outcome. List and search calls add a result count. The console resolves the client's name. It marks a name as self-reported unless the client is one of the seven Elaichi can verify, which include Cursor. The current view exports as CSV, up to 10,000 entries.

What the row does not hold: argument values, apart from the one path argument that names the object. A failed call records an error code, not the app's own error text. If you need a repository name on every line, take that from your GitHub records rather than Elaichi's. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) walks the fields one by one.

## When you do not need any of this

If GitHub is the only thing your engineers want in Cursor, you may not need a control plane. Each of them can configure one server with their own sign-in, and GitHub's permissions already hold. Cursor's MCP allowlist, an Enterprise feature, approves a configuration centrally. Adding a server to it does not push that server to anyone's machine ([Cursor enterprise docs](https://cursor.com/docs/enterprise/model-and-integration-management), checked October 2026).

The case for one address starts at the second and third app. Jira, Sentry, PagerDuty and Slack reached the same way. One set of role rules across all of them, one audit log to filter, and one removal when somebody leaves. [When you do not need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) is the honest version of that argument. If you are already past it, [MCP for coding agents across an engineering org](/blog/coding-agents-company-tools/) is the wider playbook. The catalog already carries engineering tools such as [Argo CD](/connectors/argocd/), governed the same way, with no server for anyone to build.

## FAQ

### Is GitHub in Elaichi's connector catalog?

No. On the catalog check of October 2026, GitHub is not in Elaichi's connector catalog. Datadog, Linear, GitLab, PostHog and Miro are in it as native MCP connectors. There the vendor runs its own MCP server, and Elaichi handles sign-in, access and audit. For GitHub, an organization on the Gold plan can add GitHub's remote MCP server as its own remote MCP connector. That needs the connector:create permission, which only Org Owner and Org Admin hold among the built-in roles.

### Can an Elaichi restriction limit an AI client to one GitHub repository?

No. An Elaichi restriction rule names whole connectors and single tools. It does not name repositories, branches or a GitHub organization. Repository-level permission comes from the account each person connects, because every call through a connection uses that connection's credential. Where a tool takes a repository argument, a toolbox entry can freeze that argument so callers cannot change it. The freeze only holds on calls that run through that entry.

### Does Cursor have a GitHub integration with repository permissions for a team?

Cursor reads MCP servers from .cursor/mcp.json in a project and ~/.cursor/mcp.json in the home directory. It supports OAuth for servers that require it, and Team admins distribute shared MCP servers from Dashboard > Plugins & MCPs (https://cursor.com/docs/mcp, checked October 2026). Repository permissions are not set in Cursor: they come from the GitHub account each developer signs in with. Restrictions on which tools may run are set in whatever governs the server, such as Elaichi.

### How long does a restriction change take to reach an AI client?

A restriction change reaches every surface in about two minutes, not on the client's next call. The same holds for role, team membership and access-grant changes. Revoking a share, disconnecting a connected account, and removing or suspending a member do take effect on the next call. Removing or suspending a member also revokes that person's grants, so their AI client stops working at that point.

### Which audit log filter shows GitHub tool calls made from Cursor?

Filter the audit log by the Assistant category, then by actor and date range. Connected-tool calls are recorded with the action assistant.toolbox_tool, which sits in the Assistant category. The MCP category holds OAuth grants and connection events rather than tool calls. Each row records the person, the tool, the connector, the connection the call reached, the surface, the MCP client's id and the outcome.

## Read next

- [GitHub MCP server for a company with SSO](/blog/github-mcp-server-for-a-company-with-sso/) — A GitHub MCP server for a company with SSO has two sign-ins to settle: your identity provider, and whose GitHub account the tool call actually runs as.
- [Linear MCP server for our engineering team](/blog/linear-mcp-server-for-our-engineering-team/) — A Linear MCP server for our engineering team changes whose account each call runs as, which tools stay on, and what the audit log keeps.
- [Outreach MCP access for sales team in Cursor](/blog/sales-team-cursor-outreach-sequences/) — Outreach MCP access for sales team work in Cursor: allow sequence reads, block bulk enrollment and mailbox sends, and freeze the sequence owner.