Mody Claude Code: jak zmienić wygląd i zachowanie asystenta AI

Mody to nie kolejna kosmetyczna aktualizacja. To system pluginów oparty na handlerach zdarzeń, który pozwala pisać własne funkcje w JavaScript lub TypeScript i wpinać je bezpośrednio w potok narzędzia. Możesz zmienić wygląd interfejsu, przechwycić moment wysłania promptu albo podmienić wbudowane elementy widoku. Brzmi jak coś zarezerwowanego dla autorów rozszerzeń do IDE, ale próg wejścia jest tu wyraźnie niższy.

Warto od razu zaznaczyć jedną granicę: dokumentacja wskazuje wprost, że modyfikacje mogą obejmować dużą część interfejsu, ale nie obejmują promptu uprawnień. To celowe ograniczenie bezpieczeństwa, które pozostaje poza zasięgiem nawet najbardziej rozbudowanego pluginu. Wszystko inne jest otwarte na zmiany.

Mody są dostępne zarówno w wersji CLI, jak i w desktopowej aplikacji, co oznacza, że nie musisz wybierać między środowiskami pracy. Jeśli codziennie przełączasz się między terminalem a aplikacją okienkową, ten sam plugin zadziała w obu miejscach. Przykładowe mody Anthropic publikuje w repozytorium `claude-code-playground`, w katalogu `claude-code/mods` – to dobry punkt startowy przed pisaniem własnych rozwiązań od zera.

Czym właściwie są mody i jak działają?

Najprostszy sposób myślenia o modach: to małe programy, które „słuchają” tego, co robi narzędzie, i reagują na wybrane momenty. Każdy mod rejestruje się na konkretne zdarzenia – wywołanie narzędzia (tool call), wysłanie zapytania przez użytkownika (prompt submission) albo renderowanie elementu interfejsu (UI rendering). Kiedy dane zdarzenie wystąpi, handler w modzie dostaje kontrolę i może zmienić zachowanie aplikacji.

Mody działają jako pluginy oparte na handlerach zdarzeń w JavaScript lub TypeScript i mogą przechwytywać zdarzenia interfejsu oraz narzędzi, co czyni je rozwiązaniem o szerokim zastosowaniu: od prostej zmiany kolorystyki po budowanie własnego dashboardu agenta z podglądem kosztów sesji i stanu context window.

Instalacja odbywa się przez komendę `/plugin`. Po zainstalowaniu mod jest aktywny w ramach sesji lub globalnie, zależnie od konfiguracji. Anthropic rozróżnia session mods – działające tylko w bieżącej sesji – od modów instalowanych w katalogu Claude, które są dostępne przy każdym uruchomieniu narzędzia. To rozróżnienie ma praktyczne znaczenie: jeśli testujesz coś eksperymentalnego, session mod pozwala uniknąć przypadkowego wpływu na inne projekty.

Moduł hooks to warstwa, przez którą mody komunikują się z aplikacją. Każdy handler dostaje kontekst zdarzenia i może go odczytać, zmodyfikować albo całkowicie zastąpić. Przykładowo, mod reagujący na UI rendering może wstrzyknąć własny komponent do interfejsu – tak działa choćby podgląd Markdown w czasie rzeczywistym, jeden z popularnych przypadków użycia widocznych w publicznych repozytoriach na GitHubie.

Jedno zastrzeżenie, które Anthropic podkreśla wyraźnie w dokumentacji: mody nie są sandboxowane. Mają taki sam dostęp do maszyny jak samo narzędzie, co w praktyce oznacza pełny dostęp do systemu plików i sieci. Instalowanie moda z nieznanego źródła to ryzyko porównywalne z uruchamianiem nieznanych skryptów – przed instalacją zawsze warto przejrzeć kod.

