← Blog
AI21 min czytania

Claude Code — agentowe narzędzie do kodowania w terminalu

Claude Code to agentowy asystent kodowania działający w terminalu, ale nie jest projektem open source: repozytorium anthropics/claude-code nie zawiera kodu narzędzia, a LICENSE.md odsyła do komercyjnych warunków Anthropic. Pokazujemy, co realnie konfiguruje się w repozytorium projektu — CLAUDE.md, reguły ścieżkowe, skille, subagentów, hooki i serwery MCP — jak wpiąć to w CI i ile to kosztuje.

Claude Code to agentowe narzędzie do kodowania, które chodzi w terminalu: czyta repozytorium, uruchamia polecenia, edytuje pliki i obsługuje gita, sterowane poleceniami po polsku albo po angielsku. Repozytorium anthropics/claude-code zebrało ponad 141 tysięcy gwiazdek i 22 tysiące forków, ostatni commit jest z 13 sierpnia 2026, a changelog opisuje wydanie 2.1.232. Projekt ma się dobrze i rozwija się w tempie kilku wydań tygodniowo.

Jest jednak rzecz, którą trzeba postawić na początku, bo zmienia sposób czytania całej reszty: w tym repozytorium nie ma kodu źródłowego narzędzia.

Repozytorium bez kodu, czyli co tu naprawdę jest otwarte

Na najwyższym poziomie repozytorium znajdziesz README.md, CHANGELOG.md, LICENSE.md, SECURITY.md, katalogi examples/, plugins/, scripts/, .devcontainer/ oraz .claude/. Nie ma katalogu ze źródłami CLI. Sam plik licencyjny mieści się w dwóch linijkach: informacja o prawach autorskich Anthropic PBC z klauzulą „all rights reserved” i odesłanie do Commercial Terms of Service. GitHub nie wykrywa tu żadnej licencji z listy OSI, bo jej nie ma.

Repozytorium pełni więc trzy funkcje naraz:

  • publiczny tracker błędów — w chwili pisania ponad 16 tysięcy otwartych zgłoszeń, co jest dobrą wiadomością (widać, na co ludzie się natykają) i złą naraz (kolejka jest długa),
  • changelog i dokumentacja — wydania opisane wersja po wersji, łącznie z informacją, od której wersji działa dana opcja; przy narzędziu wydawanym tak często to najważniejszy plik w repozytorium,
  • marketplace wtyczek — katalog plugins/ jest źródłem, z którego instaluje się oficjalne wtyczki, także w pipeline CI.

Otwarte na normalnych licencjach są za to rzeczy wokół narzędzia: akcja claude-code-action do GitHub Actions, pakiety Agent SDK dla TypeScriptu i Pythona, wtyczki oraz sam protokół Model Context Protocol, na którym stoją integracje. Konfiguracja, którą piszesz wokół Claude Code — reguły, skille, subagenci, hooki, definicje serwerów MCP — to zwykłe pliki w Twoim repozytorium i należą do Ciebie.

Jeśli w Twojej organizacji „open source” znaczy „możemy to postawić u siebie i przeczytać kod”, Claude Code tego kryterium nie spełnia i żadna konfiguracja tego nie zmieni. Spełnia natomiast inne, praktyczne kryterium: całe zachowanie narzędzia w projekcie opisują wersjonowane pliki tekstowe, a nie ustawienia klikane w cudzym panelu.

Konsekwencje przy komercyjnym użyciu są konkretne. Nie postawisz tego na własnym serwerze bez dostępu do internetu. Nie zaudytujesz implementacji, jeśli klient tego wymaga — możesz się oprzeć wyłącznie na certyfikatach SOC 2 Type 2 i ISO 27001 dostawcy. Jesteś zależny od jego cennika i limitów. I najważniejsze: treść plików, które Claude czyta, wychodzi poza Twoją infrastrukturę — do API Anthropic albo, jeśli tak skonfigurujesz, do Amazon Bedrock, Google Cloud lub Microsoft Foundry na Twoim koncie chmurowym. Do tego wracamy w sekcji o bezpieczeństwie.

Instalacja

Na macOS i Linuksie:

curl -fsSL https://claude.ai/install.sh | bash

Albo z Homebrew, co jest wygodniejsze przy aktualizacjach:

brew install --cask claude-code

Na Windowsie:

irm https://claude.ai/install.ps1 | iex
winget install Anthropic.ClaudeCode

