Claude Code nie widzi plików: folder, .gitignore i dostęp

To znajomy widok: prosisz Claude Code o poprawienie pliku, a on odpowiada, że taki plik nie istnieje. Albo po cichu zmienia coś zupełnie innego, niż masz na myśli. Otwierasz folder — plik jest na swoim miejscu. Ale Claude zdaje się go nie zauważać.

Prawie zawsze przyczyna jest jedna i nic się nie zepsuło. Claude nie widzi plików na całym komputerze. Ma dostęp tylko do folderu, z którego go uruchomiono. Uruchomienie w sąsiednim folderze lub poniżej korzenia projektu może pozostawić potrzebne pliki poza drzewem roboczym. Start z katalogu nadrzędnego, np. domowego, daje szerszy zakres; nie czyni projektu podrzędnego niedostępnym. Wyjaśnię krok po kroku, dlaczego tak to działa i jak zapewnić Claude dostęp do potrzebnych plików. Cytuję polecenia i ustawienia bezpośrednio z oficjalnej dokumentacji Claude Code, którą sprawdziłem na początku września 2026 roku.

Dodatkowe materiały na temat konfiguracji narzędzi znajdziesz w dokumentacji Ailoot.

Dlaczego Claude Code nie widzi niektórych plików projektu?#

Domyślnie Claude Code pracuje z jednym folderem: tym, w którym wpisano polecenie claude i uruchomiono sesję. Dokumentacja mówi o tym wprost.

Ten folder jest jego katalogiem roboczym. W jego obrębie Claude odczytuje dowolny plik bez dodatkowych pytań: edytowanie promptu, wyszukiwanie kodu czy odczyt konkretnego pliku — wszystko działa od razu. Jednak wszystko poza tym folderem jest domyślnie niedostępne. Sąsiedni folder, folder poziom wyżej czy inny dysk — Claude tam nie zajrzy, dopóki mu na to nie pozwolisz.

Rozbieżność folderu roboczego może mieć znaczenie. Jeśli projekt jest w /Users/you/my-shop, a Claude uruchomiono w sąsiednim /Users/you/other-project, jego index.html jest poza tym drzewem roboczym. Start z /Users/you jest innym przypadkiem: my-shop jest potomkiem i nie staje się niedostępny przez sam start z katalogu domowego, choć kontekst jest szerszy niż zamierzony. Dostęp do folderu nie oznacza przeczytania wszystkich plików.

W kolejnych sekcjach pokażę, jak to sprawdzić i naprawić: najpierw ustalimy, z którego folderu uruchomiono Claude, a potem przyznamy mu dostęp do potrzebnych plików na różne sposoby — od jednorazowej instrukcji po stałe ustawienie.

Jak sprawdzić, z którego folderu uruchomiono Claude Code?#

Zanim cokolwiek naprawisz, upewnij się, że problemem rzeczywiście jest folder. Łatwo to sprawdzić. Poproś Claude na czacie o wyświetlenie bieżącego katalogu — uruchomi pwd. To bezpieczne polecenie: wyświetla tylko ścieżkę i niczego nie zmienia.

pwd

Odpowiedź pokazuje faktyczny katalog roboczy. Porównaj go z pełną ścieżką projektu: /Users/you/other-project jest sąsiadem /Users/you/my-shop, a /Users/you rodzicem. W pierwszym przypadku my-shop jest poza drzewem roboczym, w drugim jest objęty zakresem, ale nie jest wybranym korzeniem projektu.

Najprościej rozwiązać tę rozbieżność, uruchamiając Claude bezpośrednio z folderu projektu. Zamknij bieżącą sesję, przejdź w terminalu do właściwego folderu i uruchom stamtąd Claude:

# Zastąp przykładową ścieżkę rzeczywistym korzeniem projektu.
cd /Users/you/my-shop
claude

Teraz my-shop będzie folderem roboczym, a wszystkie pliki projektu znajdą się w zasięgu Claude. Ta sama zasada obowiązuje w edytorze takim jak VS Code: otwórz folder zawierający projekt. Nie folder poziom wyżej ani cały dysk. Otwarty folder określa katalog roboczy Claude.

Jeśli ponowne uruchomienie jest niewygodne — na przykład przekazano już Claude kontekst w tej sesji i nie chcesz go stracić — możesz w locie dodać folder albo się do niego przełączyć. Wyjaśniam to w dwóch kolejnych sekcjach.

Jak pokazać Claude Code plik z sąsiedniego folderu?#

Czasami projekt nie mieści się w jednym folderze. Kod znajduje się w jednym miejscu, obrazy lub tekst w sąsiednim folderze, a współdzielone komponenty gdzieś indziej w pobliżu. Ponowne uruchamianie Claude w każdym folderze po kolei jest niewygodne. Lepiej przyznać mu dostęp do potrzebnego folderu, pozostawiając folder główny jako katalog roboczy.

