Serwer GitHub MCP: zdalnie, lokalnie, toolsety i tryb lockdown

Serwer GitHub MCP to oficjalny serwer Model Context Protocol od GitHuba. Pozwala Claude Code, Codex i Cursorowi czytać i zmieniać pull requesty, zgłoszenia (issues), logi GitHub Actions i alerty bezpieczeństwa. Hostowany endpoint https://api.githubcopilot.com/mcp/ działa z tokenem PAT. Liczy się zakres: tylko toolsety (zestawy narzędzi) potrzebne do zadania i tryb lockdown w repozytoriach publicznych.

PR #412 świeci na czerwono od lunchu. Padający job to 4000 linii logu, recenzent zostawił sześć komentarzy, a ty wolałbyś oddać całą pętlę agentowi, zamiast wklejać logi do czatu. Agent to zrobi, ale tylko wtedy, gdy przeczyta logi Actions i wątki review, i tylko wtedy, gdy ufasz temu, co wolno mu wypchnąć i zmergować.

Ten artykuł jest dla programistów, którzy podpinają serwer do własnego agenta, i dla tech leadów, którzy ustalają wspólną konfigurację: jaki token, jakie toolsety i których narzędzi agent nie wywoła nigdy.

Sprawdzone 26 września 2026

Polecenia sprawdzono na Claude Code 2.1.283 i codex-cli 0.157.1 oraz w README github/github-mcp-server, przewodniku po serwerze zdalnym, przewodniku po konfiguracji serwera i instrukcjach instalacji, czytanych 2026-09-26. W środowisku autora nie ma Cursora, więc jego konfiguracja pochodzi z przewodnika GitHuba dla Cursora, a nie z lokalnego testu. Popularność na 2026-09-26: 33,2 tys. gwiazdek na GitHubie (GitHub API), wpis w Official MCP Registry io.github.github/github-mcp-server 1.12.2 oraz 319 381 instalacji wtyczki github w katalogu Claude Marketplace.

Co daje dobrze zawężony serwer GitHub MCP

• Przetestowaną instalację w Claude Code, Codex i Cursorze, która trzyma token poza repozytorium.
• Tabelę uprawnień PAT, która daje każdemu przepływowi tylko te uprawnienia, których używa.
• Ustawienia toolsetów, wykluczeń i trybu lockdown, które odsłaniają tylko to, czego potrzebuje zadanie, i filtrują treści od obcych.
• Prompty, które zamieniają czerwony pull request w wypchniętą poprawkę i odpowiadają na wątki review, bez merge’a.
• Odpowiedniki dla GitLaba, dla zespołów, które tam trzymają kod.

Czy agent ma używać GitHub MCP, czy CLI gh?

Wszyscy trzej agenci uruchamiają polecenia w powłoce, więc gh i lokalny git są dostępne bez żadnego serwera MCP. Serwer GitHub MCP opłaca się wtedy, gdy agent potrzebuje typowanego, stronicowanego dostępu do stanu GitHuba albo działa tam, gdzie nie ma powłoki. Wiele zespołów używa obu.

Zadanie	Najlepsza droga	Dlaczego
Commit, gałąź, rebase, diff w katalogu roboczym	Lokalny git przez powłokę agenta	Najszybciej, bez wywołań API i bez tokena
Przeczytanie jednego padającego logu CI	gh run view RUN_ID --log-failed albo get_job_logs z failed_only i tail_lines	gh kosztuje mniej tokenów; narzędzie MCP samo przycina log
Przeczytanie wątków review i odpowiedź w każdym	GitHub MCP (pull_request_read z metodą get_review_comments, add_reply_to_pull_request_comment, pull_request_review_write z metodą resolve_thread)	Identyfikatory wątków i odpowiedzi trudno oskryptować przez gh
Triaż 50 zgłoszeń do tabeli	GitHub MCP (search_issues, issue_read)	Ustrukturyzowane wyniki, stronicowanie po stronie serwera
Agent bez powłoki (desktopowy klient czatu, agent hostowany)	GitHub MCP	Jedyna droga
Ustrukturyzowana historia gita w kliencie, który nie uruchomi git	Referencyjny serwer Git, uvx mcp-server-git --repository . (tylko PyPI)	Zobacz referencyjne serwery MCP

gh i serwer MCP korzystające z tego samego tokena zużywają ten sam budżet: podstawowy limit dla uwierzytelnionych użytkowników wynosi 5000 żądań na godzinę na github.com.