Instalacja przez npm (npm install -g @anthropic-ai/claude-code) jest oznaczona jako przestarzała — jeśli masz ją z rozpędu z 2025 roku, warto się przesiąść, bo aktualizacje idą teraz kanałem natywnym.

Po instalacji wchodzisz do katalogu projektu i uruchamiasz claude. Trzy polecenia warto znać od pierwszego dnia: claude --version (changelog przypina funkcje do numerów wydań, więc numer wersji jest realną informacją), /status (pokazuje, które źródła ustawień się wczytały) i /doctor (sprawdza konfigurację i wypisuje, co zostało odrzucone jako niepoprawne).

Uwierzytelnienie idzie albo przez subskrypcję (Pro, Max, Team, Enterprise — logowanie poleceniem /login), albo przez klucz API ze zmiennej ANTHROPIC_API_KEY, albo przez poświadczenia dostawcy chmury. To rozróżnienie wraca później przy kosztach i przy CI.

Model uprawnień, czyli pierwsza rzecz do ustawienia

Domyślnie narzędzie ma uprawnienia tylko do odczytu. Wbudowana lista bezpiecznych poleceń (ls, cat, git status i podobne) chodzi bez pytania, wszystko inne wymaga zgody. Obowiązuje też granica katalogu roboczego: zapis możliwy jest tylko w katalogu, w którym uruchomiono sesję, i w jego podkatalogach. Odczyt poza tą granicą wymaga potwierdzenia.

Klikanie zgody przy każdym vendor/bin/sail artisan test szybko męczy, więc reguły zapisuje się w .claude/settings.json w repozytorium. Plik jest wspólny dla zespołu i wchodzi do gita:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(vendor/bin/sail artisan test *)",
      "Bash(vendor/bin/pint --dirty *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git status *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./storage/framework/sessions/**)",
      "Bash(vendor/bin/sail artisan migrate:fresh *)",
      "Bash(curl *)"
    ]
  }
}

Spacja przed gwiazdką w regule ma znaczenie. Bash(git diff *) dopasuje każde polecenie zaczynające się od git diff, ale Bash(git diff*) dopasuje także git diff-index. To najczęstsza pomyłka w tych plikach.

Ustawienia układają się w hierarchię, od najsilniejszej: zarządzane przez organizację (managed-settings.json rozkładane przez MDM albo Ansible), flaga --settings, plik lokalny .claude/settings.local.json (poza gitem), plik projektowy .claude/settings.json, na końcu użytkownika ~/.claude/settings.json. Wartości z poziomu zarządzanego są nienadpisywalne — tam trafiają zakazy, które mają obowiązywać niezależnie od tego, co ktoś sobie ustawi lokalnie.

Osobno działają tryby uprawnień. plan (Shift+Tab w sesji) pozwala tylko czytać i przedstawić plan przed dotknięciem czegokolwiek. acceptEdits automatycznie zatwierdza edycje plików i garść poleceń typu mkdir czy mv. dontAsk odrzuca wszystko, czego nie ma w regułach allow — to tryb do zamkniętych przebiegów w CI. Do izolacji poleceń powłoki od reszty systemu plików i sieci służy /sandbox.

CLAUDE.md — kontekst, którego nie chcesz tłumaczyć od nowa

Każda sesja startuje z pustym kontekstem. CLAUDE.md to plik, który wczytuje się na starcie każdej rozmowy i przenosi między sesjami to, czego inaczej trzeba by powtarzać: polecenia budowania, konwencje, układ katalogów, zasady „zawsze rób X”.

Pliki wczytują się w kolejności od najogólniejszego do najbardziej szczegółowego: poziom zarządzany przez organizację, ~/.claude/CLAUDE.md (Twoje preferencje we wszystkich projektach), ./CLAUDE.md lub ./.claude/CLAUDE.md (projekt, wspólny przez gita), ./CLAUDE.local.md (prywatne, do .gitignore). Wszystkie się sklejają, żaden nie nadpisuje innego. Pliki w podkatalogach wczytują się dopiero wtedy, gdy Claude sięgnie po plik z tego podkatalogu.

/init generuje pierwszą wersję na podstawie analizy repozytorium. Dalej dopisujesz to, czego narzędzie samo się nie domyśli. Dobrą regułą jest: dopisz, gdy ten sam błąd powtórzył się drugi raz, albo gdy po raz drugi wpisujesz w czacie tę samą poprawkę.

