# Protokół przed uruchomieniem: odebranie dostępu w aktywnej sesji MCP

Zapisano 12.10.2026 przed pierwszym uruchomieniem testu. Pakiet docelowy:
`@modelcontextprotocol/server-filesystem@1.0.0`, pobrany z npm, uruchomiony
jako osobny proces przez stdio. Klient to własny skrypt JSON-RPC bez modelu AI;
serwer jest niezmienionym oficjalnym pakietem. Protokół MCP negocjowany od
wersji `2025-06-18`, faktyczna odpowiedź będzie zapisana w logu.

## Pytanie i zakres

Czy działający proces serwera plików odmawia kolejnego odczytu po wycofaniu
wszystkich roots przez klienta? Czy powrót uprawnienia przywraca odczyt? Czy
narzędzie poczeka na trwające odświeżenie i czy opóźniona starsza odpowiedź
może nadpisać nowsze odebranie dostępu?

Roots są informacją od klienta; badamy konkretny serwer, który z nich
buduje listę dozwolonych katalogów. To nie audyt izolacji systemowej ani
wszystkich implementacji MCP.

## Dane i konfiguracja

Wyłącznie pliki syntetyczne w katalogu tymczasowym testu. Jeden katalog
`allowed`, jeden `outside`. Każdy zawiera plik `probe.txt` z innym znanym
znacznikiem. Odczyt narzędziem `read_text_file`. Serwer bez katalogów
podanych w argumentach CLI; klient deklaruje `roots.listChanged: true`.
Cała sekwencja odbywa się w jednej sesji i jednym procesie serwera.
Bez LLM, GPU, płatnych API, kont, danych klientów i zapisu narzędziami MCP.

## Sekwencja i kryteria ustalone przed testem

1. Nadać root `allowed` w inicjalizacji. Potwierdzić stan przez
   `list_allowed_directories`, odczytać znacznik i sprawdzić odmowę dla
   `outside`. To kontrola dodatnia i kontrola granicy katalogu.
2. Wysłać `notifications/roots/list_changed`. Na żądanie `roots/list`
   odpowiedzieć `roots: []`. Przed odczytem potwierdzić pustą listę przez
   `list_allowed_directories`. Odczyt `allowed/probe.txt` ma zwrócić błąd
   dostępu bez znacznika. Samo wysłanie powiadomienia nie jest dowodem
   zakończenia aktualizacji.
3. Przywrócić root tą samą ścieżką, potwierdzić listę i odczytać znacznik.
   Ta kontrola wyklucza interpretację odmowy jako trwałej awarii procesu.
4. Zapowiedzieć wycofanie i zatrzymać odpowiedź na `roots/list`. Dopiero
   po odebraniu tego żądania od serwera wysłać odczyt. Obserwować przez
   200 ms, czy pojawi się odpowiedź. Następnie przesłać `roots: []`.
   Oczekiwanie: brak odpowiedzi w obserwowanym oknie, a po zwolnieniu
   odpowiedzi odmowa. To test konkretnego harmonogramu, nie gwarancja
   czasu unieważnienia w dowolnym środowisku.
5. Przywrócić i potwierdzić dostęp. Wywołać dwa odświeżenia. Zatrzymać
   starszą odpowiedź (z przyznanym root), odpowiedzieć na nowszą pustą
   listą. Potwierdzić pusty stan i odmowę. Dopiero potem zwolnić starszą
   odpowiedź. Poczekać na komunikat serwera o odrzuceniu starej odpowiedzi,
   ponownie sprawdzić pustą listę i odmowę. Starsza odpowiedź nie powinna
   przywrócić dostępu. Na koniec znów przyznać dostęp i odczytać plik.

W żadnym scenariuszu nie interpretujemy odczytu rozpoczętego przed
powiadomieniem jako błędu wycofania. Tego przypadku nie mierzymy.

## Rejestrowanie i weryfikacja

Zapisać każdy komunikat JSON-RPC w obu kierunkach, stderr serwera,
zdarzenia sterujące klienta, wyniki i wersje. Log ma rosnący numer
sekwencyjny i czas monotoniczny. Zapis wyników także przy niepowodzeniu;
brak przebiegu nie może stać się wynikiem pozytywnym. Weryfikator ma
odtworzyć stany i odczyty z surowych logów, zamiast ufać samemu podsumowaniu.
Opublikować skrypt, lockfile, protokół, logi, wyniki, README oraz SHA-256.

## Ograniczenia z góry

Jeden pakiet, jedna konfiguracja, jeden system operacyjny i jedna
deterministyczna sekwencja. Bez porównania starych wersji, testów zapisu,
symlinków, sieci, OAuth, błędu `roots/list`, wielu użytkowników i wszystkich
możliwych przeplotów zdarzeń. Nie badamy zapomnienia wcześniej odczytanych
danych ani innych narzędzi agenta. Wynik nie jest certyfikatem bezpieczeństwa.

## Dziennik zmian

Pierwszy przebieg `run-001` uruchomiono 12.10.2026 o 17:55:36.781 UTC.
Zakończył się powodzeniem. Nie zmieniano planu ani klienta testowego po
obejrzeniu wyników. Następnie dodano weryfikator czytający surowy log,
README i materiały publikacyjne. Problem DNS przy wcześniejszym pobieraniu
zależności nie był przebiegiem testu. Nie badano poprzedniej wersji pakietu.