Terminal Claude Code: 7 usprawnień workflow dla zaawansowanych użytkowników

Claude Code w wersji „vanilla” jest użyteczny od razu po instalacji. Instalujesz, podajesz polecenia i buduje to, czego Pan/Pani potrzebuje. Dla większości to wystarczające środowisko do vibe-codingu — i działa.

Wersja Claude Code, z której korzysta ktoś z dopracowanym terminalem, to już inne narzędzie. Uprzednio zatwierdzono tam zaufane komendy bash, więc Claude niemal nigdy nie prosi o zgodęns. Plik CLAUDE.md leży w katalogu głównym projektu, więc Claude zna konwencje od pierwszej sekundy sesji. A gdy sesja zaczyna się gubić, komendą pierwszego wyboru nie jest restart.

Ten artykuł w siedmiu krokach wypełnia lukę między tymi dwoma podejściami do Claude Code. Żadne z nich nie zajmie więcej niż dziesięć minut konfiguracji, a każde zwróci się w ciągu tygodnia.

Jeśli Claude Code jest dla Pana/Pani nowy, lepszym punktem wyjścia będzie nasz główny przewodnik po Claude Code. Poniżej zakładamy, że potrafi Pan/Pani już formułować polecenia i akceptować wywołania narzędzi.

1. Przestań ponownie zatwierdzać te same komendy

Domyślnie każde wywołanie narzędzia prosi o akceptację. W porządku za pierwszym razem, gdy uruchamia się pytest. Irytujące za trzecim. Za dziesiątym wciska się Enter bez czytania monitu. To najgorsze z obu światów: wyrobił Pan/Pani w sobie ignorowanie kontroli bezpieczeństwa, a mimo to spowalnia to pracę.

Oczywiście istnieje tryb „niebezpiecznego pomijania uprawnień” lub „auto mode”. Omawialiśmy kompromisy w moim poradniku o Auto Mode i kanałach w Claude Code.

Definiowanie uprawnień w pliku settings.json

Rozwiązaniem jest plik .claude/settings.json w katalogu głównym projektu, z blokiem permissions, który z góry zatwierdza znane wzorce i blokuje te niepożądane:

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

Reguły są oceniane w stałej kolejności: najpierw deny, potem ask, na końcu allow. Pierwsze dopasowanie wygrywa, więc deny zawsze przebije późniejsze allow.

Opanowanie zakresu i wildcardów

Trzy rzeczy potrafią zaskoczyć przy pierwszym pisaniu takich reguł.

1. Pierwsza to zakres. Plik projektu .claude/settings.json nadpisuje globalny ~/.claude/settings.json, więc jeśli globalnie zezwolono na Bash(rm *), a projekt to blokuje, wygrywa projekt. To sensowna domyślna zasada, ale zaskakuje osoby, które oczekują „lepkości” globalnych zezwoleń.