W projekcie na Sailu treść wygląda mniej więcej tak:

# Projekt

Laravel 12 + Inertia + React, uruchamiany przez Laravel Sail.

## Polecenia

- Testy: `vendor/bin/sail artisan test --compact`
- Formatowanie: `vendor/bin/sail bin pint --dirty`
- Assety: `vendor/bin/sail npm run build`
- Nigdy nie uruchamiaj `php artisan` bezpośrednio na hoście — środowisko żyje w kontenerach.

## Konwencje

- Nowe pliki twórz przez `make:`, nie ręcznie.
- Każda zmiana ma test; testy funkcjonalne przed jednostkowymi.
- Formy bezosobowe w komunikatach walidacji.

Dwie rzeczy o rozmiarze. Zalecany limit to 200 linii na plik — dłuższe zjadają kontekst i, paradoksalnie, są gorzej respektowane. Składnia @ścieżka/do/pliku importuje inny plik, ale nie oszczędza kontekstu: import wczytuje się w całości przy starcie razem z resztą.

I rzecz najważniejsza, często odkrywana boleśnie: CLAUDE.md to kontekst, nie mechanizm egzekwowania. Jest wstrzykiwany jako wiadomość i model stara się go trzymać, ale gwarancji nie ma — zwłaszcza przy instrukcjach ogólnikowych albo sprzecznych. Jeśli coś musi się wykonać w konkretnym momencie, to jest zadanie dla hooka, nie dla akapitu w markdownie.

Reguły ścieżkowe zamiast jednego wielkiego pliku

Przy większym projekcie instrukcje rozbija się na katalog .claude/rules/. Reguła z sekcją paths we frontmatterze wczytuje się dopiero wtedy, gdy Claude tknie pasujący plik:

---
paths:
  - "app/Filament/**/*.php"
---

# Filament