Zdalnie czy lokalnie: który serwer GitHub MCP uruchomić?

GitHub publikuje jeden kod w dwóch postaciach. Serwer zdalny to domyślny wybór; lokalny jest dla GitHub Enterprise Server, maszyn bez dostępu do sieci zewnętrznej i zespołów, które chcą OAuth bez tokena PAT.

	Zdalny (https://api.githubcopilot.com/mcp/)	Lokalny (obraz Docker ghcr.io/github/github-mcp-server lub binarka z releases)
Uwierzytelnianie w Claude Code, Codex, Cursorze	PAT w nagłówku Authorization: Bearer, zgodnie z przewodnikami GitHuba. OAuth działa tylko w hostach, które zarejestrowały GitHub App lub OAuth App	Logowanie OAuth w przeglądarce wbudowane w oficjalny obraz, bez tokena; token tylko w pamięci. PAT w GITHUB_PERSONAL_ACCESS_TOKEN ma pierwszeństwo. Tylko github.com; GitHub Enterprise Server i ghe.com wymagają własnej aplikacji OAuth lub GitHub App albo tokena PAT
Zawężanie toolsetów	Ścieżka /mcp/x/TOOLSET i /readonly albo nagłówki X-MCP-Toolsets, X-MCP-Tools, X-MCP-Exclude-Tools, X-MCP-Readonly	Flagi --toolsets, --tools, --exclude-tools, --read-only lub GITHUB_TOOLSETS, GITHUB_TOOLS, GITHUB_EXCLUDE_TOOLS, GITHUB_READ_ONLY
Tryb lockdown	Nagłówek X-MCP-Lockdown: true	--lockdown-mode lub GITHUB_LOCKDOWN_MODE=1
GitHub Enterprise	Enterprise Cloud z rezydencją danych pod https://copilot-api.SUBDOMAIN.ghe.com/mcp; nie Enterprise Server	Oba, przez --gh-host lub GITHUB_HOST (wymuszony HTTPS)
Dodatkowe narzędzia	create_pull_request_with_copilot, Copilot Spaces, github_support_docs_search	Niedostępne
Wymaga	Niczego nie instalujesz	Działającego Dockera albo binarki w PATH

Zainstaluj serwer GitHub MCP w Claude Code, Codex i Cursorze

Serwer zdalny działa tak samo u wszystkich trzech agentów: jeden adres URL i token typu bearer. Różni się tylko składnia konfiguracji.

1. Utwórz fine-grained personal access token w Settings > Developer settings > Personal access tokens, ograniczony do repozytoriów, na których pracuje agent. Uprawnienia wybierz z tabeli w następnej sekcji.

2. Wyeksportuj go w profilu powłoki, a nie w pliku wewnątrz repozytorium:

   # ~/.zshrc lub ~/.bashrc
   export GITHUB_PAT="github_pat_..."

3. Zarejestruj serwer w agencie:

   Claude Code

   # Terminal. Zakres project zapisuje .mcp.json; pojedyncze cudzysłowy zostawiają ${GITHUB_PAT}
   # nierozwinięte, więc zespół współdzieli plik, a każdy podaje własny token.
   claude mcp add -s project --transport http github https://api.githubcopilot.com/mcp/ \
     -H 'Authorization: Bearer ${GITHUB_PAT}'

   Przetestowane na 2.1.283: wynikowy .mcp.json zawiera "Authorization": "Bearer ${GITHUB_PAT}", a Claude Code rozwija zmienną przy łączeniu. Bez -s project wpis trafia do domyślnego zakresu local i zostaje tylko u ciebie.

   Codex

   # Terminal. Zapisuje [mcp_servers.github] w ~/.codex/config.toml
   codex mcp add github --url https://api.githubcopilot.com/mcp/ \
     --bearer-token-env-var GITHUB_PAT

   Przetestowane na 0.157.1. Codex czyta token ze zmiennej przy każdym połączeniu, więc w config.toml nie ląduje nic tajnego.

   Cursor

   W ~/.cursor/mcp.json, globalnym pliku użytkownika. Nigdy go nie commituj:

   {
     "mcpServers": {
       "github": {
         "url": "https://api.githubcopilot.com/mcp/",
         "headers": { "Authorization": "Bearer ${env:GITHUB_PAT}" }
       }
     }
   }

   To kształt z przewodnika GitHuba dla Cursora, według którego serwer GitHuba w Cursorze „currently requires a Personal Access Token”, choć Cursor obsługuje OAuth dla innych serwerów. Interpolacja ${env:NAZWA} pochodzi z dokumentacji Cursora cytowanej w naszym researchu (źródło wtórne, bez testu w Cursorze), więc zrestartuj Cursora i sprawdź w Settings > MCP, czy github pokazuje narzędzia.

4. Sprawdź połączenie. W Claude Code uruchom claude mcp get github (wykonuje health check) albo /mcp w sesji. W Codex uruchom /mcp w TUI. W Cursorze otwórz sekcję MCP w ustawieniach i sprawdź, czy github pokazuje narzędzia. Potem zapytaj agenta: Call get_me and tell me which GitHub user you are authenticated as.

Instalacja przez wtyczkę

Wtyczka dostarcza ten sam serwer zdalny bez pisania JSON-a. Każda wtyczka oczekuje innej nazwy zmiennej i to najczęstszy powód, dla którego po instalacji nie widać żadnych narzędzi.

Agent	Polecenie	Zmienna z tokenem
Claude Code	claude plugin install github@claude-plugins-official	GITHUB_PERSONAL_ACCESS_TOKEN (dokładnie ta nazwa)
Codex	codex plugin add github@openai-curated	GITHUB_PAT_TOKEN
Cursor	/add-plugin github	Nieudokumentowana w naszych źródłach; sprawdź mcp.json wtyczki

Wtyczka dla Codex jest na liście kuratorowanego marketplace’u OpenAI, ale 2026-09-26 nie przetestowano pełnej instalacji w zalogowanym Codex; jeśli się nie uda, użyj polecenia codex mcp add z kroku 3.

Lokalny serwer w Dockerze z OAuth, bez tokena

Żeby w ogóle pominąć PAT, uruchom serwer lokalnie. Oficjalny obraz zawiera dane aplikacji OAuth GitHuba, przy pierwszym użyciu otwiera logowanie w przeglądarce i potrzebuje stałego portu callbacku wystawionego na loopback:

# Claude Code, terminal (polecenie z dokumentacji GitHuba)
claude mcp add github -e GITHUB_OAUTH_CALLBACK_PORT=8085 -- docker run -i --rm \
  -p 127.0.0.1:8085:8085 -e GITHUB_OAUTH_CALLBACK_PORT ghcr.io/github/github-mcp-server

W Codex i Cursorze podajesz te same argumenty docker run jako command/args, z GITHUB_OAUTH_CALLBACK_PORT = "8085" w env. Bez wystawionego portu serwer przechodzi na device-code flow GitHuba i wypisuje kod do wpisania na github.com/login/device.

GitHub Copilot CLI ma go od razu

Copilot CLI ma serwer GitHub MCP preinstalowany jako github-mcp-server, z domyślnie włączonymi narzędziami tylko do odczytu. Sprawdzisz go przez /mcp show github-mcp-server, poszerzysz na sesję przez copilot --add-github-mcp-toolset actions, a wyłączysz przez copilot --disable-builtin-mcps. Artykuł o GitHub Copilot opisuje cloud agenta, którego serwer GitHuba używa tokena tylko do odczytu, ograniczonego do bieżącego repozytorium.

Jakich uprawnień PAT potrzebuje serwer GitHub MCP?

Serwer zrobi tyle, na ile pozwala token, i nic więcej, więc to token jest twoją prawdziwą granicą uprawnień. Nadawaj je według zadania:

Zadanie	Scope klasycznego PAT	Uprawnienie fine-grained PAT (tylko wybrane repozytoria)
Odczyt kodu, zgłoszeń, PR-ów, logów CI	repo	Contents, Issues, Pull requests, Actions: read
Komentarze, otwieranie PR-ów, wypychanie plików	repo	Contents, Issues, Pull requests: read and write
Zmiana pliku w .github/workflows/	repo + workflow	Workflows: read and write
Zespoły i członkowie organizacji	read:org	Members (uprawnienie organizacji): read
Gisty, powiadomienia, klasyczne projekty	gist, notifications, project	odpowiednie uprawnienie

Zanim zaczniesz szukać brakującego narzędzia, pamiętaj o dwóch zachowaniach:

• Klasyczny PAT filtruje narzędzia przy starcie. Serwer odczytuje scope’y tokena z nagłówka X-OAuth-Scopes i ukrywa narzędzia, które wymagają scope’u, którego nie nadałeś. Token z samym repo nie pokaże narzędzi do gistów ani powiadomień. Scope’y tokena sprawdzisz poleceniem curl -sI -H "Authorization: Bearer $GITHUB_PAT" https://api.github.com/user | grep -i x-oauth-scopes.
• Fine-grained PAT pokazuje wszystkie narzędzia. API egzekwuje uprawnienia przy wywołaniu, więc agent widzi narzędzie, wywołuje je i dostaje 403. To oczekiwane zachowanie; listę narzędzi zawężaj toolsetami.

Ogranicz serwer GitHub MCP do toolsetów potrzebnych w zadaniu

Bez konfiguracji serwer ładuje domyślne toolsety: context, repos, issues, pull_requests i users. Naprawa CI potrzebuje jeszcze actions; triaż nie potrzebuje niczego, co zapisuje. Mniej narzędzi to lepszy wybór narzędzia przez model i mniej miejsca na pomyłkę.

Na serwerze zdalnym masz dwie dźwignie:

• Ścieżka URL, jeden toolset na adres: https://api.githubcopilot.com/mcp/x/actions, a na końcu dowolnego z nich /readonly (https://api.githubcopilot.com/mcp/x/actions/readonly, https://api.githubcopilot.com/mcp/readonly).
• Nagłówki, do łączenia: X-MCP-Toolsets: repos,issues,pull_requests,actions, X-MCP-Tools dla pojedynczych narzędzi, X-MCP-Readonly: true.

Ścieżka przyjmuje tylko jeden toolset, więc konfiguracja do naprawy CI, która łączy kilka, używa nagłówka:

Claude Code

claude mcp add -s project --transport http github https://api.githubcopilot.com/mcp/ \
  -H 'Authorization: Bearer ${GITHUB_PAT}' \
  -H "X-MCP-Toolsets: context,repos,issues,pull_requests,actions" \
  -H "X-MCP-Lockdown: true"

Codex

~/.codex/config.toml

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
bearer_token_env_var = "GITHUB_PAT"
http_headers = { "X-MCP-Toolsets" = "context,repos,issues,pull_requests,actions", "X-MCP-Lockdown" = "true" }

Klucz to http_headers. Codex po cichu ignoruje klucz headers i toolsety nigdy nie docierają do serwera (przetestowane na 0.157.1 przez codex mcp get github --json).

Cursor

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${env:GITHUB_PAT}",
        "X-MCP-Toolsets": "context,repos,issues,pull_requests,actions",
        "X-MCP-Lockdown": "true"
      }
    }
  }
}