Społeczność zdążyła już zbudować kilka interesujących przykładów. Charlie Hills opublikował pakiet dwunastu modów, który obejmuje m.in. Mission Control (widok wszystkich uruchomionych agentów), Safe Delete z funkcją cofania usunięcia, pixel-art office desks przypisane do konkretnych sesji oraz panel kosztów aktualizowany po każdym wywołaniu narzędzia. Ten ostatni pokazuje, jak daleko można posunąć personalizację środowiska pracy – i jednocześnie, jak bardzo mody mogą być użyteczne, a nie tylko estetyczne. Inne publicznie dostępne pluginy zarządzają pamięcią podręczną kontekstu albo wyświetlają prompt rail z historią poprzednich zapytań.

Odpowiedź na pytanie „czy mogę zrobić własny mod, który zmieni UI?” brzmi krótko: tak, i to bez szczególnie rozbudowanej wiedzy o architekturze narzędzia. Wystarczy znajomość JavaScript lub TypeScript i zrozumienie, na które zdarzenie chcesz zareagować. Anthropic celowo obniżył próg wejścia, udostępniając przykładowe mody do przerabiania – to model „bring your own mod”, gdzie startowym materiałem jest gotowy szablon, a nie pusta kartka.

Co mod może przechwycić, a czego nie zmienisz?

Zanim zaczniesz pisać własny plugin, warto wiedzieć, z jakim zestawem możliwości faktycznie pracujesz. Mody dają dostęp do czterech głównych warstw aplikacji, ale każda rządzi się własnymi zasadami.

Zdarzenia narzędzi (tool calls) pozwalają przechwycić każde wywołanie przez agenta, odczytać jego parametry i zmodyfikować zachowanie przed wykonaniem lub po nim. To otwiera możliwość budowania własnych warstw logowania, filtrowania akcji albo automatycznego zatwierdzania wybranych operacji. Wysyłanie zapytań (prompt submission) uruchamia handler w momencie, gdy użytkownik wysyła wiadomość – mod może odczytać treść, dołączyć dodatkowy kontekst albo zmienić sposób, w jaki zapytanie trafia do modelu. Renderowanie interfejsu (UI rendering) to warstwa odpowiedzialna za wygląd aplikacji: mod może wstrzyknąć własne komponenty, zmienić układ elementów albo dodać nowe widoki, takie jak dashboard z metrykami sesji. Wreszcie wbudowane funkcje – część domyślnych zachowań można podmienić własną implementacją, co pozwala np. zastąpić domyślny podgląd pliku własnym rendererem Markdown.

Granica zatrzymuje się na permission prompt. Tego elementu żaden mod nie zmieni – i jest to decyzja celowa, nie techniczna przypadłość.

Dlaczego to ograniczenie ma sens? Permission prompt to moment, w którym narzędzie pyta użytkownika o zgodę na wykonanie potencjalnie niebezpiecznej operacji, na przykład usunięcie pliku lub uruchomienie komendy systemowej. Gdyby mod mógł go podmienić, złośliwy plugin mógłby cicho zatwierdzać operacje bez wiedzy użytkownika. Zachowanie tej granicy to świadomy wybór projektowy, który chroni integralność całego systemu uprawnień.

Wersja 2.1.287, opublikowana na NPM 1 października 2026 roku, to pierwsza, która oficjalnie obsługuje mody – jeśli pracujesz na starszej wersji i twój mod nic nie robi, aktualizacja narzędzia jest pierwszym krokiem diagnostycznym, zanim zaczniesz szukać błędu w kodzie pluginu.

Mody wpisują się w szerszy ekosystem rozszerzeń. Pluginy mogą łączyć w sobie slash commands, subagenty, serwery MCP i właśnie hooks – mod to jeden z elementów tej układanki, nie oddzielny system. Jeśli budujesz bardziej rozbudowane środowisko pracy, możesz łączyć te warstwy w ramach jednego pluginu.

Jak napisać pierwszy mod?

Pisanie moda zaczyna się od jednego pliku. To nie jest figura retoryczna – minimalny plugin to dosłownie `package.json` i plik wejściowy eksportujący obiekt z kluczem `hooks`. Reszta zależy od tego, co chcesz osiągnąć.