- Komponenty formularzy: `Filament\Forms\Components\`
- Komponenty układu (Grid, Section, Tabs): `Filament\Schemas\Components\`
- Akcje zawsze z `Filament\Actions\`, nigdy z podprzestrzeni Tables ani Forms.
- `Grid`, `Section` i `Repeater` nie zajmują domyślnie pełnej szerokości.

Reguły bez pola paths wczytują się zawsze, z tym samym priorytetem co .claude/CLAUDE.md. Katalog obsługuje symlinki, więc wspólny zestaw reguł da się trzymać w jednym miejscu i podlinkować do kilku repozytoriów.

Równolegle działa pamięć automatyczna: narzędzie samo zapisuje wnioski z sesji do ~/.claude/projects/<projekt>/memory/, z plikiem MEMORY.md jako indeksem. Wczytywane jest z niego pierwsze 200 linii albo 25 KB. Ta pamięć jest lokalna dla maszyny i nie wchodzi do repozytorium — czyli tego, czego ma się nauczyć cały zespół, nie zostawiaj tam, tylko przenieś do CLAUDE.md albo do reguł. Wyłącza się ustawieniem autoMemoryEnabled na false.

Skille — procedury, które wczytują się na żądanie

Kiedy fragment CLAUDE.md przestaje być faktem, a staje się procedurą („jak wypuszczamy wydanie”, „jak dopisujemy wpis na bloga”), jego miejscem jest skill. Skill to katalog z plikiem SKILL.md. Treść wczytuje się dopiero w momencie użycia, więc długi materiał referencyjny nie kosztuje nic, dopóki nie jest potrzebny.

  • ~/.claude/skills/<nazwa>/SKILL.md — osobisty, we wszystkich projektach,
  • .claude/skills/<nazwa>/SKILL.md — projektowy, wchodzi do repozytorium,
  • katalog skills/ we wtyczce — wtedy wywołuje się go z prefiksem wtyczki.

Skill uruchamia się wpisaniem /nazwa albo zostaje wybrany samodzielnie, gdy pasuje do zadania. Przykład procedury, którą chcemy odpalać wyłącznie ręcznie:

---
name: wydanie
description: Przygotowanie wydania na produkcję
disable-model-invocation: true
allowed-tools: Bash(vendor/bin/sail artisan test *) Bash(git tag *)
---

1. Uruchom pełny zestaw testów.
2. Zbuduj assety.
3. Zaktualizuj CHANGELOG.md o zmiany od ostatniego tagu.
4. Nadaj tag i wypchnij go.

disable-model-invocation: true odbiera modelowi możliwość samodzielnego uruchomienia procedury — przydatne wszędzie tam, gdzie skill ma skutki uboczne. allowed-tools zatwierdza z góry dokładnie te polecenia, których skill potrzebuje, dzięki czemu procedura nie przerywa się na pytaniu o zgodę. Wcześniejsze komendy własne z .claude/commands/*.md nadal działają: to ta sama funkcja w prostszej formie.

Subagenci — praca w osobnym kontekście

Zadanie w rodzaju „przejrzyj cały katalog testów i powiedz, czego brakuje” zaśmieca główną rozmowę treścią plików, do której nikt już nie wróci. Subagent robi to w oddzielnym oknie kontekstu i zwraca tylko podsumowanie. Definicje leżą w .claude/agents/ (projekt, do repozytorium) albo ~/.claude/agents/ (Twoje, wszędzie):

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

Treść pliku staje się promptem systemowym subagenta — dostaje on tylko to plus podstawowe informacje o środowisku, bez głównego promptu narzędzia. Pole tools ogranicza dostępne narzędzia (tu: sam odczyt, żadnego zapisu), a disallowedTools działa odwrotnie — dziedziczy wszystko poza wymienionymi. Oba pola przyjmują wzorce serwerów MCP, więc disallowedTools: mcp__github odcina cały serwer GitHuba, zostawiając resztę.

Pole model to konkretna dźwignia kosztowa: do zadań mechanicznych ustaw haiku i zapłać ułamek tego, co kosztowałby model najmocniejszy.

Hooki — jedyna warstwa, która naprawdę egzekwuje

Hook to polecenie powłoki (albo wywołanie HTTP, narzędzia MCP czy promptu) uruchamiane w ustalonym punkcie cyklu życia sesji, niezależnie od tego, co model postanowi. Zdarzeń jest kilkadziesiąt; w praktyce liczą się PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop i PreCompact.

Najbardziej oczywiste zastosowanie w projekcie PHP: formatowanie po każdej edycji, żeby styl kodu nie był przedmiotem negocjacji z modelem.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "vendor/bin/pint --dirty --format agent",
            "statusMessage": "Formatuję PHP..."
          }
        ]
      }
    ]
  }
}

Drugie zastosowanie to twarda blokada. Hook PreToolUse może odrzucić wywołanie narzędzia — albo wyjściem z kodem 2, albo zwracając na standardowe wyjście decyzję w JSON-ie:

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command')

if echo "$COMMAND" | grep -qE 'migrate:fresh|db:wipe'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Kasowanie bazy zablokowane regułą projektu"
    }
  }'
else
  exit 0
fi

Kod wyjścia 2 blokuje operację nawet wtedy, gdy zwrócony JSON mówi „allow”. Domyślny limit czasu to 600 sekund dla hooków typu command, 30 dla UserPromptSubmit. W poleceniach można używać podstawień ${CLAUDE_PROJECT_DIR} i ${CLAUDE_PLUGIN_ROOT}.

Trzecie zastosowanie jest czysto ekonomiczne: hook może przefiltrować dane, zanim trafią do kontekstu. Zamiast wczytywać dziesięciotysięczny log, hook zwraca same linie z ERROR — z dziesiątek tysięcy tokenów robi się kilkaset.

Hooki są kodem wykonywanym automatycznie z Twoimi uprawnieniami. Hook w .claude/settings.json cudzego repozytorium jest wektorem ataku dokładnie tak samo jak skrypt postinstall w package.json. Organizacja może to przyciąć ustawieniem allowManagedHooksOnly, a pojedyncza sesja flagą --settings '{"disableAllHooks": true}'.

MCP — podpięcie własnych narzędzi

Model Context Protocol to otwarty standard integracji, po którym Claude Code sięga do systemów zewnętrznych: bazy danych, trackera zadań, monitoringu, Figmy. Serwery deklaruje się w pliku .mcp.json w repozytorium (wtedy widzi je cały zespół) albo w konfiguracji użytkownika. Definicje narzędzi są domyślnie odroczone — do kontekstu wchodzą same nazwy, pełne schematy dopiero przy pierwszym użyciu, co przy kilku serwerach naraz robi wymierną różnicę.

W projektach laravelowych najbardziej opłacalnym serwerem jest Laravel Boost: daje odpytywanie bazy w trybie tylko do odczytu, podgląd schematu przed pisaniem migracji, listę poleceń Artisana, odczyt logów przeglądarki i — najcenniejsze — wyszukiwanie w dokumentacji dopasowanej do wersji pakietów faktycznie zainstalowanych w projekcie. To eliminuje najczęstszy błąd modelu przy Laravelu: podpowiadanie API z innej wersji frameworka.

Dwie uwagi praktyczne. Po pierwsze, tam gdzie istnieje zwykłe CLI (gh, aws, gcloud), jest ono tańsze kontekstowo niż serwer MCP, bo nie dokłada żadnej listy narzędzi. Po drugie, serwer MCP to obcy kod z dostępem do Twoich danych — Anthropic sprawdza konektory w katalogu pod kątem kryteriów publikacji, ale nie audytuje ich bezpieczeństwa i nimi nie zarządza. Listy allowedMcpServers i deniedMcpServers pozwalają to domknąć na poziomie organizacji.

Tryb nieinteraktywny i CI

Flaga -p zamienia narzędzie w zwykły program uniksowy: czyta standardowe wejście, pisze na standardowe wyjście, zwraca kod wyjścia 0 przy powodzeniu i niezerowy przy błędzie.

cat build-error.txt | claude -p 'wyjaśnij zwięźle przyczynę tego błędu budowania' > wynik.txt

Do skryptów i CI dochodzi flaga --bare, która pomija wykrywanie hooków, skilli, wtyczek, serwerów MCP, pamięci automatycznej i CLAUDE.md. Przebieg jest wtedy powtarzalny na każdej maszynie — hook z katalogu domowego kolegi z zespołu nie wykona się, bo w tym trybie w ogóle nie jest czytany. W trybie --bare narzędzie nie sięga też po poświadczenia OAuth ani po pęk kluczy, więc trzeba ustawić ANTHROPIC_API_KEY.

To istotne również z innego powodu. Sesja z -p nie pokazuje okna zaufania do katalogu, bo nie ma komu go pokazać — a to znaczy, że bez --bare uruchomi hooki z .claude/settings.json repozytorium, którego nigdy wcześniej nie otwierałeś, i połączy serwery z jego .mcp.json. Przy przebiegach na cudzym kodzie --bare przestaje być optymalizacją, a staje się wymogiem.

Wyjście strukturalne zdejmuje potrzebę parsowania tekstu:

claude -p "Wypisz nazwy funkcji z app/Services/Invoice.php" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"functions":{"type":"array","items":{"type":"string"}}},"required":["functions"]}' \
  | jq '.structured_output'

Przy --output-format json odpowiedź zawiera pole total_cost_usd i rozbicie kosztu na modele, więc skrypt może pilnować budżetu bez zaglądania do panelu. To szacunek liczony lokalnie po cenach standardowych — przy rabatach kontraktowych rozjedzie się z fakturą.

Najprostsze sensowne zastosowanie w projekcie: własny linter, który sprawdza to, czego statyczna analiza nie złapie.

git diff master | claude --bare -p "Jesteś recenzentem. Wypisz wyłącznie miejsca, w których ta zmiana psuje kompatybilność API. Nic więcej." --output-format json | jq -r '.result'

Podanie diffa na wejściu jest tu celowe: dzięki temu nie trzeba przyznawać uprawnień do Bash. Jeśli przerwiesz przebieg sygnałem SIGTERM, narzędzie przerywa turę, zabija drzewo procesów uruchomionych poleceń, odpala hooki SessionEnd i kończy się kodem 143 — nadaje się więc do zarządzania przez zwykły supervisor.

GitHub Actions

Ta sama mechanika w pipelinie GitHuba. Minimalny workflow reagujący na wzmiankę @claude w komentarzu:

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Uprawnienie id-token: write jest wymagane do uwierzytelnienia aplikacji GitHuba, a actions: read pozwala czytać wyniki CI z pull requesta. Zamiast klucza API można podać token subskrypcji wygenerowany poleceniem claude setup-token i przekazany jako claude_code_oauth_token — z zastrzeżeniem, że taki token jest przypisany do konta konkretnej osoby, więc do współdzielenia w organizacji lepiej nadaje się klucz API albo federacja tożsamości przez OIDC.

Przed uruchomieniem akcja sprawdza dwie rzeczy: czy osoba wywołująca ma uprawnienie zapisu do repozytorium i czy nie jest botem. Drugi warunek zapobiega pętlom, w których dwa boty wywołują się nawzajem w nieskończoność. Podanie parametru prompt przełącza akcję w tryb automatyczny — uruchamia się wtedy na dowolnym zdarzeniu, także z crona, bez czekania na wzmiankę.

Warto od razu ustawić --max-turns w claude_args, limit czasu na poziomie zadania i kontrolę współbieżności. Bez tego jedno źle sformułowane zgłoszenie potrafi zjeść minuty runnerów i tokeny w tempie, którego nikt nie zauważy do końca miesiąca.

Bezpieczeństwo i dane

Wstrzyknięcie promptu to podstawowe ryzyko każdego narzędzia agentowego: treść, którą model przeczyta — komentarz w kodzie, opis zgłoszenia, strona WWW — może próbować podać mu instrukcje. Zabezpieczenia są warstwowe: system uprawnień z zatwierdzaniem operacji wrażliwych, wykrywanie podejrzanych poleceń powłoki (wymagają ręcznej zgody nawet gdy pasują do reguły allow), brak automatycznej zgody na polecenia sieciowe w rodzaju curl i wget, osobne okno kontekstu dla pobierania treści z sieci oraz okno zaufania przy pierwszym uruchomieniu w nowym repozytorium i przy nowym serwerze MCP. Dopasowanie reguł działa w trybie fail-closed: czego nie da się jednoznacznie dopasować, wymaga potwierdzenia.

Zestaw rzeczy do zrobienia w projekcie komercyjnym:

  • wpisz Read(./.env) i Read(./.env.*) do permissions.deny, zanim ktokolwiek uruchomi narzędzie w repozytorium z produkcyjnymi poświadczeniami,
  • reguły wspólne dla organizacji rozłóż jako ustawienia zarządzane, żeby nie dało się ich nadpisać lokalnie,
  • przy pracy na nieznanym kodzie używaj kontenera deweloperskiego z katalogu .devcontainer/ albo maszyny wirtualnej,
  • włącz /sandbox tam, gdzie polecenia mają chodzić bez nadzoru,
  • audytuj konfigurację poleceniem /permissions i zdarzeniem ConfigChange, jeśli chcesz wiedzieć, kto zmienia ustawienia w trakcie sesji,
  • przy wdrożeniu zespołowym wypuść metryki OpenTelemetry — to jedyny sposób na spójne dane o użyciu niezależnie od dostawcy.

Kwestia danych osobowych i tajemnicy przedsiębiorstwa jest osobnym tematem i przy pracy dla klienta trzeba ją rozstrzygnąć przed pierwszym uruchomieniem, nie po. Treść plików wychodzi na zewnątrz. Dla użytkowników Team, Enterprise i API obowiązują Commercial Terms of Service z ograniczonym okresem przechowywania danych; użytkownicy planów konsumenckich mają własne ustawienia prywatności. Jeśli umowa z klientem wymaga, żeby dane nie opuszczały wskazanego regionu, jedyną sensowną drogą jest kierowanie ruchu przez Amazon Bedrock, Google Cloud albo Microsoft Foundry na koncie chmurowym z odpowiednią rezydencją — z tym, że wtedy dashboardy analityczne Anthropic przestają widzieć to użycie i zostaje Ci OpenTelemetry albo bramka LLM.

Podatności zgłasza się przez program HackerOne, nie publicznie. Sam projekt trzyma się tu przyzwoitych standardów: poświadczenia lądują w pęku kluczy macOS, gdy jest dostępny, a na Linuksie i Windowsie są chronione uprawnieniami plików.

Ile to kosztuje

Dokumentacja podaje konkretne liczby z wdrożeń korporacyjnych: średnio około 13 dolarów na programistę za dzień aktywnej pracy i 150–250 dolarów miesięcznie, przy czym 90% użytkowników mieści się poniżej 30 dolarów dziennie. To rozliczenie tokenowe (API i dostawcy chmury); przy subskrypcji Pro, Max, Team lub Enterprise płacisz za miejsce, a zużycie liczy się względem limitu w oknie pięciogodzinnym i tygodniowym.

Rzeczy, które faktycznie obniżają rachunek:

  • /clear przy przejściu do niezwiązanego zadania — cała historia rozmowy jedzie z każdym żądaniem, więc jednolinijkowe pytanie w sesji otwartej od rana kosztuje jak cała ta sesja,
  • dobór modelu do zadania: mocniejszy do decyzji architektonicznych, słabszy do reszty, haiku dla prostych subagentów,
  • obniżenie poziomu rozumowania przez /effort tam, gdzie głębokie myślenie nic nie wnosi — tokeny rozumowania rozliczane są jak tokeny wyjściowe,
  • tryb planowania przed większą zmianą, bo najdroższa jest praca wykonana w złym kierunku,
  • wyłączenie nieużywanych serwerów MCP (/mcp) i sprawdzanie zajętości kontekstu przez /context,
  • przeniesienie specjalistycznych instrukcji z CLAUDE.md do skilli, które wczytują się na żądanie.

Osobna pułapka: zespoły agentów, uruchamiane zmienną CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, zużywają w trybie planowania mniej więcej siedmiokrotnie więcej tokenów niż zwykła sesja, bo każdy członek zespołu prowadzi własne okno kontekstu. Bywa to warte swojej ceny, ale nie jest to opcja, którą włącza się „na wszelki wypadek”.

Gdzie się sprawdza, a gdzie nie

Najlepiej wypada tam, gdzie zadanie jest opisywalne i weryfikowalne: migracje między wersjami frameworka, dopisywanie testów do istniejącego kodu, wyszukiwanie wzorca w dużym repozytorium, przepisywanie warstwy z jednego API na drugie, uzupełnianie tłumaczeń, poprawki po code review. Wspólny mianownik: wynik da się sprawdzić bez czytania każdej linijki — bo test przechodzi albo nie.

Gorzej wypada tam, gdzie nie ma czym zweryfikować efektu ani co przeczytać: projektowanie od zera bez wytycznych, decyzje o kompromisach biznesowych, zmiany w kodzie bez testów i bez typów. Wtedy przegląd wyniku kosztuje tyle, co napisanie go samodzielnie.

Konfiguracja opisana wyżej nie jest ozdobnikiem — to główna różnica między narzędziem, które pomaga, a takim, które generuje pracę. Repozytorium z sensownym CLAUDE.md, regułami ścieżkowymi, hookiem formatującym i listą uprawnień zachowuje się zupełnie inaczej niż to samo repozytorium bez nich.

Podsumowanie

Co daje Claude Code w codziennej pracy zespołu:

  • agenta, który czyta repozytorium, uruchamia polecenia i edytuje pliki, sterowanego z terminala, IDE albo z pull requesta,
  • konfigurację w plikach wersjonowanych razem z kodem: CLAUDE.md, reguły ścieżkowe, skille, subagenci, hooki, definicje serwerów MCP,
  • system uprawnień z domyślnym trybem tylko do odczytu, granicą katalogu roboczego, listami allow i deny oraz nienadpisywalnymi ustawieniami zarządzanymi,
  • hooki jako jedyną warstwę faktycznie egzekwującą zasady, niezależną od tego, co model postanowi,
  • tryb nieinteraktywny z wyjściem JSON i walidacją schematem, nadający się do skryptów, hooków gita i pipeline'ów,
  • gotową akcję do GitHub Actions z kontrolą uprawnień wywołującego,
  • integracje po otwartym protokole MCP, w tym Laravel Boost z dokumentacją dopasowaną do wersji pakietów w projekcie,
  • przewidywalne rozliczenie: subskrypcja z limitem na miejsce albo rozliczenie tokenowe z rzędem wielkości 150–250 dolarów na programistę miesięcznie.

Licencja: Claude Code nie jest oprogramowaniem open source. Repozytorium anthropics/claude-code zawiera dokumentację, changelog, przykłady i wtyczki, ale nie kod narzędzia, a plik LICENSE.md odsyła do Commercial Terms of Service Anthropic — bez licencji z listy OSI. Przy komercyjnym użyciu oznacza to trzy rzeczy: nie postawisz tego u siebie, nie zaudytujesz implementacji i musisz świadomie rozstrzygnąć, dokąd wędruje kod klienta. Otwarte są za to elementy wokół: akcja claude-code-action, pakiety Agent SDK, wtyczki i protokół MCP. Cała konfiguracja, którą napiszesz — reguły, skille, subagenci, hooki — zostaje w Twoim repozytorium i jest przenośna niezależnie od tego, jak potoczy się los samego narzędzia.

← Wszystkie artykuły