Na serwerze lokalnym to samo zawężenie daje --toolsets context,repos,issues,pull_requests,actions (lub GITHUB_TOOLSETS), plus --read-only. Tryb tylko do odczytu wygrywa z jawną listą --tools: narzędzie zapisujące, które wymienisz, i tak zostanie pominięte.

Ile kontekstu kosztuje serwer GitHub MCP

Tool search jest domyślnie włączony w Claude Code i Codex, więc schematy ładują się na żądanie. claude plugin details github pokazuje stały koszt bliski zera tokenów, ale to polecenie nie liczy schematów narzędzi MCP (sprawdzone na 2.1.283), więc mierz przez /context. Boli dopiero wynik narzędzia: pełny log Actions albo lista 30 zgłoszeń ląduje w oknie kontekstu. Uruchom /context w Claude Code przed naprawą CI i po niej, żeby to zobaczyć, i każ agentowi wywoływać get_job_logs z failed_only: true i ustawionym tail_lines, tak jak w promptcie poniżej. Więcej o przycinaniu wyników przeczytasz w artykule o obniżaniu kosztu tokenów MCP.

Włącz tryb lockdown w repozytoriach publicznych

Agent, który czyta zgłoszenia i komentarze w publicznym repozytorium, czyta tekst pisany przez obcych, a ten tekst może zawierać instrukcje. Tryb lockdown to filtr GitHuba na tę sytuację: w repozytoriach publicznych serwer sprawdza, czy autor każdego elementu ma uprawnienie push, i ukrywa treści od osób, które go nie mają. Repozytoriów prywatnych to nie dotyczy.