Najprościej zrobić to bezpośrednio w aktywnej sesji za pomocą polecenia:

/add-dir ../assets

Wpisz /add-dir i ścieżkę folderu, a Claude od razu uzyska dostęp do jego plików na takich samych zasadach jak do plików w folderze głównym. Nie poprosi ponownie o zgodę — dodany folder podlega tym samym regułom co katalog roboczy.

Jeśli z góry wiesz, że będziesz pracować z wieloma folderami, otwórz dostęp od razu po uruchomieniu Claude — użyj tej samej ścieżki, ale z flagą:

claude --add-dir ../assets

Jeśli w danym projekcie stale potrzebujesz tego samego sąsiedniego folderu, nie musisz dodawać go ręcznie za każdym razem. Plik ustawień settings.json zawiera klucz additionalDirectories. Wymień tam ścieżki, a będą automatycznie otwierane przy każdym uruchomieniu Claude:

{
  "permissions": {
    "additionalDirectories": ["../assets", "../shared"]
  }
}

Użytkownicy Windows powinni pamiętać o jednym ograniczeniu: nie można dodać folderu sieciowego ścieżką w rodzaju \\server\shared — Claude nie akceptuje takich ścieżek. Zamontuj go jako osobny dysk z literą dysku, a następnie przekaż tę literę za pomocą --add-dir. Zwykłe foldery lokalne nie mają tego problemu.

A co, jeśli dodanie sąsiedniego folderu nie wystarcza i trzeba całkowicie przejść do innego folderu? Służy do tego osobne polecenie, które opisuję poniżej.

Jak przełączyć Claude Code do innego folderu podczas sesji?#

Czasami dodanie sąsiedniego folderu nie wystarcza — trzeba zmienić folder główny i przejść do innego projektu bez utraty zgromadzonego kontekstu. Użyj polecenia /cd:

/cd ../another-project

Po tej zmianie Claude traktuje nowy folder jako katalog roboczy. Zachowujesz całą historię rozmowy, ale miejsce, które Claude przyjmuje za punkt odniesienia do plików, zmienia się na nową lokalizację. Claude odczyta również plik z instrukcjami CLAUDE.md z nowego folderu, jeśli taki tam jest — dostosuje się więc do zasad nowego projektu.

Warto wiedzieć, jak działa zaufanie: jeśli wcześniej nie pracowano w tym folderze, Claude podczas przejścia zapyta, czy mu ufasz. To zabezpieczenie: plik z instrukcjami w nieznanym folderze może zawierać dowolną treść, dlatego Claude najpierw sprawdza, czy to twój projekt. Potwierdź i kontynuuj.

Różnica między tymi poleceniami jest prosta. /add-dir pozostawia główny folder jako katalog roboczy i otwiera dodatkowo sąsiedni folder — przydaje się, gdy części projektu są rozproszone. /cd przenosi cały katalog roboczy w nowe miejsce — przydaje się podczas przełączania się na inny projekt. Polecenie /cd wprowadzono w wersji 2.1.169, więc jeśli go brakuje, zaktualizuj Claude Code. W osobnym poradniku wyjaśniam jak zaktualizować Claude Code.

Widoczność plików przez Claude Code to dopiero podstawa. Stabilne wyniki nie zależą wyłącznie od dostępu do plików. Zależą też od ich zawartości i sposobu budowania kontekstu projektu.

Dlaczego Claude Code nie widzi pliku w podfolderze?#

Warto nie mylić tu dwóch różnych sytuacji. Sąsiedni folder, znajdujący się poza projektem, jest całkowicie niedostępny, dopóki go nie dodasz. Podfolder wewnątrz projektu działa inaczej: Claude ma do niego dostęp, ale od początku nie zachowuje jego zawartości w pamięci roboczej.

Oto jak to działa. Po uruchomieniu Claude wczytuje zawartość z najwyższych poziomów projektu. Pliki z podfolderów wczytuje na żądanie, gdy przechodzi do nich, aby coś odczytać. Dokumentacja opisuje takie zachowanie w odniesieniu do plików z instrukcjami, a ta sama zasada dotyczy kontekstu ogólnie.

Mówiąc prościej: plik w głęboko zagnieżdżonym podfolderze nie zniknął i jest w pełni dostępny. Claude po prostu jeszcze o nim nie wie, bo tam nie zajrzał — dlatego może się wydawać, że „nie widzi” pliku, mimo że ten istnieje i można go odczytać.

Możesz to naprawić jedną linijką. Podaj Claude bezpośrednio ścieżkę do pliku, na przykład src/components/header.jsx, albo po prostu poproś go najpierw o odczytanie pliku. Gdy tylko tam zajrzy, plik trafi do kontekstu i będzie można pracować z nim jak zwykle. Nie trzeba zmieniać żadnych ustawień.

Dlaczego pliki znikają z menu @ i co ma z tym wspólnego .gitignore?#