2. Druga to wildcardy w komendach sieciowych. Bash(curl http://github.com/ *) wygląda na restrykcyjną, ale nie łapie https://, opcji przed URL, redirectów ani ekspansji zmiennych powłoki. Zalecany przez dokumentację wzorzec to pełny zakaz Bash(curl *). Następnie należy używać narzędzia WebFetch z WebFetch(domain:github.com) dla domen, które faktycznie mają być dozwolone.

3. Trzecia to biały znak. Bash(ls *) pasuje do ls -la, ale nie do lsof. Bash(ls*) pasuje do obu. Spacja przed gwiazdką robi tu różnicę — warto świadomie wybierać, który wariant się pisze.

Kilka skrótów klawiszowych uzupełnia uprawnienia w tym samym duchu „przestań walczyć z terminalem” — warto je poznać od pierwszego dnia:

• Shift+Tab przełącza tryby uprawnień (domyślny, auto-accept, plan)

• Esc+Esc otwiera selektor cofania (więcej w sekcji #3)

• Ctrl+R wyszukuje wstecz w historii poleceń, tak jak w bash i zsh

• Ctrl+U usuwa od kursora do początku linii

• Shift+Enter dodaje nową linię w polu polecenia

Większość z nich działa w terminalach bez dodatkowej konfiguracji. Jeśli nie, proszę uruchomić komendę /terminal-setup, aby zainstalować wszystko.

2. Spraw, by Claude Code pamiętał Pana/Pani projekt

Każda sesja zaczyna się z pustym oknem kontekstu.

Domyślnie Claude nie pamięta, że używa Pan/Pani uv zamiast pip. Nie pamięta, że testy są w tests/, a nie w test/. A konwencje API, które wczoraj były tłumaczone przez dziesięć tur, też przepadają. Lekarstwem jest plik CLAUDE.md w katalogu głównym projektu. Proszę uruchamiać Claude Code z tego katalogu (lub podkatalogu), a plik zostanie automatycznie załadowany do kontekstu przed pierwszym poleceniem.

Najłatwciej zacząć od /init. Proszę uruchomić wewnątrz projektu. Claude przeczyta kod i napisze szkic CLAUDE.md z komendami budowania, instrukcjami testów i konwencjami, które da się wywnioskować. Potem warto go edytować, bo /init daje działającą bazę, a nie gotowy dokument.

Claude szuka kontekstu w trzech miejscach, nakładanych na siebie:

Projektowy CLAUDE.md w ./CLAUDE.md jest dostarczany razem z repozytorium. Jest taki sam dla wszystkich współautorów, więc proszę umieszczać tu fakty specyficzne dla projektu:

• Menedżer pakietów i wersja języka
• Komenda testów i lokalizacja testów
• Układ katalogów i mniej oczywiste konwencje
• Wszystko, co nowa osoba w zespole musi wiedzieć pierwszego dnia

Użytkowy CLAUDE.md w ~/.claude/CLAUDE.md podąża za Panem/Panią między projektami na tej maszynie. Tu wpisujemy preferencje osobiste: styl kodowania, formatowanie docstringów, języki pierwszego wyboru. Nie należy umieszczać tu faktów o projekcie — przenikną do każdego innego repozytorium.

Auto‑pamięć to trzecia warstwa, zapisywana przez Claude. Gdy w trakcie sesji coś koryguje Pan/Pani ("u nas używamy snake_case, nie camelCase"), trafia to do ~/.claude/projects/<project>/memory/MEMORY.md. Pierwsze 200 linii lub 25 KB tego pliku ładuje się na starcie każdej rozmowy w tym projekcie. Zawartość można podejrzeć komendą /memory; pozwala ona też włączać/wyłączać auto‑pamięć.

Jedna wskazówka dotycząca objętości: każdy CLAUDE.md warto utrzymać poniżej 200 linii. Powyżej tej granicy plik zaczyna zjadać zauważalny kontekst w każdej turze, a Claude mniej niezawodnie trzyma się długich plików. Jeśli rozrasta się za bardzo, proszę go podzielić do .claude/rules/ ze scope’ami ścieżek. Głębsze omówienie tego, co faktycznie powinno znaleźć się w CLAUDE.md, znajduje się w moim przewodniku writing the best CLAUDE.md tutorial.

3. Przestań restartować sesje, gdy coś idzie źle

Odruch, gdy sesja zaczyna się rozjeżdżać, to /clear i zaczynamy od nowa. Często to zły odruch. Restart wyrzuca ścieżki plików, które Claude już edytował, śledzony niezdany test albo założenia, które nakreślono na starcie. Nowa sesja musi się tego nauczyć od zera — kosztuje to żetony i czas.

Najpierw warto rozpoznać objawy. Taki rozkład kontekstu ma kilka oczywistych sygnałów:

• Claude ponownie pyta o ścieżkę do pliku, który edytował pięć tur temu
• Powtarza sugestię, którą już Pan/Pani odrzucił(a)
• Gubi informację o aktualnej gałęzi
• W tej samej sesji poprawiano go więcej niż dwa razy w tej samej kwestii

Gdy się to pojawia, są cztery opcje — i nie są zamienne:

Kompaktowanie sesji

 /compact nie jest tak złe, jak twierdzi część użytkowników.

Projektowy CLAUDE.md przetrwa ten proces. Po kompresji Claude ponownie czyta plik z dysku i wstrzykuje jego treść, więc konwencje nie giną. Można też dodać wskazówki dotyczące fokusu, np. /compact keep the auth refactor decisions, drop the failed test runs. To różnica między użytecznym a generycznym podsumowaniem.

Korzystanie z opcji „cofnij” w Claude Code

Selektor cofania pod Esc+Esc to funkcja, o której większość nie wie. Otwiera listę wszystkich punktów kontrolnych poleceń w sesji. Po wyborze jednego oferuje trzy opcje: przywrócić tylko rozmowę, tylko kod albo oba.

„Restore code and conversation” to zwykle to, czego trzeba. Pół godziny złych tur znika bez odpalania gita. To najbliższy „cofnij” dla całej sesji w Claude Code.

Gdy przestanie Pan/Pani restartować, kolejnym wyzwaniem staje się odnalezienie sesji.

Nadawanie nazw i ponowne otwieranie sesji

claude -n <name> (lub --name) uruchamia nazwaną sesję, a nazwa pojawia się w /resume i tytule terminala. Gdy w tym samym repo dzieją się trzy rzeczy (gałąź eksperymentalna, refaktor, debug), nazwy pozwalają je odróżnić. /rename zmienia nazwę w trakcie sesji, jeśli zakres prac się zmienia.

Wskazówka: Proszę użyć /color, aby dodatkowo rozróżnić sesje uruchomione w tym samym oknie terminala.

Ponowne otwieranie sesji odbywa się jedną z dwóch flag. claude --continue (lub -c) ładuje najświeższą rozmowę w bieżącym katalogu. Użyteczne, gdy właśnie Pan/Pani tu pracował(a) i chce kontynuować.

claude --resume otwiera interaktywny selektor, a claude --resume <name-or-id> skacze prosto do konkretnej sesji. Proszę traktować sesje jak gałęzie gita: różne strumienie pracy zasługują na własne.

4. Planuj trudne rzeczy, oszczędzaj na łatwych

Największym kosztem w dopracowanym środowisku nie jest edytor ani skróty. To dopasowanie mocy obliczeniowej do trudności zadania. Trzy narzędzia wspólnie w tym pomagają: tryb planu, /effort i /model.

Korzystanie z trybu planu w Claude Code

Tryb planu każe Claude najpierw przemyśleć podejście, zanim dotknie plików. Tworzy plan, Pan/Pani go czyta, akceptuje lub zgłasza uwagi — i dopiero wtedy następuje wykonanie.

Sztuczka, której używam, by plany były solidne, to prosty prompt, z którego często korzystam:

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

Uruchomi to wiele subagentów do przeglądu planu z różnych perspektyw i zasugerowania poprawek. To dobra praktyka przy planie dłuższym niż 500 linii.

Koszt jest taki, że planowanie plus red‑teaming dodają dwie tury, zanim powstanie jakikolwiek kod, więc przy czymkolwiek mniejszym niż istotna funkcja lub naprawa błędu to przesada.

Do trybu planu można wejść na pięć sposobów:

Forma wbudowana w wiersz poleceń (

) to ta, którą najłatwiej przeoczyć. Ustawia tryb i zadanie jednym skrótem zamiast dwóch. Dogłębny opis workflow „najpierw przegląd, potem wykonanie” znajdzie Pan/Pani w moim poradniku trybu planu Claude Code.

Ustawianie odpowiedniego poziomu effort

Effort to kolejny element. Kontroluje, ile pogłębionego rozumowania Claude wykonuje w każdej turze. Wyższy effort oznacza głębsze wnioskowanie, więcej tokenów i wolniejszą odpowiedź.

/effort <level> i flaga CLI --effort <level> akceptują wszystkie pięć wartości. Low, medium, high i xhigh utrzymują się między sesjami. Max działa tylko w obrębie bieżącej sesji, bo znosi ograniczenie wydatku tokenów — trzeba go więc ustawiać świadomie. Właściwą domyślną opcją do codziennej pracy jest low lub medium. high i xhigh proszę rezerwować na naprawdę trudne problemy, a max — na momenty, gdy lepiej „spalić” tokeny, niż się pomylić.

Warto pamiętać kontrapunkt: model na low z dobrym kontekstem często przewyższa ten sam model na max z kiepskim kontekstem. Oczyszczenie polecenia zwykle daje większy zysk niż podbicie effort.

Wybór właściwego modelu

Wybór modelu to miejsce realnych oszczędności. /model przełącza model w trakcie sesji, a skrót Option+P (macOS) / Alt+P (Win/Linux) podmienia model bez czyszczenia wpisanego już tekstu. Warto znać aliasy:

• sonnet to domyślny model „daily driver”

• opus jest do najtrudniejszych problemów (alias best również wskazuje opus)

• haiku gdy liczy się szybkość

• sonnet[1m] i opus[1m] to warianty z kontekstem 1M

• opusplan uruchamia Opus w trybie planu, a Sonnet do wykonania

• default usuwa nadpisanie i wraca do zalecanego modelu

Jeśli domyślnie używa Pan/Pani Opus do wszystkiego, przełączenie na Sonnet przez większość dnia to największa dostępna obniżka wydatków. 

Opus jest właściwy, gdy utknęło się na czymś trudnym i potrzeba najinteligentniejszego modelu. Sonnet poradzi sobie z niemal całą resztą. Różnica kosztów jest na tyle duża, że „użyję Opus na wszelki wypadek” to najdroższy nawyk, jaki można zostawić na autopilocie.

5. Zautomatyzuj to, co robisz ręcznie

Gdy źródła tarcia znikną, kolejną warstwą jest praca, którą wciąż wykonuje się ręcznie.

Zadania cykliczne

Łatwiej je zautomatyzować, niż szukać wymówek. Dwie funkcje pokrywają większość przypadków: /loop do powtarzalnych sprawdzeń, które inaczej trzeba by doglądać, oraz hooki do gwarancji, których nie da się wymusić instrukcją w CLAUDE.md.

/loop ponownie uruchamia prompt lub komendę slash w cyklicznym harmonogramie. Składnia ma dwie postacie:

• /loop 5m <prompt> uruchamia prompt co 5 minut

• /loop <prompt> bez interwału oddaje dobór kadencji modelowi

Jednostki interwału to s, m, h i d; minimum to jedna minuta. Wymagana wersja Claude Code v2.1.72 lub nowsza.

Przykład: watcher testów — /loop 2m run the test suite and report failures. Zamiast pamiętać o testach po każdej zmianie (i zapominać połowę razy), Claude wyłapie złamany test przy kolejnym 2‑minutowym tyknięciu.

Ten sam wzorzec działa dla sprawdzania deployu stagingu (/loop 10m check if the staging deploy is green) lub tailowania logów podczas niestabilnego incydentu (/loop 1m tail the last 50 lines of app.log and flag errors).

Pętle żyją 7 dni.

Zadanie wywoła się po raz ostatni siódmego dnia i samo się usunie. Są powiązane z sesją, więc --continue lub --resume je przywróci po zamknięciu i ponownym otwarciu. Aby zatrzymać pętlę wcześniej, proszę nacisnąć Esc. Jeśli potrzeba harmonogramu, który przetrwa zamknięcie sesji (nocne sprawdzenie, tygodniowy przegląd), proszę użyć Routines przez /schedule.

Hooki

Hooki to druga połowa. Uruchamiają komendy powłoki w określonych momentach pracy Claude, konfigurowane w .claude/settings.json. 

Powód, by użyć hooka zamiast instrukcji w CLAUDE.md, jest jeden: CLAUDE.md ma charakter doradczy, a hooki gwarantują wykonanie. Klasyczny przypadek to zasada „po każdej edycji odpal linter”, którą Claude omija co jakiś czas. Hook domyka tę lukę.

Sześć zdarzeń pokrywa większość przypadków:

M

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

Jedna pułapka warta zapamiętania: tylko kod wyjścia 2 naprawdę blokuje Claude. Wyjście 1 jest traktowane jako nieblokujący błąd i Claude idzie dalej, mimo że 1 to zwyczajowy kod porażki w Uniksie. Jeśli hook ma egzekwować zasadę, proszę zwrócić 2.

Hooków nie trzeba też pisać ręcznie.

Wystarczy poprosić Claude o „napisz hook, który uruchamia ruff po każdej edycji pliku”, a przygotuje szkic JSON. Komenda /hooks pokazuje wszystkie aktywne konfiguracje hooków, więc nie trzeba grepować ustawień, gdy coś nieoczekiwanie się uruchamia. Pełny katalog zdarzeń i schematy JSON stdin/stdout znajdzie Pan/Pani w moim poradniku hooków Claude Code.

6. Miej oko na koszty

Pętle, długie sesje i domyślne użycie Opus spalają tokeny. Trzy komendy czynią wydatki na tyle widocznymi, by można je było kontrolować — celem jest na nie zerknąć, a nie konfigurować je godzinami.

/usage pokazuje poziom planu, sumy sesji, rozbicia kosztów per model i paski postępu dla okien limitów 5‑godzinnego i tygodniowego.

/context wizualizuje bieżące okno kontekstu jako kolorową siatkę, z ostrzeżeniami o pojemności i wskazówkami, które narzędzia lub pliki zajmują miejsce. Warto użyć, gdy sesja „ciąży” i trzeba wybrać między /compact a /clear.

/statusline konfiguruje stały pasek na dole terminala. Może pokazywać model, procent kontekstu, okna limitów i wszystko inne, co da się odczytać z JSON sesji. To funkcja, która najbardziej zmienia zachowania — bo wrzuca liczby kosztowe w pole widzenia podczas pracy.

Można uruchomić /statusline i opisać zwykłym językiem, co ma się wyświetlać — Claude wygeneruje skrypt i zaktualizuje ustawienia. Alternatywnie można napisać własny skrypt powłoki i wskazać go w ~/.claude/settings.json:

{
  "statusLine": {
	"type": "command",
	"command": "~/.claude/statusline.sh"
  }
}

Do śledzenia długoterminowego między sesjami narzędzie społecznościowe npx ccusage agreguje zużycie tokenów w czasie. To narzędzie firm trzecich, nie od Anthropic, ale wypełnia lukę między sesyjnym /usage a miesięcznym rachunkiem.

7. Trzy dodatkowe funkcje, o których warto wiedzieć

Sześć powyższych ulepszeń to moje codzienne podstawy. Poniższe trzy to realne funkcje, z których korzystam rzadziej, ale dobrze wiedzieć, że istnieją — na dzień, gdy będą potrzebne.

Naciśnij i mów dzięki /voice

/voice włącza dyktowanie „push‑to‑talk”. Proszę przytrzymać Space, mówić, puścić — a transkrypcja trafi do pola polecenia. Wymagana wersja v2.1.69 lub nowsza, obsługiwanych jest dwadzieścia języków.

Głos zwykle wygrywa z pisaniem, gdy spaceruje się i myśli na głos, albo dyktuje intencję na starcie zadania, zanim słowa się wyklarują. Gorzej sprawdza się przy zmianach liniowych — „zmień linię 47 na...” łatwiej napisać.

Pobieranie sesji z chmury z /teleport

/teleport (alias /tp) przenosi sesję chmurową do lokalnego terminala. Załóżmy, że rozpoczęto długie zadanie w aplikacji webowej lub iOS, a teraz wraca Pan/Pani do laptopa. Proszę uruchomić claude --teleport, aby otworzyć selektor i wylądować w tej sesji w terminalu, z właściwą gałęzią już przełączoną.

Kilka warunków musi się zgadzać:

• Czysty stan gita
• Właściwe repo
• To samo konto claude.ai, które uruchomiło sesję w chmurze
• Gałąź wypchnięta na zdalne

Proszę nie mylić --teleport z --resume. Druga opcja wznawia tylko lokalne sesje z historii tej maszyny. Dokładny opis znajdzie Pan/Pani w naszym poradniku zdalnej kontroli Claude Code.

Pytania poboczne z /btw

/btw służy do szybkiego pytania bez zrywania flow.

Wyobraźmy sobie, że Claude jest w trakcie zadania. Ruszyła długa edycja lub wywołanie narzędzia, a Pan/Pani nagle potrzebuje regexu do IP albo przypomnienia, która flaga robi X. 

Wystarczy wpisać /btw <question>, a odpowiedź pojawi się w zamykalnym overlayu. Trwające zadanie idzie dalej, odpowiedź nie trafia do historii rozmowy, więc nie trzeba uruchamiać nowej sesji dla jednorazowego sprawdzenia i nie zaśmieca się bieżącej.

Zakończenie

Najszybsza droga do odwrotu od wszystkiego z tego artykułu to próba wdrożenia wszystkiego jednego dnia. Proszę wybrać dwa lub trzy punkty, wyrobić nawyk, a resztę dodać później, gdy pierwsze staną się automatyczne.

Trzy na start — każde dla innej części dnia, by sobie nie wchodziły w drogę:

• Zwięzły projektowy CLAUDE.md plus dwie–trzy reguły wildcard w .claude/settings.json dla komend bash, które co sesję ponownie zatwierdza Pan/Pani. To poranny nawyk — czuć go dopiero, gdy przestaną się pojawiać przerwy.

• Wybór między /compact a /clear oraz selektor cofania Esc+Esc. To nawyk środka dnia — sygnałem jest moment, gdy Claude ponownie prosi o ścieżkę, którą znał godzinę temu.

• Jedna pętla /loop dla powtarzalnego sprawdzenia, które już teraz zabiera czas. To nawyk w tle — gdy już działa, sam się spłaca.

Jeśli różnice między Sonnet, Opus i Haiku nadal są niejasne, nasz kurs Introduction to Claude Models przeprowadza przez to, kiedy który model pasuje. Dzięki temu wywołania /effort i /model stają się dużo prostsze.