Co agent widzi w trybie lockdown:

• issue_read (get) i pull_request_read (get, get_diff, get_files, get_commits) zwracają błąd, gdy autor nie ma uprawnienia push.
• Komentarze, pod-zgłoszenia, komentarze review i same review są filtrowane: elementy od osób bez uprawnienia push znikają.
• Treści od github-actions[bot] i copilot zawsze przechodzą, więc wyniki CI pozostają widoczne.

Włączasz go przez --lockdown-mode lub GITHUB_LOCKDOWN_MODE=1 lokalnie albo nagłówek X-MCP-Lockdown: true na serwerze zdalnym. W trybie HTTP flaga operatora jest górną granicą: nagłówek może lockdown włączyć, ale nie wyłączyć.

Tryb lockdown nie jest granicą autoryzacji

GitHub pisze wprost, że lockdown to „a best-effort content filter”, który „does not change what the underlying GitHub credential can read or write”. Ukryte treści mogą być osiągalne przez inne narzędzia. Trzymaj token wąsko, wyłącz narzędzia zapisujące tam, gdzie zadanie ich nie potrzebuje, a resztę modelu zagrożeń znajdziesz w artykule o bezpieczeństwie MCP.

Napraw czerwony pull request na podstawie logu Actions

To pełny przykład użycia. Działa tak samo w Claude Code, Codex i Cursorze, gdy serwer ma toolset actions, a lokalny checkout jest na gałęzi PR-a.