Innym częstym powodem, dla którego wydaje się, że Claude „zgubił” plik, jest selektor plików. Po wpisaniu @ pojawia się lista, która ułatwia wybranie pliku bez wpisywania pełnej ścieżki. Lista nie pokazuje jednak wszystkiego.

Domyślnie menu @ ukrywa pliki wymienione w .gitignore. Ten plik określa, czego nie należy dodawać do współdzielonego repozytorium: folderów usługowych, plików zawierających hasła i ustawienia środowiskowe oraz gotowych wyników kompilacji. Powód jest prosty — zwykle nie trzeba ręcznie pracować z tymi plikami, więc tylko zaśmiecałyby listę. Czasami jednak potrzebujesz jednego z nich, a nie ma go w menu.

Za to zachowanie odpowiada ustawienie respectGitignore. Jest domyślnie włączone, więc pliki z .gitignore nie pojawiają się w menu. Jeśli chcesz je zobaczyć, zmień wartość na false:

{
  "respectGitignore": false
}

Możesz zrobić to samo bez edytowania pliku, używając w Claude Code polecenia /config. Przełącznik nazywa się „Respect .gitignore in file picker”. Odznacz tę opcję, a ukryte pliki wrócą do menu.

Ważne zastrzeżenie: respectGitignore dotyczy tylko menu @ i nie ma nic wspólnego z dostępem do plików. Nawet jeśli plik jest ukryty na liście, zawsze możesz wpisać jego ścieżkę ręcznie, a Claude go odczyta. Menu ułatwia wybór plików, ale nie określa granic dostępu.

Co zrobić, jeśli Claude Code nie może odczytać konkretnego pliku?#

Jeśli folder na pewno jest właściwy, dostęp jest otwarty, a Claude nadal nie chce odczytać konkretnego pliku, najpewniej jest on objęty ograniczeniem. Ograniczenia znajdują się w pliku ustawień settings.json i są dwóch rodzajów.

Pierwszy rodzaj to ograniczenia dotyczące konkretnych plików. W ustawieniach są to reguły deny, które najczęściej dotyczą pliku .env zawierającego klucze i hasła:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Taka reguła blokuje Claude dostęp do wskazanych plików — i jest to zamierzone. Klucze i hasła nie powinny trafiać do rozmowy z modelem, dlatego pliki .env są domyślnie chronione. Jeśli Claude nie chce odczytać .env ani podobnego pliku zawierającego poufne dane, działa zgodnie z założeniami; nie usuwaj tego ograniczenia bez przekonującego powodu.

Drugi rodzaj to ogólne ograniczenie dotyczące wszystkiego poza folderami roboczymi. Odpowiada za nie ustawienie blockReadsOutsideWorkingDirectories. Gdy jest włączone, Claude odmawia odczytania dowolnego pliku poza katalogiem roboczym, nawet jeśli próbujesz otworzyć go bezpośrednio. Jeśli ustawiono je na true, a potrzebujesz zewnętrznego pliku, dodaj jego folder za pomocą /add-dir albo wyłącz to ograniczenie:

{
  "permissions": {
    "blockReadsOutsideWorkingDirectories": false
  }
}

To ustawienie wprowadzono w wersji 2.1.257. Jeśli wypróbowano już wszystko inne, a plik nadal jest niedostępny, sprawdź zarówno reguły deny, jak i blockReadsOutsideWorkingDirectories.

Od czego zacząć, gdy Claude Code nie widzi plików?#

Oto krótki plan, który możesz wykonać po kolei.

1. Sprawdź folder roboczy: poproś Claude o wyświetlenie bieżącego katalogu za pomocą pwd i porównaj go z lokalizacją projektu.
2. Jeśli foldery się różnią, uruchom Claude ponownie z właściwego folderu (cd project, a następnie claude) albo przejdź tam poleceniem /cd.
3. Potrzebujesz plików z sąsiedniego folderu? Dodaj go poleceniem /add-dir albo flagą --add-dir przy uruchamianiu Claude.
4. Plik z podfolderu nie trafił do kontekstu? Podaj Claude jego ścieżkę bezpośrednio albo poproś o odczytanie pliku.
5. Brakuje pliku w menu @? Chodzi o .gitignore. Ustaw respectGitignore na false albo odznacz pole w /config.
6. Konkretny plik jest zablokowany? Sprawdź reguły deny i blockReadsOutsideWorkingDirectories w settings.json.

W dziewięciu przypadkach na dziesięć pierwszy krok rozwiązuje problem: Claude został uruchomiony z niewłaściwego folderu. Dostęp do plików to podstawa, ale sam nie zbuduje projektu za ciebie. Szczegółowo opisałem, jak budować kontekst Claude, aby miał na uwadze cały projekt i nie gubił wątku, w poradniku o Second Brain w Claude Code.

Dodatkowe materiały na temat pracy z narzędziami znajdziesz w dokumentacji Ailoot.