W `package.json` deklarujesz nazwę paczki i punkt wejściowy, a w polu `claude` wskazujesz, że to plugin dla Claude Code. Sam plik modułu eksportuje obiekt zgodny z interfejsem `ClaudePlugin`. Minimalny przykład, który faktycznie działa, zajmuje około 20 linii kodu.

Zanim przejdziesz do pisania logiki, zainstaluj mod lokalnie poleceniem `claude plugin install ./twoj-folder`. Narzędzie załaduje plugin z dysku zamiast z rejestru NPM – to wygodne podczas developmentu, bo każda zmiana w pliku jest widoczna po restarcie sesji bez konieczności publikowania paczki. Debugowanie odbywa się przez standardowe `console.error` (nie `console.log` – to drugie trafia do stdout i może zakłócić renderowanie interfejsu).

Poniżej znajdziesz kolejne kroki, które prowadzą od pustego folderu do działającego moda:

1. Utwórz folder projektu i zainicjuj go przez `npm init -y`, a następnie dodaj do `package.json` sekcję `claude` z polem `”type”: „plugin”`;
2. Zainstaluj typy jako zależność deweloperską: `npm install –save-dev @anthropic/claude-code-types` – bez tego edytor nie podpowie ci dostępnych metod i interfejsów;
3. Napisz plik wejściowy eksportujący obiekt `ClaudePlugin` z co najmniej jednym handlerem w kluczu `hooks` – najprostszy punkt startowy to `onPromptSubmit`, który przyjmuje kontekst zapytania i może go przepuścić bez zmian;
4. Zainstaluj mod lokalnie poleceniem `claude plugin install ./nazwa-folderu` i uruchom nową sesję, żeby sprawdzić, czy plugin się ładuje – komunikat o błędzie pojawi się w stderr;
5. Dodaj logikę: jeśli chcesz przechwycić wywołania narzędzi, zaimplementuj handler `onToolCall`, który otrzymuje obiekt z nazwą narzędzia i jego parametrami; możesz tam uruchomić własny kod przed przekazaniem wywołania dalej lub całkowicie je zablokować;
6. Przetestuj zachowanie na kilku rzeczywistych zapytaniach, zanim opublikujesz plugin przez `npm publish` – szczególnie sprawdź ścieżki błędów, bo nieobsłużony wyjątek w handlerze może zawiesić całą sesję agenta.

Jeden konkretny przykład z życia: jeśli pracujesz w projekcie, gdzie każde zapytanie do agenta powinno zawierać numer ticketu z systemu zadań, możesz napisać handler `onPromptSubmit`, który odczytuje zmienną środowiskową `TICKET_ID` i dokłeja jej wartość na początku każdej wiadomości. Użytkownik nie musi o tym pamiętać – mod robi to automatycznie przy każdym wysłaniu.

Warto zwrócić uwagę na obsługę asynchroniczności. Handlery mogą być funkcjami `async`, co pozwala na wywołania do zewnętrznych API albo odczyt plików konfiguracyjnych w trakcie przetwarzania. Handler, który nie zwróci odpowiedzi w ciągu 30 sekund, zostanie przerwany z błędem timeout – dla operacji sieciowych zawsze ustawiaj własny limit czasu krótszy niż ten próg.

Mody w praktyce – przykłady zastosowań i ograniczenia

Najczęściej budowane pluginy rozwiązują konkretne problemy powtarzające się w codziennej pracy z agentem. Nie chodzi o eksperymenty – chodzi o automatyzację rzeczy, które bez pluginu wymagają ręcznej interwencji przy każdej sesji.

Jednym z popularniejszych zastosowań jest automatyczne ładowanie kontekstu projektu. Bez moda, za każdym razem gdy zaczynasz nową sesję, musisz ręcznie wklejać informacje o strukturze projektu, konwencjach nazewnictwa albo listę plików, których agent nie powinien modyfikować. Mod z handlerem `onSessionStart` może odczytać plik `.claude-context.md` z katalogu projektu i automatycznie wstrzyknąć jego zawartość jako część kontekstu systemowego. Czas konfiguracji sesji spada z kilku minut do zera.