Prompt do skopiowania: napraw padający PR na podstawie logu CI

PR #412 in acme/api is red. Using the GitHub MCP server:
1. Read the PR (pull_request_read) and note the head branch and the failing checks.
2. List the workflow runs for that branch (actions_list, method list_workflow_runs) and take the newest failed run.
3. Fetch only the failed jobs' logs: get_job_logs with run_id, failed_only: true, return_content: true, tail_lines: 300.
4. Quote the first real error line and name the root cause in one sentence.
5. Reproduce it locally with the same command the CI job ran. Do not change code until you have seen it fail.
6. Fix the cause, not the test. Run the same command until it passes, then run the full test suite.
7. Commit with a message that names the failing job, and push to the PR branch.
8. Report: root cause, files changed, the local command and its passing output. Do not merge.

Co powinieneś zobaczyć (nazwy narzędzi zaobserwowane na działającym serwerze zdalnym 2026-09-26):

• actions_list zwraca przebiegi gałęzi, a agent wybiera najnowszy z conclusion: failure.
• get_job_logs zwraca kilkaset linii każdego padającego joba zamiast tysięcy.
• Po pushu na PR-ze startuje nowy przebieg, a agent raportuje dowody i się zatrzymuje.

Agent czyta GitHuba przez MCP, ale zmienia kod w lokalnym checkoucie, więc każda zmiana jest widoczna w git diff i przechodzi przez lokalne hooki, zamiast pojawić się jako zdalny commit z push_files.

Od zgłoszenia do merge’a: przepływ z GitHub MCP

Pojedyncza naprawa CI to jeden krok dłuższej pętli. Tu serwer prowadzi zgłoszenie aż do zmergowanego pull requesta, a człowiek stoi przy jedynej bramce, która ma znaczenie.

1. Triaż. Agent czyta otwarte zgłoszenia przez search_issues i issue_read i proponuje etykiety oraz priorytet. Przy toolsecie issues w trybie tylko do odczytu nie może jeszcze niczego zmienić.

2. Gałąź i implementacja. Wybierasz zgłoszenie. Agent tworzy lokalną gałąź, pisze zmianę i testy, a potem otwiera pull request przez create_pull_request z odnośnikiem do zgłoszenia.

3. Naprawa na podstawie logu CI. Gdy checki padają, agent wykonuje prompt z poprzedniej sekcji: czyta log, odtwarza błąd, poprawia, wypycha. Powtarza, aż wymagane checki przejdą.

4. Komentarze review. Recenzenci, ludzie albo boty AI do code review, zostawiają komentarze. Agent czyta je przez pull_request_read z metodą get_review_comments, która zwraca też threadId każdego wątku, odpowiada w każdym wątku przez add_reply_to_pull_request_comment, wypycha poprawki i oznacza wątek jako rozwiązany przez pull_request_review_write z metodą resolve_thread dopiero wtedy, gdy zmiana jest w gałęzi.

5. Merge. Człowiek zatwierdza i merguje, gdy spełnione są reguły ochrony gałęzi. Agent nigdy nie wywołuje merge_pull_request (zabezpieczenie opisano niżej).

