# Connect GitHub to Prodpeek

Profile: `github/code-read` · connection kind: `http` · tier 1
Credential: Fine-grained personal access token
Suggested URL: `https://api.githubcopilot.com/mcp/`

Read code, history and diffs from selected repositories. One connection per repository, each with a token that can reach only that repository.

## What you must not do

You cannot create this credential on the user's behalf — it needs their login and,
usually, an approval step. Walk them through it and verify the result. Never ask
them to paste the credential into the chat; it goes straight into Prodpeek's
console, which encrypts it at rest. You cannot create this token for the user — it requires their GitHub login and an approval step. Walk them through it and check the result.

## Grant exactly these permissions

- `Repository access → Only select repositories → pick ONE` — This is the whole scoping mechanism. The GitHub MCP endpoint is one URL for every repo — which repo a call touches is an argument, not part of the address — so the token is the only thing that makes a connection repo-specific.
- `Repository permissions → Contents → Read-only` — File contents, commit history, diffs, branches and tags.
- `Repository permissions → Pull requests → Read-only` — PR diffs and metadata. Omit it if you only want files and history.
- `Repository permissions → Metadata → Read-only` — Required by GitHub whenever any other repository permission is set.

## Refuse these, and say why if the user asks for them

- `Any permission set to Read and write` — One write permission ends the Tier 1 claim. The point of this token is that it cannot change anything even if something goes wrong upstream of it.
- `Secret scanning alerts` — Those alerts contain the detected secrets themselves. The profile denies the tools; do not hand the token the ability either.
- `Code scanning alerts` — A precise map of unfixed vulnerabilities in your own code.
- `Actions (workflow logs)` — CI logs are masked in the web UI and often not in the raw download — the classic place a secret escapes.
- `A classic PAT instead of a fine-grained one` — Classic tokens scope to whole accounts, not repositories. `repo` grants write to every repository you can reach. Fine-grained is not a preference here.

## Verify before the credential is used

- The token page lists exactly one repository under Repository access.
- Every permission reads Read-only. None reads Read and write.
- Expiry is set. A token for an agent should not outlive your attention to it.

## Then, in Prodpeek

1. Services → Add a service → choose the profile `github/code-read`.
2. Connection kind `http`, URL `https://api.githubcopilot.com/mcp/`.
3. Paste the credential. It is encrypted in the store and never shown again.
4. Run **Test connection**. It lists every tool the upstream advertises and how the
   profile classifies each one. Anything under "not in the policy" is denied by
   default — report that list rather than assuming it is fine.

## Full human walkthrough

## Why one token per repository

The hosted GitHub MCP endpoint is a single URL. Which repository a call reaches is
decided by the `owner` and `repo` arguments, not by the address you connect to. So
naming a Prodpeek connection `gh-api` does not stop it reading `gh-billing` — only
the token does.

That is why the shape here is one connection per repository, each with its own
fine-grained token scoped to exactly that repository. A project spanning four repos
is four connections in the same Prodpeek project. It is slightly more setup, and it
is the difference between "we asked it not to" and "it cannot".

## Steps

1. Go to **Settings → Developer settings → Personal access tokens → Fine-grained
   tokens** and choose **Generate new token**. (Direct link:
   `https://github.com/settings/personal-access-tokens/new`.)

2. Name it for the connection you are about to create — `prodpeek-<repo>` — so that
   revoking the right one later is obvious.

3. Set an **expiry**. Ninety days is a reasonable default; a token wired into a
   gateway is exactly the kind that gets forgotten.

4. Under **Repository access**, choose **Only select repositories** and pick the one
   repository this connection is for. Not "All repositories".

5. Under **Repository permissions**, set:
   - **Contents → Read-only**
   - **Pull requests → Read-only** (skip if you only need files and history)
   - **Metadata → Read-only** (GitHub adds this automatically)

   Leave everything else at **No access**. In particular leave Secret scanning
   alerts, Code scanning alerts and Actions alone — the profile denies those tools,
   and a token that cannot reach them means the denial holds even if the profile is
   ever misconfigured.

6. Generate the token and copy it. GitHub shows it once.

7. In Prodpeek: **Services → Add a service**, choose **GitHub — code read**, name it
   after the repository, leave the URL at the suggested endpoint, and paste the
   token. Then **Test connection** — it lists what the endpoint advertises and how
   the profile classifies each tool.

## If you are adding several repositories

Repeat the whole thing per repository, including a new token each time. The "Add
another endpoint" button on a service card copies a connection's credential to a new
URL, which is right for a vendor that splits one account across endpoints
(DigitalOcean) — but wrong here: sharing a token across repositories is precisely
the scoping you just set up being undone.