Drugi obszar to warstwa audytu i logowania. W środowiskach, gdzie kod generowany przez AI musi przejść przez przegląd bezpieczeństwa, mod może zapisywać każde wywołanie narzędzia do pliku dziennika wraz z timestampem, nazwą narzędzia i jego parametrami. Taki log pozwala odtworzyć dokładnie, co agent zrobił podczas sesji – które pliki odczytał, jakie komendy uruchomił i w jakiej kolejności. To przydatne zarówno do audytu, jak i do debugowania, gdy sesja zakończyła się nieoczekiwanym wynikiem.

Trzecia kategoria to filtry i guardrails. Handler `onToolCall` może sprawdzać, czy agent próbuje wykonać operację na pliku spoza dozwolonego katalogu, i blokować takie wywołanie zanim trafi do wykonania. Podobnie można zbudować filtr, który wymaga potwierdzenia przed uruchomieniem komendy zawierającej `rm` lub `DROP TABLE`. To nie zastępuje permission prompt – działa jako dodatkowa warstwa logiki biznesowej nałożona na standardowy mechanizm uprawnień.

Ograniczenia są jednak realne. Mod nie ma dostępu do historii rozmowy w trybie do odczytu – może przechwycić zapytanie w momencie wysyłania, ale nie może przejrzeć wcześniejszych wiadomości z sesji. Nie może też modyfikować odpowiedzi modelu po jej wygenerowaniu; hooki działają przed przetwarzaniem i w jego trakcie, nie po nim.

Praktyczne ograniczenie, które pojawia się szybciej niż można by się spodziewać, dotyczy stanu między sesjami. Mod nie ma wbudowanego mechanizmu persystencji – jeśli chcesz przechowywać dane między uruchomieniami, musisz samodzielnie zapisywać je do pliku lub bazy danych i odczytywać przy starcie. To nie jest wada architektury, lecz świadoma decyzja: pluginy mają być bezstanowe domyślnie, a stan opcjonalny i jawny.

FAQ

Czym są mody Claude Code?

Mody to pluginy oparte na handlerach zdarzeń, które pozwalają modyfikować zachowanie i wygląd narzędzia bez ingerencji w jego kod. Każdy mod rejestruje się na wybrane zdarzenia – wysłanie zapytania, wywołanie narzędzia albo renderowanie interfejsu – i może zmieniać ich przebieg. Oficjalne wsparcie dla modów pojawiło się w wersji 2.1.287, opublikowanej 1 października 2026 roku.

Czy mody działają zarówno w CLI, jak i w aplikacji desktopowej?

Tak. Ten sam plugin działa w obu środowiskach bez konieczności wprowadzania zmian w kodzie. Jeśli codziennie przełączasz się między terminalem a aplikacją okienkową, nie musisz utrzymywać dwóch oddzielnych wersji moda.

Czy mody Claude Code są bezpieczne?

Mody nie są sandboxowane i mają taki sam dostęp do systemu jak samo narzędzie – oznacza to pełny dostęp do plików i sieci. Przed instalacją pluginu z zewnętrznego źródła zawsze warto przejrzeć jego kod. Jedynym elementem, którego żaden mod nie może zmienić, jest permission prompt – to celowe ograniczenie chroniące integralność systemu uprawnień.

Jak zainstalować mod lokalnie podczas developmentu?

Wystarczy użyć komendy `claude plugin install ./nazwa-folderu`. Narzędzie załaduje plugin bezpośrednio z dysku, co pozwala testować zmiany po każdym restarcie sesji bez konieczności publikowania paczki na NPM.

Czy mod może modyfikować odpowiedź modelu po jej wygenerowaniu?

Nie. Hooki działają przed przetwarzaniem i w jego trakcie, ale nie ma mechanizmu pozwalającego przechwycić gotową odpowiedź i ją zmienić. Jeśli chcesz wpłynąć na wynik, musisz działać na poziomie zapytania przed jego wysłaniem.