Prompt do skopiowania: triaż zgłoszeń bez ich zmieniania

Using the GitHub MCP server in read-only mode, list open issues in acme/api
created in the last 14 days (search_issues). For each one, read the body and
comments (issue_read) and return a table: number, title, proposed label
(bug / feature / question / duplicate), priority (P0-P3), one-line reason,
and a duplicate candidate if one exists. Do not label, comment or close anything.

Prompt do skopiowania: przepracuj komentarze review na pull requeście

Read every unresolved review thread on PR #412 in acme/api (pull_request_read).
For each thread: decide whether the comment is correct. If it is, make the change
locally, run the tests, and reply in that thread with what changed and the commit
SHA (add_reply_to_pull_request_comment). If you disagree, reply with your reasoning
and leave the thread open for a human. Push once at the end. Resolve only the
threads whose change you pushed. Do not merge and do not dismiss reviews.

Trzymaj merge poza zasięgiem agenta

Token zmerguje wszystko, co może zmergować jego właściciel, więc usuń to narzędzie także po stronie klienta:

Claude Code

W .claude/settings.json. Reguła deny na samą nazwę narzędzia usuwa je z kontekstu modelu:

{
  "permissions": {
    "deny": ["mcp__github__merge_pull_request", "mcp__github__delete_file"]
  }
}

Codex

# ~/.codex/config.toml, w istniejącej tabeli [mcp_servers.github]
disabled_tools = ["merge_pull_request", "delete_file"]

Przetestowane na 0.157.1: codex mcp get github --json pokazuje oba narzędzia w disabled_tools.

Cursor

Nasze źródła nie opisują w Cursorze reguły deny dla pojedynczych narzędzi, więc wyklucz je po stronie serwera nagłówkiem X-MCP-Exclude-Tools w ~/.cursor/mcp.json:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${env:GITHUB_PAT}",
        "X-MCP-Exclude-Tools": "merge_pull_request,delete_file"
      }
    }
  }
}

Przewodnik GitHuba po konfiguracji serwera opisuje ten nagłówek i podaje, że wykluczenia mają pierwszeństwo przed toolsetami i X-MCP-Tools, więc wykluczone narzędzie pozostaje ukryte nawet wtedy, gdy jego toolset jest włączony.

Nagłówek X-MCP-Exclude-Tools działa w każdym kliencie, który wysyła własne nagłówki, a serwer lokalny przyjmuje tę samą listę jako --exclude-tools lub GITHUB_EXCLUDE_TOOLS. Traktuj go jako uzupełnienie po stronie serwera dla reguły deny w Claude Code i listy disabled_tools w Codex: narzędzie znika, zanim zobaczy je jakikolwiek klient.

Ostatnią linią obrony jest ochrona gałęzi z wymaganymi status checkami i wymaganym zatwierdzającym review: nawet źle skonfigurowany agent jej nie obejdzie.

Jak sprawdzić, co agent zrobił na GitHubie?

Nie czytasz każdej linii, którą agent wypycha. Sprawdzasz, czy są dowody, a resztę egzekwuje repozytorium.

• Odtwórz przed poprawką, zalicz po poprawce. Prompt zmusza agenta, żeby pokazał padające polecenie, a potem to samo polecenie przechodzące. Poprawka bez odtworzenia błędu wraca do agenta.
• Wymagane checki są wyrocznią. Ochrona gałęzi oznacza joby CI jako wymagane, więc „zielony” znaczy, że ten sam zestaw testów, który złapał błąd, teraz przechodzi. Obserwujesz to przez gh pr checks 412 --watch.
• Jeden recenzent podpisuje zmianę. Człowiek zatwierdza pull request, najpierw czytając raport agenta i diff testów; co sprawdzać, opisuje artykuł o przeglądzie pull requestów od agenta.
• Każda akcja zostawia ślad. Komentarze, odpowiedzi i pushe pojawiają się na pull requeście pod użytkownikiem tokena. Do przebiegów automatycznych użyj tokena osobnego konta technicznego, żeby w historii odróżnić działania agenta od twoich.
• Wycofanie to revert. Agent pracuje zwykłymi commitami na gałęzi, więc git revert cofa każdą jego zmianę.

GitLab: oficjalny serwer MCP i zereight/gitlab-mcp

