Claude Code w terminalu: agent Anthropic, który pracuje na plikach projektu
Jak uruchomić Claude Code na Windows, macOS i Linux: wymagania systemowe, instalator natywny, WinGet, Homebrew, podpisane repozytoria apt, dnf i apk oraz npm, weryfikacja podpisu wydania, logowanie i kolejność wyboru poświadczeń, tryby uprawnień i reguły allow, ask i deny, ścieżki chronione, sandbox poleceń powłoki, plik CLAUDE.md, pierwsze zadanie z kryteriami akceptacji, koszty, prywatność, błędy i deinstalacja.
Claude Code to nie okno czatu z przyciskiem kopiowania. To program uruchamiany w terminalu wewnątrz katalogu projektu: czyta pliki, wprowadza zmiany, uruchamia polecenia powłoki i pytania o Git zamienia w rozmowę. (Quickstart) Konsekwencja jest oczywista i wcale nie drugorzędna - narzędzie, które modyfikuje pliki na dysku, wymaga świadomej decyzji o tym, co wolno mu zrobić bez pytania.
Poniżej jedna kompletna ścieżka: wymagania, instalacja na Windows, macOS i Linux, logowanie i przechowywanie poświadczeń, tryby uprawnień i reguły, plik CLAUDE.md, pierwsze zadanie na małym projekcie z kryteriami akceptacji, sandbox poleceń powłoki, koszty, prywatność, typowe błędy oraz deinstalacja.
Instrukcja opiera się na dokumentacji Anthropic w stanie na 8 września 2026 roku. Ta data jest tu ważniejsza niż zwykle: dokumentacja Claude Code zmienia się bardzo szybko i wersjonuje zachowania prawie w każdej sekcji („wymaga wersji 2.1.xxx lub nowszej”), więc przy rozbieżności rozstrzyga bieżąca dokumentacja producenta i własne claude --version, a nie ten tekst. Zakres jest ograniczony: opisano interfejs terminalowy (CLI), a nie aplikację desktopową, rozszerzenia do IDE, wersję webową ani integracje CI - te mają własną dokumentację i częściowo inne zachowanie. Nie przeprowadzono testów instalacji ani uruchomienia na żadnym z trzech systemów; wszystkie komendy, ścieżki i zachowania pochodzą z dokumentacji producenta, nie z zaobserwowanego przebiegu.
Wymagania
Producent podaje je zwięźle i warto je sprawdzić przed pobraniem czegokolwiek.
Systemy operacyjne: macOS 13.0 lub nowszy, Windows 10 w wersji 1809 lub nowszej albo Windows Server 2019 lub nowszy, Ubuntu 20.04 lub nowszy, Debian 10 lub nowszy, Alpine Linux 3.19 lub nowszy. (Advanced setup)
Sprzęt: co najmniej 4 GB RAM, procesor x64 lub ARM64. (Advanced setup)
Sieć: połączenie z internetem jest wymagane. (Advanced setup)
Powłoka: Bash, Zsh, PowerShell lub CMD. (Advanced setup)
Lokalizacja: kraje wspierane przez Anthropic. (Advanced setup) Przy próbie uruchomienia poza nimi pojawia się komunikat App unavailable in region. (Troubleshoot installation and login)
Konto: Claude Code wymaga konta Pro, Max, Team, Enterprise albo Console. Darmowy plan Claude.ai nie obejmuje dostępu do Claude Code. Alternatywą są zewnętrzni dostawcy API - Amazon Bedrock, Google Cloud's Agent Platform (dawniej i nadal w części adresów dokumentacji: Google Vertex AI) lub Microsoft Foundry. (Advanced setup)
Zależność dodatkowa: ripgrep, zwykle dołączany razem z Claude Code. (Advanced setup)
Instalacja: trzy systemy
Producent podaje trzy główne drogi: instalator natywny, menedżery pakietów systemowych oraz npm. Wybór ma konkretne konsekwencje dla aktualizacji, więc opłaca się go podjąć świadomie.
Windows
W PowerShellu:
irm https://claude.ai/install.ps1 | iex
W wierszu polecenia CMD:
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
Alternatywnie WinGet:
winget install Anthropic.ClaudeCode
Wszystkie trzy komendy pochodzą z dokumentacji instalacji. (Advanced setup)
Pomyłka co do powłoki jest na tyle częsta, że producent opisuje ją wprost: komunikat The token '&&' is not a valid statement separator oznacza, że wpisano komendę CMD w PowerShellu, a 'irm' is not recognized as an internal or external command - że komendę PowerShella wpisano w CMD. Rozpoznanie jest proste: znak zachęty pokazuje PS C:\ w PowerShellu i C:\ bez PS w CMD. (Advanced setup) Instalacja nie wymaga uprawnień administratora. (Advanced setup)
Na Windows do wyboru są trzy warianty pracy, różniące się przede wszystkim obsługą sandboksu. Wariant natywny nie wymaga niczego dodatkowego, a Git for Windows jest opcjonalny, ale sandbox nie jest w nim obsługiwany - to opcja dla projektów i narzędzi natywnie windowsowych. WSL 2 wymaga włączonego WSL 2, obsługuje sandbox i jest właściwym wyborem przy łańcuchach narzędzi linuksowych albo gdy potrzebne jest izolowane wykonywanie poleceń. WSL 1 nie obsługuje sandboksu i jest opcją tylko wtedy, gdy WSL 2 jest niedostępny. (Advanced setup)
Git for Windows zmienia zachowanie narzędzia powłokowego. Bez niego Claude Code uruchamia polecenia przez narzędzie PowerShell; z nim korzysta z Git Bash jako narzędzia Bash. (Advanced setup) Gdy Git Bash jest zainstalowany, ale nie zostaje znaleziony, ścieżkę wskazuje się w pliku ustawień:
{
"env": {
"CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
}
}
Przy zainstalowanym Git for Windows narzędzie PowerShell jest dostępne obok Bash: w kontach claude.ai i Console włączone domyślnie, a w sesjach na Amazon Bedrock, Google Cloud's Agent Platform i Microsoft Foundry po ustawieniu CLAUDE_CODE_USE_POWERSHELL_TOOL=1. Wartość 0 wyłącza to narzędzie. (Advanced setup)
Przy pracy w WSL instalację przeprowadza się już wewnątrz dystrybucji, instalatorem linuksowym, a claude uruchamia się z terminala WSL, a nie z PowerShella czy CMD. (Advanced setup)
Jedna uwaga bezpieczeństwa specyficzna dla Windows: producent odradza włączanie WebDAV oraz udostępnianie Claude Code ścieżek w rodzaju \\*, które mogą zawierać podkatalogi WebDAV. WebDAV został przez Microsoft uznany za przestarzały ze względu na ryzyko bezpieczeństwa, a jego włączenie może pozwolić Claude Code wywoływać żądania sieciowe do zdalnych hostów z pominięciem systemu uprawnień. (Security)
macOS
Instalator natywny:
curl -fsSL https://claude.ai/install.sh | bash
Alternatywnie Homebrew:
brew install --cask claude-code
Homebrew udostępnia dwa caski i różnica jest istotna. Cask claude-code śledzi kanał stabilny, zwykle mniej więcej tydzień za bieżącym, pomijający wydania z poważnymi regresjami; claude-code@latest śledzi kanał najnowszy i dostaje wersje od razu po wydaniu. Instalacje przez Homebrew nie aktualizują się same - trzeba uruchomić brew upgrade claude-code albo brew upgrade claude-code@latest, zależnie od zainstalowanego caska. (Advanced setup)
Dokumentacja nie wprowadza w instalacji rozróżnienia między Apple Silicon a Intelem po stronie komend - obie architektury obsługuje ten sam instalator, a różnica pojawia się dopiero na liście platform pakietu npm, gdzie wymienione są osobno darwin-arm64 i darwin-x64. (Advanced setup) Wymóg wersji systemu jest natomiast twardy: przy macOS starszym niż 13.0 program kończy się błędami ładowania w rodzaju dyld: Symbol not found albo dyld: cannot load, a alternatywne metody instalacji pobierają tę samą binarkę i tego nie rozwiążą - potrzebna jest aktualizacja systemu. (Troubleshoot installation and login)
Linux
Instalator natywny jest ten sam co na macOS:
curl -fsSL https://claude.ai/install.sh | bash
Anthropic publikuje też podpisane repozytoria apt, dnf i apk. Każde ma dwa kanały: stable z wersją zwykle około tygodniowego opóźnienia, pomijającą wydania z poważnymi regresjami, oraz latest z każdym wydaniem od razu po publikacji. Instalacje z menedżera pakietów nie aktualizują się przez Claude Code - aktualizacje przychodzą normalnym mechanizmem aktualizacji systemu. (Advanced setup)
Dla Debiana i Ubuntu, kanał stable. Zanim padnie pierwsza komenda, jedna rzecz do sprawdzenia: procedura pobiera klucz przez curl i weryfikuje go przez gpg, a świeże instalacje Debiana i Ubuntu mogą nie mieć żadnego z nich. Gdy któreś polecenie zgłasza command not found, doinstalowuje się oba:
sudo apt install curl gnupg
(Advanced setup) Właściwa procedura:
sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://downloads.claude.ai/keys/claude-code.asc \
-o /etc/apt/keyrings/claude-code.asc
echo "deb [signed-by=/etc/apt/keyrings/claude-code.asc] https://downloads.claude.ai/claude-code/apt/stable stable main" \
| sudo tee /etc/apt/sources.list.d/claude-code.list
sudo apt update
sudo apt install claude-code
Przed zaufaniem kluczowi trzeba zweryfikować jego odcisk palca: gpg --show-keys /etc/apt/keyrings/claude-code.asc powinno zgłosić 31DD DE24 DDFA B679 F42D 7BD2 BAA9 29FF 1A7E CACE. Gdy gpg zgłasza, że pliku nie da się otworzyć albo że nie zawiera poprawnych danych OpenPGP, pobranie klucza się nie powiodło lub zwróciło niewłaściwą treść - trzeba sprawdzić, czy sieć dociera do downloads.claude.ai, i powtórzyć pobranie. Nieudane pobranie klucza nie zatrzymuje procedury od razu, tylko odzywa się później błędem NO_PUBKEY BAA929FF1A7ECACE przy apt update. Późniejsza aktualizacja to sudo apt update && sudo apt upgrade claude-code. (Advanced setup)
Dla Fedory i RHEL, kanał stable:
sudo tee /etc/yum.repos.d/claude-code.repo <<'EOF'
[claude-code]
name=Claude Code
baseurl=https://downloads.claude.ai/claude-code/rpm/stable
enabled=1
gpgcheck=1
gpgkey=https://downloads.claude.ai/keys/claude-code.asc
EOF
sudo dnf install claude-code
dnf pobiera klucz przy pierwszej instalacji i prosi o potwierdzenie odcisku - ten sam ciąg 31DD DE24 DDFA B679 F42D 7BD2 BAA9 29FF 1A7E CACE. Aktualizacja: sudo dnf upgrade claude-code. (Advanced setup)
Dla Alpine, kanał stable:
wget -O /etc/apk/keys/claude-code.rsa.pub \
https://downloads.claude.ai/keys/claude-code.rsa.pub
echo "https://downloads.claude.ai/claude-code/apk/stable" >> /etc/apk/repositories
apk add claude-code
Klucz weryfikuje się przez sha256sum /etc/apk/keys/claude-code.rsa.pub, które powinno zwrócić 395759c1f7449ef4cdef305a42e820f3c766d6090d142634ebdb049f113168b6. Aktualizacja: apk update && apk upgrade claude-code. (Advanced setup)
Alpine i inne dystrybucje oparte na musl lub uClibc wymagają przy instalatorze natywnym dwóch rzeczy naraz: bash i curl do samej komendy instalacyjnej oraz libgcc, libstdc++ i ripgrep w czasie działania. Alpine nie ma domyślnie ani bash, ani curl, więc udokumentowana komenda instalacyjna curl -fsSL https://claude.ai/install.sh | bash kończy się na czystym systemie błędem not found, dopóki się ich nie doinstaluje. Komplet wygląda tak:
apk add bash curl libgcc libstdc++ ripgrep
Jest jeszcze jedna pułapka: ripgrep leży na Alpine w repozytorium community. Gdy apk zgłasza brak pakietu, dopisuje się to repozytorium do /etc/apk/repositories, zgodnie z własną wersją Alpine:
echo "https://dl-cdn.alpinelinux.org/alpine/v3.22/community" >> /etc/apk/repositories
Potem apk update odświeża indeks pakietów i można powtórzyć apk add.
Po instalacji pakietów ustawia się jeszcze USE_BUILTIN_RIPGREP na 0:
{
"env": {
"USE_BUILTIN_RIPGREP": "0"
}
}
Instalacja przez npm
npm install -g @anthropic-ai/claude-code
Od wersji Claude Code 2.1.198 pakiet wymaga Node.js 22 lub nowszego. Na starszym Node.js instalacja nie kończy się błędem: npm wypisuje ostrzeżenie EBADENGINE, po czym instalacja przechodzi i claude działa - pakiet pobiera bowiem binarkę natywną, która w czasie działania nie korzysta z Node.js. To ostrzeżenie warto więc rozpoznać jako informację o niespełnionym wymaganiu silnika, a nie jako nieudaną instalację. Sam pakiet instaluje tę samą natywną binarkę co instalator samodzielny: npm pobiera ją jako opcjonalną zależność zależną od platformy, na przykład @anthropic-ai/claude-code-darwin-arm64, a krok postinstall wstawia ją na miejsce. Zainstalowana binarka claude sama nie wywołuje Node.js. Obsługiwane platformy to darwin-arm64, darwin-x64, linux-x64, linux-arm64, linux-x64-musl, linux-arm64-musl, win32-x64 i win32-arm64; menedżer pakietów musi zezwalać na zależności opcjonalne. Aktualizację instalacji npm robi się przez npm install -g @anthropic-ai/claude-code@latest; producent odradza npm update -g, bo to polecenie respektuje zakres semver z pierwotnej instalacji i może nie przenieść na najnowsze wydanie. Odradza też sudo npm install -g ze względu na problemy z uprawnieniami i ryzyko bezpieczeństwa. (Advanced setup)
Weryfikacja instalacji
claude --version
Polecenie wypisuje numer wersji, po którym następuje (Claude Code). (Quickstart) Dokładniejsze sprawdzenie instalacji i konfiguracji daje:
claude doctor
Aktualizacje
Instalacje natywne aktualizują się w tle: Claude Code sprawdza aktualizacje przy starcie i okresowo w trakcie pracy, pobiera i instaluje je w tle, a wchodzą w życie przy kolejnym uruchomieniu. Wynik ostatniej próby aktualizacji pokazuje claude doctor. Instalacje przez Homebrew, WinGet, apt, dnf i apk domyślnie nie aktualizują się same. (Advanced setup)
Kanał wydań ustawia klucz autoUpdatesChannel: "latest" (domyślnie) daje nowe funkcje od razu po wydaniu, "stable" wersję zwykle około tygodnia starszą, pomijającą wydania z poważnymi regresjami. (Advanced setup)
{
"autoUpdatesChannel": "stable"
}
Ręczna aktualizacja bez czekania na sprawdzenie w tle:
claude update
Wyłączenie automatycznych aktualizacji to DISABLE_AUTOUPDATER ustawione na "1" w kluczu env pliku ustawień; zatrzymuje ono wyłącznie sprawdzanie w tle, bo claude update i claude install nadal działają. Zablokowanie wszystkich dróg aktualizacji, łącznie z ręcznymi, wymaga DISABLE_UPDATES. (Advanced setup)
Weryfikacja integralności
Każde wydanie publikuje manifest.json z sumami kontrolnymi SHA256 dla wszystkich binarek platformowych, a sam manifest jest podpisany kluczem GPG Anthropic - weryfikacja podpisu manifestu weryfikuje więc pośrednio każdą wymienioną w nim binarkę. (Advanced setup) Odcisk klucza podpisującego to 31DD DE24 DDFA B679 F42D 7BD2 BAA9 29FF 1A7E CACE, a poprawny wynik gpg --verify manifest.json.sig manifest.json zawiera linię Good signature from "Anthropic Claude Code Release Signing <security@anthropic.com>". Ostrzeżenie WARNING: This key is not certified with a trusted signature! jest przy świeżo zaimportowanym kluczu oczekiwane. (Advanced setup) Podpisy manifestów są dostępne dla wydań od 2.1.89 wzwyż; wcześniejsze publikują sumy kontrolne bez podpisu odłączonego. (Advanced setup)
Poza tym binarki mają podpisy natywne dla platformy: na macOS podpisane przez „Anthropic PBC” i notaryzowane przez Apple (weryfikacja codesign --verify --verbose ./claude), na Windows podpisane przez „Anthropic, PBC” (weryfikacja Get-AuthenticodeSignature .\claude.exe). Binarki linuksowe nie są podpisywane indywidualnie - przy pobraniu bezpośrednim weryfikuje się je podpisem manifestu, a przy instalacji z apt, dnf lub apk robi to menedżer pakietów kluczem repozytorium. (Advanced setup)
Logowanie
Po instalacji wystarczy uruchomić claude w katalogu projektu. Przy pierwszym uruchomieniu program otwiera okno przeglądarki do zalogowania; jeśli przeglądarka nie otworzy się sama, klawisz c kopiuje adres logowania do schowka. (Authentication)
Do wyboru są konta:
- Claude Pro lub Max - logowanie kontem Claude.ai;
- Claude for Teams lub Enterprise - konto Claude.ai, do którego zaprosił administrator zespołu;
- Claude Console - poświadczenia Console, po wcześniejszym zaproszeniu przez administratora;
- Dostawcy chmurowi - Amazon Bedrock, Google Cloud's Agent Platform lub Microsoft Foundry; wymagają ustawienia zmiennych środowiskowych przed uruchomieniem
claudei nie potrzebują logowania w przeglądarce. Nazwa zmiennej dla platformy Google pozostaje przy tym historyczna:CLAUDE_CODE_USE_VERTEX. (Authentication)
Wylogowanie i ponowne uwierzytelnienie robi się poleceniem /logout w wierszu Claude Code, a przełączenie konta - /login. (Authentication, Quickstart) Przy pierwszym logowaniu kontem Console tworzona jest automatycznie przestrzeń robocza „Claude Code” w Console, na potrzeby scentralizowanego śledzenia kosztów. (Quickstart)
Gdzie leżą poświadczenia
Na macOS poświadczenia trafiają do zaszyfrowanego pęku kluczy systemu. Na Linuksie i Windows przechowywane są w ~/.claude/.credentials.json albo w katalogu wskazanym zmienną $CLAUDE_CONFIG_DIR, jeśli jest ustawiona; na Linuksie plik zapisywany jest z uprawnieniami 0600, a na Windows dziedziczy kontrolę dostępu katalogu profilu użytkownika. (Authentication)
Kolejność wyboru poświadczeń
To najczęstsze źródło zamieszania przy współistnieniu subskrypcji i klucza API. Gdy dostępnych jest kilka poświadczeń naraz, Claude Code wybiera je w tej kolejności:
- poświadczenia dostawcy chmurowego, gdy ustawiono
CLAUDE_CODE_USE_BEDROCK,CLAUDE_CODE_USE_VERTEXalboCLAUDE_CODE_USE_FOUNDRY; - zmienna
ANTHROPIC_AUTH_TOKEN, wysyłana jako nagłówekAuthorization: Bearer- do routowania przez bramę lub proxy LLM uwierzytelniające się tokenami bearer; - zmienna
ANTHROPIC_API_KEY, wysyłana jako nagłówekX-Api-Key- do bezpośredniego dostępu do API Anthropic kluczem z Claude Console; w trybie interaktywnym program raz pyta o zatwierdzenie klucza i zapamiętuje wybór, a w trybie nieinteraktywnym (-p) klucz jest zawsze używany, gdy jest obecny; - wynik skryptu
apiKeyHelper- do poświadczeń dynamicznych lub rotowanych; - poświadczenia OAuth subskrypcji z
/login- domyślne dla użytkowników Pro, Max, Team i Enterprise. (Authentication)
Skutek praktyczny jest opisany wprost: aktywna subskrypcja Claude przy jednoczesnym ANTHROPIC_API_KEY w środowisku oznacza, że po zatwierdzeniu klucz ma pierwszeństwo. Gdy klucz należy do wyłączonej lub wygasłej organizacji, kończy się to błędami uwierzytelniania. Naprawa: unset ANTHROPIC_API_KEY, a następnie /status, żeby potwierdzić, która metoda jest aktywna. (Authentication)
Zakres działania tych mechanizmów też jest ograniczony: apiKeyHelper, ANTHROPIC_API_KEY i ANTHROPIC_AUTH_TOKEN dotyczą wyłącznie sesji CLI w terminalu - Claude Desktop i sesje zdalne używają wyłącznie OAuth i nie wywołują apiKeyHelper ani nie czytają zmiennych z kluczem API. (Authentication)
Uprawnienia: tryby i reguły
To najważniejsza część konfiguracji i miejsce, w którym warto poświęcić kilka minut przed pierwszym poważnym zadaniem.
Podstawą jest system warstwowy. W trybie ręcznym Claude Code startuje z uprawnieniami tylko do odczytu, a przed edycją plików, uruchomieniem testów czy wykonaniem polecenia pyta, przy czym można zatwierdzić czynność jednorazowo albo na stałe. Zestaw wbudowanych poleceń tylko do odczytu, takich jak ls, cat czy git status, wykonuje się bez pytania. (Security)
Zatwierdzenia zachowują się różnie w zależności od typu narzędzia. Odczyty plików i Grep nie wymagają zatwierdzenia w katalogu roboczym i katalogach dodatkowych. Polecenia Bash wymagają zatwierdzenia poza wbudowanym zestawem tylko do odczytu, a wybór „Tak, i nie pytaj ponownie” zapisuje regułę trwale, per repozytorium i polecenie. Modyfikacja plików wymaga zatwierdzenia, ale zgoda obowiązuje tylko do końca sesji. WebFetch wymaga zatwierdzenia poza wbudowanym zestawem zatwierdzonych wcześniej domen dokumentacji, a zgoda zapisuje się trwale per repozytorium i domena. WebSearch wymaga zatwierdzenia, z trwałą zgodą per repozytorium. (Configure permissions)
Trwałe zgody zapisują się do .claude/settings.local.json w katalogu głównym repozytorium Git i obowiązują w przyszłych sesjach w całym repozytorium, także w podkatalogach i drzewach roboczych. (Configure permissions)
Tryby uprawnień
| Tryb | Co działa bez pytania |
|---|---|
default |
tylko odczyty |
acceptEdits |
odczyty, edycje plików i typowe polecenia systemu plików (mkdir, touch, mv, cp i podobne) |
plan |
tylko odczyty, a przy dostępnym trybie auto także polecenia zatwierdzone przez klasyfikator |
auto |
wszystko, z kontrolą bezpieczeństwa w tle |
dontAsk |
wyłącznie narzędzia wcześniej zatwierdzone |
bypassPermissions |
wszystko |
Tryb default nosi w CLI, rozszerzeniach VS Code i JetBrains oraz aplikacji desktopowej etykietę Manual, a Claude Code przyjmuje manual jako alias; etykieta i alias wymagają wersji 2.1.200 lub nowszej. (Configure permissions)
W trakcie sesji tryby przełącza się klawiszami Shift+Tab, które cyklicznie przechodzą default → acceptEdits → plan; bieżący tryb widać na pasku stanu. Tryb można też podać przy starcie:
claude --permission-mode plan
albo ustawić na stałe przez defaultMode w pliku ustawień:
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
Tryb acceptEdits pozwala tworzyć i edytować pliki w katalogu roboczym bez pytania, a poza edycjami automatycznie zatwierdza polecenia mkdir, touch, rm, rmdir, mv, cp i sed. Automatyczne zatwierdzenie dotyczy wyłącznie ścieżek w katalogu roboczym lub w additionalDirectories; ścieżki spoza tego zakresu, zapisy do ścieżek chronionych i wszystkie pozostałe polecenia Bash nadal wymagają zatwierdzenia. (Choose a permission mode)
Tryb plan każe Claude prowadzić rozpoznanie i proponować zmiany bez ich wprowadzania: czyta pliki, uruchamia polecenia eksploracyjne i pisze plan, ale nie edytuje źródeł. Wchodzi się w niego przez Shift+Tab albo poprzedzając pojedynczy prompt komendą /plan. (Choose a permission mode)
Jeden szczegół tego trybu bywa zaskoczeniem, bo dotyczy granicy uprawnień. „Bez wprowadzania zmian” odnosi się do edycji źródeł, nie do poleceń powłoki. Gdy tryb auto jest dostępny, a ustawienie useAutoModeDuringPlan jest włączone - a domyślnie jest - to w trybie plan polecenia powłoki ocenia klasyfikator zamiast użytkownika: zatwierdzone wykonują się bez monitu, odrzucone są blokowane. Dopiero gdy tryb auto jest niedostępny, polecenia spoza wbudowanego zestawu tylko do odczytu pytają o zgodę. Tryb plan jest więc bezpieczny w tym sensie, że nie zmienia kodu, ale nie w tym, że nic się bez pytania nie wykona. (Choose a permission mode)
Tryb auto pozwala działać bez rutynowych monitów, ale nie bez kontroli: osobny model klasyfikatora ocenia czynności przed wykonaniem i blokuje te, które wykraczają poza żądanie, dotyczą nierozpoznanej infrastruktury albo wyglądają na wywołane wrogą treścią, którą Claude przeczytał. Jawne reguły typu ask nadal wymuszają monit. Producent formułuje ostrzeżenie wprost: tryb zmniejsza liczbę monitów, ale nie gwarantuje bezpieczeństwa - do użycia przy zadaniach, których ogólnemu kierunkowi się ufa, a nie zamiast przeglądu operacji wrażliwych. (Choose a permission mode)
Dostępność trybu auto zależy od kilku warunków naraz. Po stronie planu nie ma ograniczenia - tryb jest dostępny na wszystkich planach - ale na Team i Enterprise administrator może go wyłączyć dla całej organizacji, ustawiając permissions.disableAutoMode na "disable" w ustawieniach zarządzanych. Po stronie modelu na API Anthropic i na Claude Platform on AWS wymagany jest Opus 4.6 lub nowszy, Sonnet 4.6 lub nowszy albo model z rodziny Fable; na Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry i w sesjach przez bramę aplikacji Claude - wyłącznie Sonnet 5, Opus 4.7 lub nowszy oraz modele Fable. Starsze modele, w tym Sonnet 4.5, Opus 4.5, Haiku i modele claude-3, nie są wspierane u żadnego dostawcy. (Choose a permission mode)
Warto tu ominąć nieaktualną poradę, która wciąż krąży. U wymienionych dostawców chmurowych tryb auto pojawia się dziś w cyklu Shift+Tab domyślnie; obecność w cyklu nie zmienia jednak trybu, w którym sesja startuje - ten pozostaje ustawiony przez defaultMode, czyli tryb ręczny, dopóki się go nie zmieni. Zmienna CLAUDE_CODE_ENABLE_AUTO_MODE była potrzebna w wersjach od 2.1.158 do 2.1.206; od 2.1.207 jest przyjmowana wyłącznie dla zgodności wstecznej i nie robi nic. Ustawianie jej dziś to zatem krok bez efektu. (Choose a permission mode)
Tryb bypassPermissions pomija monity o uprawnienia, łącznie z zapisami do ścieżek chronionych. Producent stawia sprawę jednoznacznie: należy go używać wyłącznie w środowiskach izolowanych - kontenerach, maszynach wirtualnych czy kontenerach deweloperskich bez dostępu do internetu - gdzie Claude Code nie może uszkodzić systemu hosta. (Configure permissions, Choose a permission mode) Tryb nie chroni przed wstrzyknięciem promptu ani niezamierzonymi działaniami; alternatywą z kontrolą w tle jest tryb auto. (Choose a permission mode) Na Linuksie i macOS Claude Code odmawia startu w tym trybie przy uruchomieniu jako root lub przez sudo. (Choose a permission mode) Do wejścia w ten tryb potrzebna jest jedna z flag włączających, na przykład:
claude --permission-mode bypassPermissions
Ścieżki chronione
We wszystkich trybach poza bypassPermissions zapisy do wąskiego zestawu ścieżek nigdy nie są zatwierdzane automatycznie, co ma zapobiegać przypadkowemu uszkodzeniu stanu repozytorium i konfiguracji samego Claude. W trybach default, acceptEdits i plan takie zapisy wywołują monit, w trybie auto trafiają do klasyfikatora, w dontAsk są odrzucane, a w bypassPermissions dozwolone. (Choose a permission mode)
Chronione katalogi to .git, .config/git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn oraz .claude z wyjątkiem .claude/worktrees. Wśród chronionych plików są między innymi .gitconfig, .gitmodules, pliki konfiguracyjne powłok (.bashrc, .bash_profile, .zshrc, .profile, .envrc i pokrewne), .npmrc, .yarnrc, bunfig.toml, .devcontainer.json, .mcp.json i .claude.json. (Choose a permission mode)
Istotne: reguły permissions.allow z plików ustawień nie zatwierdzają z góry zapisów do ścieżek chronionych, bo kontrola bezpieczeństwa wykonuje się przed oceną reguł allow - wpis w rodzaju Edit(.claude/**) nie zmienia więc zachowania z tabeli wyżej. (Choose a permission mode)
Reguły: allow, ask, deny
Reguły przegląda się i zmienia poleceniem /permissions, które pokazuje wszystkie reguły oraz plik settings.json, z którego każda pochodzi. Reguły allow pozwalają używać wskazanego narzędzia bez zatwierdzania, ask wymuszają potwierdzenie, deny blokują użycie. (Configure permissions)
Kolejność oceniania jest sztywna: najpierw deny, potem ask, na końcu allow; pierwsze dopasowanie w tej kolejności rozstrzyga, a szczegółowość reguły niczego nie zmienia. Szeroka reguła deny w rodzaju Bash(aws *) blokuje każde pasujące wywołanie, także takie, które pasuje do węższej reguły allow jak Bash(aws s3 ls) - reguła deny nie może więc nieść wyjątków. Ta sama zasada dotyczy relacji ask do allow. (Configure permissions)
Reguły mają format Narzędzie albo Narzędzie(specyfikator). Sama nazwa narzędzia dopasowuje wszystkie jego użycia. Jako reguła deny sama nazwa usuwa narzędzie z kontekstu Claude w całości, więc model w ogóle go nie widzi; reguła zakresowa w rodzaju Bash(rm *) zostawia narzędzie dostępne i blokuje pasujące wywołania w momencie próby. (Configure permissions)
Przykład konfiguracji, w której Claude uruchamia skrypty npm i commituje bez pytania, ale nie może wypchnąć zmian:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
"deny": [
"Bash(git push *)"
]
}
}
Znak * w regule Bash dopasowuje dowolny tekst, także spacje, więc jedna reguła obejmuje rodzinę poleceń; reguła bez * dopasowuje jedno dokładne polecenie. Gwiazdkę stawia się po podkomendzie: w git log --oneline main programem jest git, a podkomendą log, i to ona ogranicza zasięg reguły. Bash(git log *) pozwala tylko na git log, a Bash(git *) na każde polecenie gita. Claude Code ostrzega przy starcie o regule allow z gwiazdką przed podkomendą, na przykład Bash(git * main). (Configure permissions)
Kilka niuansów dopasowania warto znać, bo bywają zaskakujące. Gwiazdka na końcu poprzedzona spacją dopasowuje też samo polecenie: Bash(ls *) pasuje do ls. Spacja przed końcową gwiazdką jest częścią reguły, więc Bash(ls *) nie pasuje do lsof, a Bash(ls*) już tak. W regule Bash(git * main) gwiazdka zastępuje podkomendę, więc dopasowuje każdą podkomendę gita i każdą opcję przed nią, łącznie z -c, która każe gitowi uruchomić wskazany program. (Configure permissions)
Ostatnia rzecz, o której łatwo zapomnieć: reguły uprawnień egzekwuje Claude Code, a nie model. Instrukcje w promcie czy w CLAUDE.md kształtują to, co Claude próbuje zrobić, ale nie zmieniają tego, na co Claude Code pozwala. Przyznawanie i odbieranie dostępu odbywa się przez /permissions, reguły, tryb uprawnień albo hak PreToolUse. (Configure permissions)
Katalogi robocze
W trybie ręcznym Claude Code może zapisywać tylko do katalogu, w którym został uruchomiony, i jego podkatalogów, a modyfikacja plików w katalogach nadrzędnych wymaga wyraźnej zgody. W tym samym trybie pyta też przed odczytem ścieżek spoza tej granicy narzędziami Read, Grep i Glob. (Security)
Granicę rozszerza się na trzy sposoby: argumentem --add-dir <ścieżka> przy starcie, poleceniem /add-dir w trakcie sesji albo trwale przez additionalDirectories w pliku ustawień. (Configure permissions)
Na Windows jest tu jedno ograniczenie: większości ścieżek sieciowych, na przykład udziału UNC \\server\share, nie da się dodać jako katalogów roboczych, bo samo ich rozwiązanie może skontaktować się z hostem. Rozwiązaniem jest zmapowanie udziału na literę dysku i przekazanie jej przez --add-dir przy starcie. (Configure permissions)
Sandbox poleceń powłoki
Sandbox pozwala uruchamiać większość poleceń powłoki bez zatrzymywania się na pytania: zamiast zatwierdzać każde polecenie, definiuje się, do jakich plików i domen sieciowych mogą sięgać polecenia, a granicę egzekwuje system operacyjny dla każdego polecenia Bash i jego procesów potomnych. (Configure the sandboxed Bash tool)
Dostępność zależy od systemu: sandbox działa na macOS, Linuksie i WSL2, a natywny Windows nie jest obsługiwany - na Windows trzeba uruchomić Claude Code w dystrybucji WSL2. Na macOS nie ma nic do instalowania, bo sandbox korzysta z wbudowanego mechanizmu Seatbelt. Na Linuksie i WSL2 potrzebne są dwa pakiety: bubblewrap, czyli nieuprzywilejowane narzędzie sandboksujące egzekwujące izolację systemu plików, oraz socat, przekaźnik kierujący ruch sieciowy przez proxy sandboksu. (Configure the sandboxed Bash tool)
sudo apt-get install bubblewrap socat
albo, na Fedorze:
sudo dnf install bubblewrap socat
(Configure the sandboxed Bash tool)
Panel sandboksu otwiera polecenie /sandbox, z zakładkami Mode (sposób zatwierdzania poleceń sandboksowanych), Overrides (czy polecenia nieudane w sandboksie mogą uruchomić się poza nim) i Config (rozstrzygnięte ustawienia). Gdy widoczna jest wyłącznie zakładka Dependencies, brakuje wymaganego pakietu - po jego instalacji trzeba zrestartować Claude Code, bo sprawdzenie zależności wykonuje się przy starcie. (Configure the sandboxed Bash tool)
Na Ubuntu 24.04 i nowszych domyślna zasada AppArmor uniemożliwia bubblewrap tworzenie przestrzeni nazw użytkownika potrzebnych do izolacji. Sprawdzenie, działające także wewnątrz WSL2:
sysctl kernel.apparmor_restrict_unprivileged_userns
Gdy polecenie zwraca 0 albo zgłasza błąd No such file or directory, czyli klucz nie istnieje, krok można pominąć. Gdy zwraca 1, trzeba dodać profil AppArmor przyznający bwrap tę możliwość:
sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>
profile bwrap /usr/bin/bwrap flags=(unconfined) {
userns,
include if exists <local/bwrap>
}
EOF
Profil dotyczy wyłącznie samego bwrap, a nie poleceń uruchamianych w sandboksie. Na koniec przeładowanie AppArmora, żeby wszedł w życie:
sudo systemctl reload apparmor
(Configure the sandboxed Bash tool) Warto zauważyć różnicę wobec Codeksa z pierwszej części serii: tam procedura polega na dograniu gotowego profilu bwrap-userns-restrict z pakietów Ubuntu, tu producent podaje własny, minimalny profil do utworzenia ręcznie.
Domyślne granice sandboksu wyglądają tak: zapis i odczyt w bieżącym katalogu roboczym i jego podkatalogach oraz w katalogu tymczasowym sesji, na który wskazuje $TMPDIR; odczyt całego komputera z wyjątkiem wybranych katalogów zablokowanych. Ta domyślna reguła odczytu nadal pozwala czytać pliki poświadczeń, na przykład ~/.aws/credentials i ~/.ssh/. (Configure the sandboxed Bash tool) To jeden z ważniejszych szczegółów w całej konfiguracji: sam sandbox nie chroni kluczy prywatnych przed odczytem, dopóki nie zostanie o to poproszony.
Są na to dwie drogi i różnią się zasięgiem. Prostsza to dopisanie ścieżek do denyRead, co blokuje ich odczyt wewnątrz sandboksu. Pełniejsza to osobny blok sandbox.credentials, który poza blokowaniem plików potrafi też usunąć wskazane zmienne środowiskowe z otoczenia sandboksowanych poleceń:
{
"sandbox": {
"enabled": true,
"credentials": {
"files": [
{ "path": "~/.aws/credentials", "mode": "deny" },
{ "path": "~/.ssh", "mode": "deny" }
],
"envVars": [
{ "name": "GITHUB_TOKEN", "mode": "deny" },
{ "name": "NPM_TOKEN", "mode": "deny" }
]
}
}
}
Ta różnica ma praktyczne znaczenie, bo - jak opisuje dalsza część tej sekcji - sandboksowane polecenia dziedziczą domyślnie środowisko procesu nadrzędnego razem z ustawionymi tam poświadczeniami. denyRead chroni pliki, a zmienne środowiskowe wymagają osobnego mechanizmu. Producent zaznacza przy tym, że nie ma wbudowanej listy domyślnie chronionych poświadczeń: chronione jest wyłącznie to, co samodzielnie się wymieni. (Configure the sandboxed Bash tool)
Rozszerzenie zapisu poza domyślne katalogi:
{
"sandbox": {
"enabled": true,
"filesystem": {
"allowWrite": ["~/.kube", "/tmp/build"]
}
}
}
Ścieżki egzekwowane są na poziomie systemu operacyjnego, więc obowiązują wszystkie polecenia w sandboksie i ich procesy potomne; producent zaleca to podejście zamiast wyłączania narzędzia z sandboksu przez excludedCommands. (Configure the sandboxed Bash tool)
Blokada odczytu katalogu domowego z wyjątkiem projektu, w ustawieniach projektowych:
{
"sandbox": {
"enabled": true,
"filesystem": {
"denyRead": ["~/"],
"allowRead": ["."]
}
}
}
Kropka w allowRead rozwija się do katalogu głównego projektu tylko dlatego, że konfiguracja leży w ustawieniach projektu; w ~/.claude/settings.json rozwinęłaby się do ~/.claude, a pliki projektu pozostałyby zablokowane. (Configure the sandboxed Bash tool)
Domyślnie, gdy sandbox nie może wystartować z powodu braku zależności albo nieobsługiwanej platformy, Claude Code wyświetla ostrzeżenie i uruchamia polecenia bez sandboksu. Zamianę tego na twardy błąd daje sandbox.failIfUnavailable ustawione na true. (Configure the sandboxed Bash tool)
Nawet w trybie automatycznego zezwalania obowiązują jawne reguły deny, a polecenia rm lub rmdir wymierzone w /, katalog domowy albo inne krytyczne ścieżki systemowe nadal wywołują monit. (Configure the sandboxed Bash tool)
Zakres sandboksu też ma granice. Izoluje on podprocesy Bash, natomiast wbudowane narzędzia plikowe Read, Edit i Write korzystają bezpośrednio z systemu uprawnień, a nie z sandboksu. Sandboksowane polecenia Bash dziedziczą domyślnie środowisko procesu nadrzędnego, łącznie z ustawionymi tam poświadczeniami; usunięcie poświadczeń Anthropic i dostawców chmurowych z podprocesów wymaga ustawienia CLAUDE_CODE_SUBPROCESS_ENV_SCRUB. (Configure the sandboxed Bash tool)
CLAUDE.md, czyli pamięć projektu
Każda sesja Claude Code zaczyna się od pustego okna kontekstu. Wiedzę między sesjami przenoszą dwa mechanizmy: pliki CLAUDE.md, czyli instrukcje pisane przez użytkownika, oraz pamięć automatyczna, czyli notatki, które Claude zapisuje sam na podstawie poprawek i preferencji. Oba ładowane są na początku każdej rozmowy, ale Claude traktuje je jako kontekst, a nie jako wymuszaną konfigurację; do zablokowania czynności niezależnie od decyzji modelu służy hak PreToolUse. (How Claude remembers your project)
Lokalizacje CLAUDE.md, w kolejności ładowania od najszerszego zakresu:
- zasady zarządzane -
/Library/Application Support/ClaudeCode/CLAUDE.mdna macOS,/etc/claude-code/CLAUDE.mdna Linuksie i WSL,C:\Program Files\ClaudeCode\CLAUDE.mdna Windows; - instrukcje użytkownika -
~/.claude/CLAUDE.md, preferencje osobiste dla wszystkich projektów; - instrukcje projektu -
./CLAUDE.mdalbo./.claude/CLAUDE.md, dzielone z zespołem przez kontrolę wersji; - instrukcje lokalne -
./CLAUDE.local.md, osobiste preferencje do projektu, dodawane do.gitignore. (How Claude remembers your project)
Pliki CLAUDE.md i CLAUDE.local.md z hierarchii katalogów powyżej katalogu roboczego ładują się przy starcie, a pliki z podkatalogów na żądanie, gdy Claude czyta pliki z tych katalogów. (How Claude remembers your project)
Szkielet pliku generuje polecenie /init, które analizuje kod i tworzy plik z komendami budowania, instrukcjami testów i wykrytymi konwencjami projektu; przy istniejącym CLAUDE.md proponuje ulepszenia zamiast go nadpisywać. (How Claude remembers your project) Potwierdzenie, że plik się wczytał, daje polecenie /context i lista pod nagłówkiem Memory files. (How Claude remembers your project)
Trzy zalecenia redakcyjne z dokumentacji, wszystkie sprawdzalne. Rozmiar: celować poniżej 200 wierszy na plik, bo dłuższe zużywają więcej kontekstu i obniżają stosowanie się do instrukcji. Struktura: nagłówki i wypunktowania zamiast gęstych akapitów. Konkretność: „Używaj wcięć dwuspacjowych” zamiast „Formatuj kod poprawnie”, „Uruchom npm test przed commitem” zamiast „Testuj zmiany”, „Obsługa API leży w src/api/handlers/” zamiast „Trzymaj pliki uporządkowane”. (How Claude remembers your project)
Jeżeli repozytorium używa już pliku AGENTS.md dla innych agentów kodujących, warto wiedzieć, że Claude Code czyta CLAUDE.md, a nie AGENTS.md. Rozwiązaniem jest CLAUDE.md importujący ten pierwszy plik, dzięki czemu oba narzędzia czytają te same instrukcje bez duplikowania:
@AGENTS.md
## Claude Code
Use plan mode for changes under `src/billing/`.
Przy braku potrzeby dodawania treści specyficznych dla Claude wystarczy dowiązanie symboliczne ln -s AGENTS.md CLAUDE.md. (How Claude remembers your project)
Jedna pułapka przy imporcie: import w pliku pamięci na poziomie projektu jest zewnętrzny, gdy jego ścieżka rozwiązuje się poza katalogiem roboczym. Przy pierwszym napotkaniu takich importów Claude Code pokazuje okno zatwierdzenia z listą plików, a odmowa trwale je wyłącza i okno się nie powtarza. Mechanizm ma chronić przed plikami, które inne osoby commitują do wspólnego projektu. (How Claude remembers your project)
Pierwsze zadanie: mała lista zadań bez backendu
Poniższe ćwiczenie jest propozycją, a nie relacją z wykonanego uruchomienia. Nie przeprowadzono go na żadnej maszynie; kroki i kryteria wynikają z udokumentowanego zachowania narzędzia.
Projekt jest celowo minimalny: strona z listą zadań w czystym HTML, CSS i JavaScripcie, bez serwera i zależności, ze stanem zapisywanym w pamięci przeglądarki.
Przygotowanie katalogu
mkdir lista-zadan
cd lista-zadan
git init
git commit --allow-empty -m "Punkt wyjścia"
Pusty commit na start daje punkt, do którego zawsze da się wrócić. Ma to znaczenie tym większe, że Claude Code oferuje też własny mechanizm cofania: /rewind albo dwukrotne naciśnięcie Escape przywraca rozmowę i kod do wcześniejszego punktu kontrolnego. (Manage costs effectively) Git i tak jest jednak siecią bezpieczeństwa niezależną od narzędzia.
Uruchomienie
cd /ścieżka/do/projektu
claude
Po uruchomieniu widać wiersz Claude Code z wersją, bieżącym modelem i katalogiem roboczym nad nim; /help pokazuje dostępne polecenia, a /resume wznawia wcześniejszą rozmowę. (Quickstart)
Warto od razu sprawdzić, w jakim trybie startuje sesja, bo domyślna wartość nie jest jednakowa dla wszystkich. Na planach Pro, Max i Team wbudowanym trybem startowym interaktywnych sesji terminalowych jest tryb auto, w którym czynności ocenia klasyfikator zamiast użytkownika, a Claude edytuje większość plików i uruchamia większość poleceń bez pytania. Na pozostałych planach wbudowanym trybem startowym jest tryb ręczny. Ustawienia własne albo organizacji mogą to zmienić, a Shift+Tab przełącza tryb w dowolnym momencie. (Quickstart)
Reguła planu to jednak dopiero ostatni krok w dłuższej liście, więc rozbieżność z oczekiwaniem nie musi oznaczać usterki. W trybie ręcznym sesja wystartuje mimo planu Pro, Max czy Team także wtedy, gdy: któryś plik ustawień ustawia disableAutoMode na "disable", pobieranie flag funkcji jest wyłączone, jest to pierwsza sesja po instalacji lub aktualizacji do wersji wprowadzającej to zachowanie, program uruchomiono nieinteraktywnie przez claude -p albo z Agent SDK, albo sesja działa na Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, Claude Platform on AWS lub przez bramę aplikacji Claude. Tryb ręczny obowiązuje też na planie Enterprise i przy kluczu Console. Poza tym samo wbudowane domyślne auto wymaga wersji 2.1.228 lub nowszej na macOS, Linuksie i WSL oraz 2.1.233 lub nowszej na natywnym Windows - na starszych wbudowanym domyślnym trybem jest ręczny. Gdy tryb auto zostanie wybrany, ale nie jest dostępny dla sesji, Claude Code startuje w trybie ręcznym. (Choose a permission mode)
Najprostsze sprawdzenie jest wizualne: pasek stanu pokazuje aktywny tryb, na przykład ⏸ manual mode on albo ⏵⏵ auto mode on. (Choose a permission mode)
Na pierwszy raz sensownym wyborem jest tryb ręczny - zobaczenie, o co narzędzie pyta, jest samo w sobie użyteczne. Tryb plan też się nadaje do rozpoznania, ale z zastrzeżeniem opisanym wyżej: przy dostępnym trybie auto polecenia powłoki ocenia w nim klasyfikator, więc część z nich wykona się bez monitu. Kto chce zobaczyć każde pytanie, powinien wybrać tryb ręczny.
Prompt na pierwsze zadanie
Cel: zbuduj w tym pustym katalogu prostą stronę z listą zadań,
działającą po otwarciu pliku index.html bezpośrednio w przeglądarce.
Kontekst: katalog jest pusty i jest repozytorium Git. Bez backendu,
bez serwera, bez menedżera pakietów.
Ograniczenia: wyłącznie index.html, styles.css i app.js; żadnych
bibliotek zewnętrznych ani odwołań do CDN; stan listy w localStorage;
interfejs po polsku.
Ukończone, gdy: da się dodać zadanie, oznaczyć je jako zrobione i usunąć,
a po odświeżeniu strony lista wygląda tak samo jak przed odświeżeniem.
Struktura promptu nie jest przypadkowa. Dokumentacja kosztów zaleca konkretne żądania zamiast ogólnych, bo mgliste polecenia w rodzaju „popraw ten kod” uruchamiają szerokie skanowanie, a konkretne pozwalają pracować efektywnie przy minimalnej liczbie odczytów plików. Zaleca też podawanie celów weryfikacji - przypadków testowych, zrzutów ekranu albo oczekiwanego wyniku - bo gdy Claude może sam sprawdzić swoją pracę, wyłapuje problemy, zanim trzeba je zgłaszać. (Manage costs effectively)
Kryteria akceptacji
Test nie polega na przeczytaniu podsumowania:
git statuspokazuje wyłącznie trzy nowe pliki. Cokolwiek poza tym oznacza, że prompt był za szeroki.git diffprzejrzany w całości. Producent stawia sprawę wprost: Claude Code ma tylko te uprawnienia, które mu przyznano, a odpowiedzialność za przegląd proponowanego kodu i poleceń pod kątem bezpieczeństwa przed zatwierdzeniem leży po stronie użytkownika. (Security)- Otwarcie
index.htmlw przeglądarce, dodanie dwóch zadań, oznaczenie jednego jako zrobione, odświeżenie klawiszemF5. Oba zadania nadal na liście, w tym samym stanie. - Wyszukanie w
app.jsciągulocalStorage- zapis musi być w kodzie, nie tylko w opisie odpowiedzi. - Brak znaczników
<script src="https://…">i<link href="https://…">windex.html.
Po zaliczeniu:
git add .
git commit -m "Lista zadań: pierwsza wersja"
Commit można też zlecić rozmową - Claude Code zamienia operacje Git w polecenia w naturalnym języku, na przykład „zatwierdź moje zmiany z opisowym komunikatem”. (Quickstart)
Drugie zadanie
Cel: dodaj filtrowanie listy - trzy przyciski Wszystkie, Aktywne, Zrobione.
Kontekst: istniejące pliki index.html, styles.css i app.js.
Ograniczenia: nie zmieniaj formatu danych zapisywanych w localStorage;
nadal bez bibliotek zewnętrznych.
Ukończone, gdy: każdy przycisk pokazuje właściwy podzbiór zadań,
a zadania zapisane przed zmianą nadal wczytują się poprawnie.
Kryterium jest tu ostrzejsze: dane zapisane przed zmianą muszą przetrwać zmianę. Najprostszy sprawdzian to dodanie kilku zadań przed drugą turą.
Przy zadaniach dłuższych albo bardziej złożonych warto zacząć od trybu plan: Shift+Tab przełącza w niego przed implementacją, Claude bada kod i proponuje podejście do zatwierdzenia, co zapobiega kosztownym poprawkom, gdy pierwotny kierunek okazuje się zły. Gdy Claude idzie w złą stronę, Escape natychmiast go zatrzymuje. (Manage costs effectively) Sens tego trybu to więc oszczędność i kierunek pracy, a nie pełna blokada wykonywania - źródeł nie zmienia, ale polecenia eksploracyjne mogą się w nim wykonać bez pytania.
Do przeglądu zmian na bieżącej gałęzi służy osobne polecenie /security-review, opisane jako doraźne przejście pod kątem bezpieczeństwa. (Security) Przegląd nie jest jednak dowodem poprawności - decyzja o przyjęciu zmiany zostaje po stronie człowieka.
Podstawowe polecenia
Polecenia powłoki, uruchamiane z terminala:
| Polecenie | Działanie |
|---|---|
claude |
tryb interaktywny |
claude "zadanie" |
tryb interaktywny z początkowym promptem |
claude -p "pytanie" |
jednorazowe zapytanie i wyjście |
claude -c |
kontynuacja ostatniej rozmowy w bieżącym katalogu |
claude -r |
wznowienie wcześniejszej rozmowy |
Polecenia sesji, wpisywane wewnątrz Claude Code: /clear czyści historię rozmowy, /help pokazuje dostępne polecenia, /exit albo dwukrotne Ctrl+D kończy pracę. (Quickstart)
Kilka skrótów, które oszczędzają czas: / pokazuje dostępne polecenia i umiejętności, Tab uzupełnia polecenia, strzałka w górę przywołuje historię, Shift+Tab przełącza tryby uprawnień. (Quickstart)
Koszty i limity
Claude Code nalicza opłaty według zużycia tokenów API; ceny planów subskrypcyjnych (Pro, Max, Team, Enterprise) są na stronie cennika. Koszt na dewelopera różni się mocno w zależności od wybranego modelu, wielkości bazy kodu i wzorców użycia, takich jak uruchamianie wielu instancji czy automatyzacja. We wdrożeniach korporacyjnych średni koszt to około 13 dolarów na dewelopera za aktywny dzień i 150-250 dolarów miesięcznie, przy czym u 90% użytkowników koszt pozostaje poniżej 30 dolarów za aktywny dzień. (Manage costs effectively) Do oszacowania wydatków własnego zespołu producent zaleca start od małej grupy pilotażowej i ustalenie punktu odniesienia przed szerszym wdrożeniem. (Manage costs effectively)
Bieżące zużycie pokazuje polecenie /usage. Blok Session na jego górze prezentuje szczegółowe statystyki tokenów bieżącej sesji, a kwotę Claude Code wylicza lokalnie z liczby tokenów według cen katalogowych - jest to szacunek, więc wiążące rozliczenie znajduje się na stronie użycia w Claude Console. Domyślnie liczy się je po cenach katalogowych, co w organizacji płacącej stawki kontraktowe daje rozjazd z fakturą; administrator może to pogodzić, ustawiając w ustawieniach zarządzanych tabelę modelPricing z własnymi stawkami - wtedy przy kwocie pojawia się adnotacja o stawkach organizacji. Ustawienie zmienia to, co Claude Code raportuje, a nie to, co Anthropic nalicza. Blok Session jest przeznaczony dla użytkowników API; subskrybenci Max i Pro mają użycie zawarte w subskrypcji, więc kwota kosztu sesji nie ma dla nich znaczenia rozliczeniowego - widzą za to paski użycia planu, statystyki aktywności i rozbicie użycia. (Manage costs effectively)
Osobna sprawa to sesje długie, które potrafią zużyć znacznie więcej limitu, niż sugerowałaby aktywność użytkownika. Powód jest strukturalny: Claude Code wysyła całą rozmowę przy każdym żądaniu, a przy każdym użyciu narzędzia idzie kolejne żądanie niosące zestaw wyników narzędzi. Dzięki buforowaniu promptów historia jest odczytywana po stawce tokenów buforowanych, ale jednowierszowe pytanie w sesji otwartej od rana i tak pociąga zużycie za całą rozmowę. Drugą przyczyną są chybienia bufora: pierwsza wiadomość po przerwie dłuższej niż czas życia bufora powoduje ponowne przetworzenie pełnego kontekstu, a czas życia to godzina przy subskrypcji i pięć minut po przejściu na kredyty użycia oraz domyślnie pięć minut przy kluczu API i u dostawców chmurowych. (Manage costs effectively)
Do tego dochodzi kompaktowanie: /compact czyta rozmowę, którą podsumowuje, więc kompaktowanie dużego kontekstu samo w sobie jest dużym żądaniem. Gdy zamiast ciągłości potrzebny jest świeży start, /clear nie kosztuje nic. (Manage costs effectively)
Claude Code zużywa też tokeny na funkcje działające w tle nawet w bezczynności - podsumowywanie wcześniejszych rozmów na potrzeby claude --resume oraz przetwarzanie części poleceń. Procesy te zużywają niewielką liczbę tokenów, zwykle poniżej 0,04 dolara na sesję, nawet bez aktywnej interakcji. (Manage costs effectively)
Sposoby na oszczędniejszą pracę są wprost wymienione: pisanie konkretnych promptów, tryb plan przy zadaniach złożonych, wczesne korygowanie kursu klawiszem Escape, podawanie celów weryfikacji oraz testowanie przyrostowe - napisać jeden plik, sprawdzić go, dopiero potem kontynuować, bo to wyłapuje problemy wtedy, gdy są tanie w naprawie. (Manage costs effectively)
Prywatność i dane
Claude Code działa lokalnie, ale do interakcji z modelem wysyła dane przez sieć: obejmują one wszystkie prompty użytkownika i wyniki modelu, szyfrowane w tranzycie przez TLS 1.2 lub nowszy. (Data usage)
Zasady trenowania różnią się między typami kont. Dla użytkowników konsumenckich (Free, Pro, Max) firma daje wybór, czy dane mogą służyć do ulepszania przyszłych modeli, i trenuje nowe modele na danych z tych kont, gdy ustawienie jest włączone - także wtedy, gdy Claude Code używany jest z tych kont. Dla użytkowników komercyjnych (Team, Enterprise, API, platformy zewnętrzne, Claude Gov) Anthropic nie trenuje modeli generatywnych na kodzie ani promptach wysyłanych do Claude Code na warunkach komercyjnych, chyba że klient sam zdecydował się udostępnić dane do ulepszania modeli, na przykład w Development Partner Program. (Data usage)
Retencja: konta konsumenckie zezwalające na wykorzystanie danych do ulepszania modeli mają okres pięcioletni, a niezezwalające trzydziestodniowy, przy czym ustawienia prywatności można zmienić w dowolnym momencie. Konta komercyjne mają standardowo trzydzieści dni, a zerowa retencja danych jest dostępna dla kwalifikujących się kont Claude for Enterprise i nie wchodzi w skład standardowego planu Enterprise - włącza ją zespół obsługi klienta po potwierdzeniu kwalifikacji. (Data usage)
Osobno działa buforowanie lokalne: klienci Claude Code przechowują transkrypty sesji lokalnie w postaci zwykłego tekstu w ~/.claude/projects/ przez domyślnie trzydzieści dni, żeby umożliwić wznawianie sesji. Okres zmienia klucz cleanupPeriodDays. (Data usage)
Jest też trzeci termin, łatwy do przeoczenia, bo dotyczy jednorazowej zgody. Po ankiecie „How is Claude doing this session?” może pojawić się osobne pytanie, czy Anthropic może obejrzeć transkrypt sesji. Sama ocena w ankiecie nie zbiera transkryptów ani treści sesji, ale zgoda w tym drugim kroku wysyła transkrypt rozmowy, transkrypty podagentów i surowy plik dziennika sesji; znane wzorce kluczy API i tokenów są przed wysłaniem redagowane, natomiast kod i zawartość plików idą bez zmian. Tak udostępnione transkrypty przechowywane są do sześciu miesięcy. Nic nie wychodzi z maszyny bez wyraźnego wybrania zgody, a same ankiety wyłącza CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1. (Data usage)
Telemetria dzieli się na dwie kategorie z osobnymi wyłącznikami. Metryki obejmują opóźnienia, niezawodność i wzorce użycia, są wysyłane do Anthropic i do zewnętrznej infrastruktury logowania przez TLS i nigdy nie zawierają kodu, promptów ani ścieżek plików; wyłącza je DISABLE_TELEMETRY=1. Raporty o błędach zawierają komunikaty i ślady stosu z wnętrza samego Claude Code, wysyłane do zewnętrznej usługi śledzenia błędów przez TLS, przy czym znane wzorce sekretów, ścieżek plików, adresów e-mail i innych danych osobowych są redagowane przed opuszczeniem maszyny; wyłącza je DISABLE_ERROR_REPORTING=1. Cały ruch nieistotny naraz wyłącza CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. (Data usage)
Jedno zachowanie warto znać osobno, bo działa niezależnie od dostawcy modelu. Przed pobraniem adresu URL narzędzie WebFetch wysyła żądaną nazwę hosta do api.anthropic.com, żeby sprawdzić ją na liście blokad utrzymywanej przez Anthropic. Wysyłana jest wyłącznie nazwa hosta, nie pełny adres, ścieżka ani zawartość strony; host, który przeszedł kontrolę, jest buforowany na pięć minut. Kontrola działa niezależnie od używanego dostawcy modelu i nie podlega zmiennej CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. Gdy sieć blokuje api.anthropic.com, żądania WebFetch zawodzą, dopóki domena nie zostanie dopuszczona albo dopóki nie ustawi się skipWebFetchPreflight: true. (Data usage)
Wysłanie zgłoszenia poleceniem /feedback przesyła do Anthropic kopię historii rozmowy razem z kodem; polecenia /bug i /share idą tą samą drogą, a transkrypty udostępnione tą ścieżką są przechowywane przez pięć lat. Przed wysłaniem można wybrać, ile historii dołączyć: domyślnie tylko bieżącą sesję albo także inne sesje z tego projektu z ostatnich 24 godzin lub 7 dni. Wyłącznik to DISABLE_FEEDBACK_COMMAND=1. (Data usage)
Ochrona przed wstrzyknięciem promptu
Wstrzyknięcie promptu to technika, w której napastnik próbuje nadpisać albo zmanipulować instrukcje asystenta, wstawiając złośliwy tekst. Claude Code ma na to kilka zabezpieczeń: system uprawnień wymagający jawnego zatwierdzenia operacji wrażliwych w trybie ręcznym, analizę uwzględniającą pełny kontekst żądania, sanityzację danych wejściowych oraz zatwierdzanie poleceń sieciowych - polecenia pobierające treść z sieci, takie jak curl i wget, nie są domyślnie zatwierdzane automatycznie i w trybie ręcznym wywołują monit jak każde inne polecenie Bash spoza zestawu tylko do odczytu. Całkowitą blokadę daje dodanie ich do permissions.deny. (Security)
Do tego dochodzą: zatwierdzanie żądań sieciowych dla większości narzędzi je wykonujących, izolowane okna kontekstu dla pobierania stron, weryfikacja zaufania przy pierwszym uruchomieniu w danej bazie kodu i przy nowych serwerach MCP, wykrywanie wstrzyknięcia poleceń wymagające ręcznego zatwierdzenia podejrzanych poleceń bash nawet wcześniej dopuszczonych, oraz dopasowywanie fail-closed, w którym niedopasowane polecenia domyślnie wymagają zatwierdzenia. (Security)
Dwa zastrzeżenia z dokumentacji są istotne. Weryfikacja zaufania jest wyłączona przy uruchomieniu nieinteraktywnym z flagą -p. Uruchomienie Claude Code bezpośrednio w katalogu domowym powoduje, że akceptacja zaufania obowiązuje tylko w bieżącej sesji i nie jest zapisywana na dysk, więc monit wraca przy każdym starcie; nie ma ustawienia, które by to utrwaliło - trzeba uruchamiać program z podkatalogu projektu. (Security)
Praktyki zalecane przy pracy z niezaufaną treścią: przeglądać proponowane polecenia przed zatwierdzeniem, unikać przekazywania niezaufanej treści bezpośrednio do Claude, weryfikować proponowane zmiany plików krytycznych, używać maszyn wirtualnych do uruchamiania skryptów i wywołań narzędzi, zwłaszcza przy kontakcie z zewnętrznymi usługami webowymi, oraz zgłaszać podejrzane zachowania przez /feedback. Producent dodaje przy tym ostrzeżenie, że choć te zabezpieczenia znacząco redukują ryzyko, żaden system nie jest całkowicie odporny na wszystkie ataki. (Security)
Osobna kwestia to serwery MCP. Anthropic zachęca do pisania własnych serwerów albo korzystania z serwerów dostawców, którym się ufa, i zaznacza, że przegląda konektory pod kątem kryteriów listowania przed dodaniem ich do katalogu, ale nie audytuje bezpieczeństwa ani nie zarządza żadnym serwerem MCP. (Security)
Błędy i sposoby ich rozwiązania
command not found: claude albo 'claude' is not recognized. Instalacja się powiodła, ale katalog instalacyjny nie jest w PATH. Instalator umieszcza plik w ~/.local/bin/claude na macOS i Linuksie oraz %USERPROFILE%\.local\bin\claude.exe na Windows. (Troubleshoot installation and login) Warto przy tym wiedzieć, że rozszerzenie do VS Code nie umieszcza claude w tej lokalizacji - dołącza prywatną kopię CLI wewnątrz katalogu rozszerzenia na potrzeby własnego panelu czatu i nie dodaje jej do PATH. Przy zainstalowanym wyłącznie rozszerzeniu plik ~/.local/bin/claude nie będzie istniał. (Troubleshoot installation and login)
Problemy z pobieraniem instalatora. Instalator pobiera pliki z downloads.claude.ai. Sprawdzenie łączności na macOS i Linuksie to curl -sI https://downloads.claude.ai/claude-code-releases/latest, a w PowerShellu to samo wywołane jawnie jako curl.exe, bo PowerShell aliasuje curl do Invoke-WebRequest, które odrzuca flagi -sI. Serwer został osiągnięty, gdy pierwsza linia pokazuje status 200. Kod 403 zwykle oznacza zaporę lub filtr sieciowy blokujący hosta albo niedostępność Claude Code w danym regionie, a 5xx zwykle przejściowy problem usługi. (Troubleshoot installation and login) Przy pracy za firmowym proxy trzeba przed instalacją ustawić HTTPS_PROXY i HTTP_PROXY na adres proxy. (Troubleshoot installation and login)
Instalacja przerywana komunikatem Killed na Linuksie albo kodem wyjścia 137. Rozwiązaniem jest zwolnienie pamięci albo dodanie przestrzeni wymiany. (Troubleshoot installation and login)
cannot execute binary file: Exec format error w WSL. To WSL1 i znana regresja binarki natywnej: nagłówki programu zmieniły się w sposób, którego loader WSL1 nie obsługuje. Najczystsza naprawa to konwersja dystrybucji do WSL2 z PowerShella:
wsl --set-version <NazwaDystrybucji> 2
(Troubleshoot installation and login)
Błędy npm w WSL. Gdy npm zgłasza niezgodność platformy przy instalacji, WSL prawdopodobnie używa windowsowego npm - najpierw npm config set os linux, potem npm install -g @anthropic-ai/claude-code --force, bez sudo. Gdy claude kończy się komunikatem exec: node: not found, środowisko WSL najprawdopodobniej korzysta z windowsowej instalacji Node.js; potwierdzają to which npm i which node - ścieżki zaczynające się od /mnt/c/ to binarki Windows, linuksowe zaczynają się od /usr/. Naprawa polega na instalacji Node przez menedżer pakietów dystrybucji albo przez nvm. (Troubleshoot installation and login) Producent odradza przy tym wyłączanie importowania PATH z Windows przez appendWindowsPath = false, bo psuje to możliwość wywoływania programów Windows z WSL. (Troubleshoot installation and login)
Error: claude native binary not installed po instalacji przez npm. Pakiet pobiera binarkę natywną jako opcjonalną zależność platformową, a następnie uruchamia skrypt postinstall kopiujący ją na miejsce jako polecenie claude; do tego czasu claude jest skryptem zastępczym. Pominięcie pobrania albo kroku postinstall - na przykład przez --ignore-scripts czy część konfiguracji pnpm - zostawia ten skrypt na miejscu. (Troubleshoot installation and login)
Cask 'claude-code' is unavailable. Rozwiązaniem jest aktualizacja Homebrew. (Troubleshoot installation and login)
Claude nie stosuje się do CLAUDE.md. Treść pliku dostarczana jest jako wiadomość użytkownika po prompcie systemowym, a nie jako część promptu systemowego - Claude ją czyta i próbuje się do niej stosować, ale nie ma gwarancji ścisłej zgodności, zwłaszcza przy instrukcjach mglistych lub sprzecznych. Diagnostyka: /context i lista pod Memory files, żeby sprawdzić, czy plik się w ogóle wczytał; sprawdzenie, czy leży w lokalizacji ładowanej dla tej sesji; uszczegółowienie instrukcji; poszukanie sprzecznych wpisów w różnych plikach CLAUDE.md. Gdy coś musi wykonać się w konkretnym momencie, na przykład przed każdym commitem, właściwym mechanizmem jest hak, a nie wpis w pamięci. (How Claude remembers your project)
Instrukcje znikają po /compact. CLAUDE.md z katalogu głównego projektu przeżywa kompaktowanie - Claude odczytuje go ponownie z dysku i wstrzykuje do sesji. Zagnieżdżone pliki z podkatalogów i reguły z frontmatterem paths: ładują się ponownie, gdy Claude czyta pliki, których dotyczą. Zniknięcie instrukcji oznacza więc zwykle, że była podana wyłącznie w rozmowie. (How Claude remembers your project)
Panel /sandbox pokazuje tylko zakładkę Dependencies. Brakuje wymaganego pakietu; po instalacji bubblewrap i socat trzeba zrestartować Claude Code, bo sprawdzenie zależności wykonuje się przy starcie. (Configure the sandboxed Bash tool)
Sandboxing requires WSL2. Dystrybucja działa na WSL1; wersję sprawdza wsl -l -v z PowerShella. Rozwiązaniem jest przejście na WSL2 albo praca bez sandboksu. Na WSL2 obowiązuje przy tym osobne ograniczenie: sandboksowane polecenia nie mogą uruchamiać binarek Windows, takich jak cmd.exe, powershell.exe czy cokolwiek spod /mnt/c/, bo WSL przekazuje je hostowi Windows przez gniazdo uniksowe, które sandbox blokuje. Polecenie, które musi wywołać binarkę Windows, trzeba dodać do excludedCommands. (Configure the sandboxed Bash tool)
claude update albo claude doctor zawiesza się. Dokumentacja wskazuje na katalog znajdujący się w ścieżce konfiguracji powłoki jako przyczynę i przenoszenie go jako rozwiązanie. (Troubleshoot installation and login)
Nieudane logowanie mimo aktywnej subskrypcji. Najczęstsza przyczyna to ustawiona zmienna ANTHROPIC_API_KEY należąca do wyłączonej lub wygasłej organizacji, która wygrywa pierwszeństwo z poświadczeniami subskrypcji. Naprawa: unset ANTHROPIC_API_KEY i sprawdzenie /status. (Authentication)
Deinstalacja i sprzątanie
Sposób usunięcia zależy od metody instalacji. Gdy po deinstalacji claude nadal się uruchamia, prawdopodobnie istnieje druga instalacja albo pozostały alias powłoki po starszym instalatorze. (Advanced setup)
Instalacja natywna, macOS, Linux i WSL:
rm -f ~/.local/bin/claude
rm -rf ~/.local/share/claude
Instalacja natywna, Windows PowerShell:
Remove-Item -Path "$env:USERPROFILE\.local\bin\claude.exe" -Force
Remove-Item -Path "$env:USERPROFILE\.local\share\claude" -Recurse -Force
Homebrew: brew uninstall --cask claude-code albo brew uninstall --cask claude-code@latest, zależnie od zainstalowanego caska. WinGet: winget uninstall Anthropic.ClaudeCode. npm: npm uninstall -g @anthropic-ai/claude-code. (Advanced setup)
Przy apt trzeba usunąć też konfigurację repozytorium:
sudo apt remove claude-code
sudo rm /etc/apt/sources.list.d/claude-code.list /etc/apt/keyrings/claude-code.asc
Analogicznie przy dnf usuwa się /etc/yum.repos.d/claude-code.repo, a przy apk wpis repozytorium z /etc/apk/repositories oraz plik /etc/apk/keys/claude-code.rsa.pub. (Advanced setup)
Pliki konfiguracyjne to osobny krok i osobna decyzja - ich usunięcie kasuje wszystkie ustawienia, dozwolone narzędzia, konfiguracje serwerów MCP i historię sesji. (Advanced setup) Kolejność ma tu znaczenie: rozszerzenie VS Code, wtyczka JetBrains i aplikacja desktopowa również zapisują do ~/.claude/, więc jeżeli któreś z nich zostaje zainstalowane, katalog zostanie odtworzony przy następnym uruchomieniu. Pełne usunięcie wymaga wcześniejszej deinstalacji tych komponentów. (Advanced setup)
macOS, Linux i WSL:
rm -rf ~/.claude
rm ~/.claude.json
rm -rf .claude
rm -f .mcp.json
Windows PowerShell:
Remove-Item -Path "$env:USERPROFILE\.claude" -Recurse -Force
Remove-Item -Path "$env:USERPROFILE\.claude.json" -Force
Remove-Item -Path ".claude" -Recurse -Force
Remove-Item -Path ".mcp.json" -Recurse -Force
Dwa ostatnie polecenia w każdym bloku dotyczą ustawień projektowych i uruchamia się je z katalogu projektu. (Advanced setup)
Kilka zasad na koniec
Producent formułuje jedną zasadę wprost i warto ją zapamiętać: Claude Code ma tylko te uprawnienia, które zostały mu przyznane, a odpowiedzialność za przegląd proponowanego kodu i poleceń pod kątem bezpieczeństwa przed zatwierdzeniem leży po stronie użytkownika. (Security)
Do tego kilka praktyk z dokumentacji bezpieczeństwa dla pracy z wrażliwym kodem: przeglądać wszystkie proponowane zmiany przed zatwierdzeniem, używać ustawień uprawnień specyficznych dla projektu w repozytoriach wrażliwych, rozważyć kontenery deweloperskie dla dodatkowej izolacji i regularnie audytować własne ustawienia uprawnień przez /permissions. (Security)
I jedna uwaga o rozmowie z narzędziem: dokumentacja zaleca traktowanie Claude jak pomocnego współpracownika - opisanie tego, co ma zostać osiągnięte, zamiast wydawania rozkazów krok po kroku. (Quickstart) To działa dobrze pod jednym warunkiem: że efekt jest potem sprawdzany tak samo starannie jak cudzy pull request.
