Copilot dostał lokalną piaskownicę, lecz ochrona jest domyślnie wyłączona

Według komunikatu GitHuba z 23 września 2026 r. lokalna piaskownica w aplikacji GitHub Copilot trafiła do publicznego podglądu. Ogranicza dostęp narzędzi uruchamianych przez agenta do plików, sieci i poświadczeń na komputerze użytkownika. Jest domyślnie wyłączona; przełącznik w ustawieniach projektu obejmuje nowe lokalne sesje, lecz nie zmienia tych, które już działają.

Opublikowane po premierze omówienie AIgent Lab zwraca uwagę na różnicę między osobnym worktree a izolacją poleceń agenta. Worktree rozdziela pliki i gałęzie równoległych prac, ale samo nie ogranicza dostępu poleceń do reszty komputera. Nowa funkcja dodaje taką granicę dla lokalnych sesji repozytorium i worktree w aplikacji Copilot.

Co ogranicza piaskownica aplikacji Copilot

Instrukcja GitHuba opisuje piaskownicę systemu operacyjnego, w której działają narzędzia wywoływane przez agenta. Politykę ustawia się osobno dla projektu: obejmuje dostęp do systemu plików, połączenia sieciowe oraz poświadczenia Git i GitHub CLI. Ustawienia projektu określają żądaną politykę, a zasady zarządzane przez firmę mogą ją dodatkowo zaostrzyć.

Domyślnie sesja w piaskownicy może czytać i zapisywać pliki w swoim obszarze roboczym oraz bieżącym katalogu pracy. Dodatkowe foldery można udostępnić do odczytu i zapisu, tylko do odczytu albo umieścić na liście Denied. Bardziej szczegółowy zakaz pozostaje skuteczny nawet wtedy, gdy dostęp przyznano do folderu nadrzędnego. Dla pliku poufnego znajdującego się w dozwolonym obszarze roboczym potrzebna jest więc osobna reguła odmowy dostępu.

Samo włączenie piaskownicy nie odcina sieci. Domyślna polityka pozwala na połączenia z internetem i siecią lokalną, a ustawienia Outbound internet i Local network służą do ograniczania tych kierunków oddzielnie. Sieć lokalna obejmuje także połączenia zwrotne, z których może korzystać serwer deweloperski uruchomiony na tym samym komputerze. Wyłączenie dostępu do internetu może z kolei wpłynąć na pobieranie zależności i wywołania usług zewnętrznych.

Domyślnie dostępne pozostają również poświadczenia do uwierzytelnionych operacji Git przez HTTPS oraz uwierzytelnienie GitHub CLI. Każdy z tych rodzajów dostępu można wyłączyć niezależnie. Taka decyzja może zablokować agentowi wysłanie gałęzi lub utworzenie pull requestu z piaskownicy, pozostawiając mu możliwość pracy nad plikami zgodnie z regułami projektu.

Jak objąć ochroną nową sesję projektu

Ustawienie Sandbox new sessions znajduje się w sekcji Sandbox wybranego projektu w aplikacji GitHub Copilot. Włączenie go zmienia domyślny stan nowych lokalnych sesji tego projektu. Przed rozpoczęciem sesji można też ustalić dostęp do dodatkowych folderów, obu rodzajów sieci i poświadczeń; domyślna polityka pozwala na typowe czynności deweloperskie, w tym instalowanie zależności i pracę z GitHubem.

1. Otwórz ustawienia aplikacji i wybierz projekt, w którym będzie działał agent.
2. W sekcji Sandbox włącz Sandbox new sessions.
3. Ustal reguły dla dodatkowych folderów, internetu, sieci lokalnej oraz poświadczeń Git i GitHub CLI, a następnie rozpocznij nową lokalną sesję.

Przełącznik projektu nie zmienia stanu sesji już uruchomionej. W aktywnej sesji lokalnej polecenie /sandbox on włącza izolację dla tej sesji bez zmiany ustawienia domyślnego projektu. Zmiany reguł dostępu do plików, sieci i poświadczeń zaczynają natomiast obowiązywać w nowej sesji albo po ponownym uruchomieniu istniejącej. Polecenie /restart-session zachowuje historię rozmowy podczas takiego ponownego uruchomienia.

Worktree, lokalna piaskownica i sesja chmurowa

Trzy środowiska wyznaczają różne granice pracy agenta. Worktree oddziela pliki i gałąź używane w równoległej sesji. Lokalna piaskownica nakłada politykę dostępu na narzędzia wywoływane przez agenta na komputerze użytkownika. Sesja chmurowa działa w odrębnym środowisku i nie dziedziczy ustawienia lokalnej piaskownicy projektu.

• Worktree: rozdziela robocze pliki i gałęzie, ale polecenie uruchomione bez piaskownicy nadal może sięgać poza ten katalog z uprawnieniami użytkownika.
• Lokalna piaskownica aplikacji: obejmuje narzędzia w lokalnej sesji repozytorium lub worktree. Zakres dostępu wynika z polityki projektu, stanu sesji i ewentualnych zasad firmowych.
• Sesja chmurowa: korzysta z własnego środowiska. Ustawienie lokalnej piaskownicy aplikacji jej nie obejmuje; nie obejmuje też sesji działającej na zdalnym hoście.

Ustawienia piaskownicy w aplikacji i w Copilot CLI są konfigurowane osobno. Włączenie ochrony dla projektu w aplikacji nie ustawia jej dla sesji uruchamianych z terminala. Ma to znaczenie, gdy agent pracuje nad tym samym repozytorium w obu narzędziach: wspólne pliki projektu nie oznaczają wspólnej polityki izolacji.

Granice ochrony w publicznym podglądzie

Skuteczna granica zależy od reguł, a nie tylko od włączonego przełącznika. Jeżeli dozwolony obszar zawiera sekret, sieć pozostaje dostępna, a poświadczenia są udostępnione, narzędzia agenta zachowują te możliwości także w piaskownicy. Przy zadaniu wymagającym wyłącznie lokalnej edycji kodu można ograniczyć te uprawnienia oddzielnie, bez odbierania dostępu do potrzebnych plików projektu.

Gdy polityka blokuje operację, aplikacja może zaproponować uruchomienie narzędzia poza piaskownicą. Zależnie od obowiązujących zasad użytkownik może anulować działanie, dopuścić je jednorazowo albo wyłączyć izolację na resztę bieżącej sesji. Właściciel firmy może zabronić uruchamiania narzędzi poza piaskownicą. Zgoda na wyjątek zmienia więc zakres ochrony konkretnego działania lub sesji, mimo że ustawienie projektu pozostaje włączone.

Istnieje też ograniczenie zależne od platformy: na Linuksie ustawienie Local network nie kontroluje niezależnie dostępu do sieci lokalnej procesów potomnych, takich jak polecenia powłoki czy lokalne serwery MCP i LSP. Dotyczy natomiast operacji wykonywanych wewnątrz procesu aplikacji. Jeśli system nie potrafi wymusić żądanej polityki, pierwszy proces powłoki uruchamiany w piaskownicy kończy się błędem zamiast działać bez izolacji. Dla programisty oznacza to, że rzeczywisty zakres ochrony zależy zarówno od reguł projektu, jak i od środowiska, w którym rusza sesja.

Przeczytaj także:

• Lokalny model czy API? Oszczędność znika przy złym wykorzystaniu