GitHub Copilot czyta teraz CLAUDE.md. Reguły projektu przestają należeć do jednego narzędzia

GitHub ogłosił 17 lipca, że przegląd kodu w Copilocie czyta teraz pliki CLAUDE.md i GEMINI.md prosto z repozytorium. Innymi słowy: plik z regułami, który pisałeś pod Claude Code albo pod Gemini, zaczyna działać także w narzędziu konkurencji, bez przepisywania czegokolwiek. Zmiana wygląda na drobiazg techniczny, a jest pierwszym wyraźnym sygnałem, że format instrukcji dla projektu przestaje być własnością pojedynczego dostawcy.

Co dokładnie się zmieniło

W ogłoszeniu na blogu GitHuba zmiana opisana jest jednym zdaniem: przegląd kodu czyta pliki REVIEW.md, GEMINI.md i CLAUDE.md z repozytorium, niezależnie od tego, gdzie w projekcie leżą. GitHub dodaje, że jeśli zespół już trzyma w tych plikach swoje wytyczne do przeglądu albo instrukcje pisane pod konkretny model, Copilot podniesie je automatycznie.

Do tej pory Copilot obsługiwał własny zestaw: copilot-instructions.md, pliki z rozszerzeniem .instructions.md, umiejętności agenta oraz AGENTS.md. Trzy nowe nazwy dochodzą do tej listy, a nie ją zastępują.

Drugą zmianą w tej samej paczce jest to, skąd instrukcje są czytane. Wcześniej Copilot brał je z gałęzi docelowej, teraz bierze z gałęzi, którą właśnie zgłaszasz. Dzięki temu poprawkę w regułach można sprawdzić od razu, zamiast najpierw scalać ją do głównej gałęzi i dopiero potem obserwować efekt.

Dlaczego to ma znaczenie poza samym Copilotem

Jeśli budujesz aplikacje z pomocą agentów, plik z regułami projektu jest najtańszą rzeczą, jaka realnie poprawia wyniki. Zapisujesz w nim, w jakim języku ma pisać komentarze, jakich bibliotek nie ruszać, jak nazywać pliki, czego nie zmieniać bez pytania. Problem w tym, że dotąd każde narzędzie chciało swojego pliku pod swoją nazwą, więc osoba korzystająca z dwóch albo trzech narzędzi utrzymywała kilka kopii tej samej wiedzy.

Ruch GitHuba nie jest żadnym otwarciem standardu i nie ma tu wspólnej specyfikacji. To po prostu decyzja jednego producenta, żeby czytać cudze pliki. Kierunek jest jednak wygodny dla użytkownika: reguły pisze się raz, a im więcej narzędzi je respektuje, tym mniej pracy przy przesiadce. Warto odnotować, że dzieje się to akurat w Copilocie, czyli u dostawcy z największą bazą użytkowników, który miał najmniejszy interes w czytaniu plików nazwanych po konkurencji.

Zastrzeżenie, żeby nie było nieporozumienia: zmiana dotyczy wyłącznie przeglądu kodu w Copilocie, a nie podpowiedzi w edytorze ani agenta chmurowego. Jeśli spodziewasz się, że od teraz Copilot będzie stosował Twój CLAUDE.md podczas pisania kodu, to na razie tak nie działa.

Przegląd kodu chowa się za zaporą

W tej samej paczce jest zmiana, która w praktyce może być ważniejsza. Przegląd kodu w Copilocie działa teraz domyślnie za zaporą sieciową, która ogranicza dostęp do sieci w trakcie przeglądu. GitHub pisze wprost, że zapora jest włączona domyślnie dla wszystkich repozytoriów, a ustawia się ją w ustawieniach repozytorium w sekcji Copilot, w pozycji dotyczącej dostępu do internetu.

To sensowny domyślny wybór. Narzędzie, które czyta kod i instrukcje z repozytorium, jest naturalnym celem dla ataku polegającego na przemyceniu poleceń w treści, którą agent przeczyta. Pisaliśmy o tej klasie problemu przy okazji utwardzania narzędzia Agent w Claude Code. Odcięcie sieci nie usuwa problemu, ale odbiera napastnikowi najprostszą drogę wyprowadzenia danych na zewnątrz.

Jest jedno zastrzeżenie: zapora nie działa na własnych maszynach z konfiguracją self-hosted. Kto uruchamia przeglądy na swojej infrastrukturze, tej ochrony na razie nie dostaje.

Dwie pozostałe zmiany są czysto administracyjne. Środowisko przeglądu można teraz przygotować własnym plikiem copilot-code-review.yml w katalogu .github/workflows/, a jeśli go nie ma, Copilot cofnie się do istniejącego copilot-setup-steps.yml. Konfiguracja maszyn dla przeglądu kodu i dla agenta chmurowego została też rozdzielona na dwie osobne sekcje w ustawieniach organizacji, bo wcześniej dzieliły jedno ustawienie.

Co z tym zrobić

Jeśli masz w projekcie plik CLAUDE.md i korzystasz z przeglądu kodu w Copilocie, nie musisz robić nic: reguły zostaną podniesione same. Dobrym pomysłem jest natomiast zajrzenie do tego pliku i sprawdzenie, czy nie ma w nim zdań pisanych ściśle pod jedno narzędzie, bo teraz przeczyta je także drugie.

Jeśli dopiero zaczynasz i nie masz żadnego pliku z regułami, to jest moment, żeby go założyć. Wystarczy kilkanaście zdań o tym, czego w projekcie nie ruszać i jak ma wyglądać kod. Więcej o samym narzędziu zebraliśmy na karcie GitHub Copilot.