Zespoły na GitLabie mają dwie opcje. Własny serwer GitLaba działa zdalnie pod https://gitlab.com/api/v4/mcp (lub https://YOUR_GITLAB/api/v4/mcp dla instancji self-managed). Według źródeł wtórnych (wyciągów z wyszukiwarki z dokumentacji GitLaba, której nie dało się pobrać 2026-09-26) to funkcja GitLab Duo w wersji beta dla planów Premium i Ultimate. Dla pozostałych planów jest społecznościowy zereight/gitlab-mcp (2 tys. gwiazdek, npm @zereight/mcp-gitlab 2.1.66 na 2026-09-26), uruchamiany lokalnie z tokenem PAT.

Claude Code

# Oficjalny, zdalny z OAuth (tego adresu używa wtyczka gitlab w claude-plugins-official)
claude mcp add --transport http gitlab https://gitlab.com/api/v4/mcp

# Społecznościowy, lokalny z PAT wyeksportowanym jako GITLAB_PAT w profilu powłoki.
# Narzędzia do pipeline'ów są opcjonalne: GITLAB_TOOLSETS=pipelines (starsza forma: USE_PIPELINE=true)
claude mcp add -s project gitlab -e 'GITLAB_PERSONAL_ACCESS_TOKEN=${GITLAB_PAT}' \
  -e GITLAB_API_URL=https://gitlab.com/api/v4 -e GITLAB_TOOLSETS=pipelines \
  -- npx -y @zereight/mcp-gitlab

Przetestowane na 2.1.283: apostrofy zostawiają odwołanie nierozwinięte, a .mcp.json zawiera "${GITLAB_PAT}", nie token.

Codex

# ~/.codex/config.toml. Wyeksportuj GITLAB_PERSONAL_ACCESS_TOKEN w profilu powłoki;
# env_vars przekazuje ją z powłoki, więc token nie trafia do tego pliku.
# Narzędzia do pipeline'ów są opcjonalne: GITLAB_TOOLSETS=pipelines (starsza forma: USE_PIPELINE=true)
[mcp_servers.gitlab]
command = "npx"
args = ["-y", "@zereight/mcp-gitlab"]
env_vars = ["GITLAB_PERSONAL_ACCESS_TOKEN"]
env = { GITLAB_API_URL = "https://gitlab.com/api/v4", GITLAB_TOOLSETS = "pipelines" }

Przetestowane na 0.157.1: codex mcp get gitlab --json pokazuje token w env_vars, bez wartości.

Dla oficjalnego serwera zdalnego pasująca składnia to codex mcp add gitlab --url https://gitlab.com/api/v4/mcp, a potem codex mcp login gitlab, ale nie przetestowano jej z OAuth GitLaba.

Cursor

W globalnym pliku użytkownika ~/.cursor/mcp.json, którego nigdy nie commitujesz:

{
  "mcpServers": {
    "gitlab": {
      "command": "npx",
      "args": ["-y", "@zereight/mcp-gitlab"],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "${env:GITLAB_PAT}",
        "GITLAB_API_URL": "https://gitlab.com/api/v4",
        "GITLAB_TOOLSETS": "pipelines"
      }
    }
  }
}

Interpolacja ${env:NAZWA} pochodzi z dokumentacji Cursora cytowanej w naszym researchu, nie z lokalnego testu.

GITLAB_API_URL musi wskazywać korzeń API (/api/v4), a nie adres strony. Dla agenta tylko do odczytu ustaw GITLAB_PERMISSION_MODE=readonly; modify pozwala tworzyć i aktualizować, ale bez narzędzi do usuwania. Scope’y tokena GitLaba dobierasz według tej samej zasady co na GitHubie: read_api i read_repository do odczytu, api tylko wtedy, gdy agent musi zapisywać.

Prompt do skopiowania: napraw padający pipeline w GitLabie

The pipeline for MR !88 in acme/api failed. Using the GitLab MCP server, find the
failed job, fetch its log, and quote the first real error. Reproduce it locally with
the job's script, fix the cause, run the same command until it passes, and push to
the MR branch. Report the root cause and the passing command. Do not merge.

Co się psuje w GitHub MCP i jak z tego wyjść?

Objaw	Przyczyna	Rozwiązanie
Bad credentials lub 401	Token wygasł, został odwołany lub źle wpisany; albo zmienna nie jest ustawiona w powłoce, z której uruchomiono agenta	Utwórz nowy PAT, wyeksportuj go i uruchom agenta ponownie z tej powłoki. Przy tokenach fine-grained sprawdź listę repozytoriów
Wtyczka zainstalowana, zero narzędzi	Wtyczka czyta ustaloną zmienną (GITHUB_PERSONAL_ACCESS_TOKEN w Claude Code, GITHUB_PAT_TOKEN w Codex; w Cursorze sprawdź mcp.json wtyczki)	Wyeksportuj dokładnie tę nazwę, której oczekuje wtyczka
Brakuje oczekiwanego narzędzia	Klasyczny PAT bez scope’u je ukrywa albo włączony jest tryb tylko do odczytu lub filtr toolsetów	Sprawdź x-oauth-scopes, ścieżkę URL i nagłówki X-MCP-*
Narzędzie widoczne, wywołanie zwraca 403	Fine-grained PAT pokazuje wszystkie narzędzia; API odrzuca wywołanie	Nadaj uprawnienie albo usuń toolset, żeby agent przestał próbować
search_code nie znajduje niczego na twojej gałęzi	Wyszukiwanie kodu indeksuje tylko gałąź domyślną, a forki tylko w niektórych przypadkach	Kod z gałęzi przeszukuj lokalnie przez rg
Błędy limitu 403 lub 429 w trakcie pracy	Limit 5000 żądań na godzinę na token dzielą gh, skrypty i serwer MCP	Stronicuj małymi porcjami, masowe odczyty rób przez gh, daj automatyzacji własny token
claude mcp add github https://… nie łączy się z niczym	Bez --transport http Claude Code zapisuje URL jako polecenie stdio	Usuń wpis i dodaj go ponownie z --transport http
Logowanie OAuth w Dockerze nigdy się nie kończy	Port callbacku nie jest wystawiony na loopback	Dodaj -p 127.0.0.1:8085:8085 i GITHUB_OAUTH_CALLBACK_PORT=8085 albo użyj device-code flow
Zgłoszenie kontrybutora „nie istnieje”	Tryb lockdown ukrywa treści autorów bez uprawnienia push	W repozytoriach publicznych to oczekiwane. Najpierw przeczytaj zgłoszenie sam (gh issue view N). Lockdownu nie da się ograniczyć do jednego repozytorium: sesja bez --lockdown-mode, GITHUB_LOCKDOWN_MODE lub X-MCP-Lockdown przestaje filtrować wszystkie publiczne repozytoria w tej sesji. Jeśli agent musi je przeczytać, uruchom taką sesję tylko do odczytu (https://api.githubcopilot.com/mcp/readonly, X-MCP-Readonly: true lub lokalnie --read-only) bez narzędzi zapisujących, a potem wróć do konfiguracji z lockdownem. Rola Triage nie pomoże: nie daje uprawnienia push, które ma dopiero rola Write i wyższe

Problemy z połączeniem, które nie dotyczą tylko GitHuba, opisuje artykuł o problemach z połączeniem MCP.

Pułapki, które wyglądają poprawnie, a są błędne (stan na 2026-09-26)

• @modelcontextprotocol/server-github i @modelcontextprotocol/server-gitlab w npm są oznaczone jako deprecated („Package no longer supported”) i zarchiwizowane. Użyj adresu zdalnego, obrazu Docker albo @zereight/mcp-gitlab.
• @github/github-mcp-server nie istnieje w npm, a github-mcp-server bez scope’u to niepowiązany pakiet społecznościowy.
• ?readonly=true nie jest przełącznikiem GitHuba. GitHub używa ścieżki /readonly lub nagłówka X-MCP-Readonly.
• .claude/mcp.json to zła ścieżka. Plik projektowy Claude Code to .mcp.json w katalogu głównym repozytorium, a --url to flaga Codex, nie Claude Code.

Dokąd dalej z GitHub MCP

• Wymaganie wstępne: jak działa MCP w trzech agentach.
• Następny krok: przegląd pull requestów otwieranych przez agenta, a potem ta sama pętla naprawy CI bez nadzoru z agentami headless w CI.

Najważniejsze serwery MCP dla zespołów Ranking z przełącznikiem tylko do odczytu dla każdego serwera.

Bezpieczeństwo MCP Prompt injection, zakres tokena i reszta modelu zagrożeń.

Jira i Linear przez MCP Zacznij pętlę od zgłoszenia w trackerze zadań.

Najczęściej instalowane wtyczki Wtyczka github i inne, które warto zainstalować.