Jaki terminal wybrać do pracy z AI? Porównanie Ghostty, Kitty, iTerm2 i innych

Development Łukasz Ślusarski Łukasz Ślusarski 23 min czytania 629 wyświetleń
Jaki terminal wybrać do pracy z AI? Porównanie Ghostty, Kitty, iTerm2 i innych

Claude Code, Gemini CLI, Cursor – AI coding tools działają w
terminalu. Sprawdzamy który terminal jest najlepszy pod orchestrację
agentów, performance i codzienną pracę.


1. Wstęp – Dlaczego terminal ma znaczenie w erze AI

Przez lata terminal był narzędziem dla „tych hardkorowych” –
administratorów, backendowców, ludzi którzy wolą vim od
wszystkiego. Reszta świata żyła w IDE. Ten podział właśnie się
kończy.

Claude Code od Anthropic, Gemini CLI od Google, agentura Codex od OpenAI – najważniejsze AI coding tools 2025 i 2026 roku są terminal-first. Nie jako dodatek, nie jako opcja. Terminal to ich natywne środowisko. Claude Code w trybie Agent Teams orkiestruje kilku agentów AI jednocześnie, każdy w osobnym panelu terminala. Gemini CLI odpala się jedną komendą i pracuje w czystym shellu. Nawet Cursor, który zaczynał jako fork VS Code, w 2026 roku wypuścił wersję CLI.

To nie jest powrót do „czarnego ekranu z lat 80.” – to fundamentalna zmiana w tym, jak wygląda codzienna praca programisty. Trend „vibe coding”, który eksplodował po premierze Claude Code, polega na prowadzeniu konwersacji z agentem AI w terminalu, a nie na ręcznym pisaniu kodu w edytorze. Terminal stał się interfejsem do AI – i jak każdy interfejs, może być dobry albo zły.

Problem w tym, że domyślny Terminal.app na macOS czy cmd.exe na Windowsie nie były projektowane z myślą o tych workflow’ach. Brakuje im wydajności renderowania przy dużych outputach (a agenty AI generują dużo tekstu), wsparcia dla multipleksacji paneli, poprawnej obsługi sekwencji klawiszy typu Shift+Enter czy stabilności przy wielogodzinnych sesjach z kontekstem 200K tokenów.

Dlatego przetestowaliśmy sześć terminali pod kątem jednego pytania: który najlepiej sprawdza się w codziennej pracy z AI coding tools? Ghostty, Kitty, Alacritty, WezTerm, iTerm2 i Warp – każdy z nich ma swoją filozofię i swoich zwolenników. Sprawdziliśmy je pod względem wydajności, zużycia pamięci, kompatybilności z tmux, wsparcia dla Claude Code Agent Teams i prostoty konfiguracji. Wyniki są jednoznaczne – i nie wszystkie popularne terminale wypadają dobrze.


Potrzebujesz pomocy z tym tematem?

Pomagam firmom wdrażać nowoczesne rozwiązania. Umów bezpłatną 30-minutową rozmowę.

Umów bezpłatną rozmowę →
Potrzebujesz pomocy z tym tematem?

2. Czego wymagają AI coding tools od terminala

Zanim przejdziemy do porównania, trzeba zrozumieć czego właściwie potrzebują narzędzia, z którymi pracujemy. Wymagania Claude Code, Gemini CLI i Cursora różnią się istotnie – i to te różnice decydują o tym, czy dany terminal sprawdzi się w praktyce.

Claude Code

Claude Code to najbardziej wymagający tool z całej trójki i to on najsilniej determinuje wybór terminala. Działa w dwóch trybach, które mają fundamentalnie różne wymagania.

Tryb in-process (standardowy) działa w zasadzie wszędzie. Uruchamiasz claude w dowolnym terminalu, dostajesz interaktywną sesję, przełączasz się między wiadomościami za pomocą Shift+Up / Shift+Down. To wystarczy do solo pracy z jednym agentem. Jedyne wymaganie: terminal musi poprawnie obsługiwać Shift+Enter do wpisywania wieloliniowych promptów – co brzmi banalnie, ale nie każdy terminal radzi sobie z tym domyślnie.

Tryb split-pane (Agent Teams) – i tu zaczynają się schody. Claude Code w trybie orchestracji uruchamia kilku agentów jednocześnie, każdego w osobnym panelu terminala. To wymaga multipleksacji, a Anthropic oficjalnie wspiera tylko dwa rozwiązania:

  • tmux – działa z każdym terminalem, który poprawnie obsługuje tmux
  • iTerm2 – natywna integracja, bez potrzeby tmux

Co istotne, nie działają z Agent Teams: wbudowany terminal VS Code, Windows Terminal (natywnie) ani Ghostty bez tmux. Jeśli planujesz używać Agent Teams – a to jest feature, który zmienia produktywność – potrzebujesz albo tmux, albo iTerm2.

Dodatkowy kontekst: Claude Code operuje na kontekście do 200K tokenów (w becie nawet 1M). Przy tak dużych sesjach terminal musi stabilnie renderować długie outputy bez lagów i artefaktów. GPU-accelerated rendering nie jest luksusem – to konieczność.

Gemini CLI

Google poszedł w drugą stronę – Gemini CLI jest celowo lekkie. Wymagania to Node.js 18+, 512 MB RAM i około 100 MB na dysku. Całe ciężkie obliczenia dzieją się w chmurze, więc lokalny terminal jest głównie interfejsem do wyświetlania tekstu.

W praktyce oznacza to, że Gemini CLI działa dobrze w dosłownie każdym terminalu. Nie ma specjalnych wymagań co do split-pane, nie potrzebuje tmux, nie wymaga obsługi niestandardowych sekwencji klawiszy. Jeśli używasz wyłącznie Gemini CLI, wybór terminala jest kwestią komfortu, nie kompatybilności.

Cursor CLI

Cursor to przede wszystkim IDE – fork VS Code z wbudowanym AI. Terminal jest w nim wtórny, a większość interakcji z AI odbywa się przez interfejs graficzny edytora. Wersja CLI, która pojawiła się w 2026 roku, pozwala na uruchamianie Cursora z linii poleceń, ale to wciąż wrapper nad GUI.

Dla naszego porównania Cursor CLI jest najmniej istotny – działa w każdym terminalu, nie stawia specjalnych wymagań, a i tak większość użytkowników Cursora pracuje w jego natywnym oknie.

Tabela wymagań

Wymaganie Claude Code Gemini CLI Cursor CLI
Multipleksacja (Agent Teams) tmux lub iTerm2 nie wymaga nie wymaga
Shift+Enter (multiline) wymagane opcjonalne nie dotyczy
Stabilne renderowanie (duży output) krytyczne (200K+ tokenów) umiarkowane niskie
Min. RAM terminala im mniej, tym lepiej bez znaczenia bez znaczenia
GPU rendering zalecane opcjonalne opcjonalne
Wsparcie tmux kluczowe dla Agent Teams opcjonalne opcjonalne

Wniosek jest prosty: to Claude Code dyktuje wymagania. Jeśli używasz go na poważnie – szczególnie z Agent Teams – wybór terminala nie jest kwestią estetyki. To decyzja, która wpływa na to, czy w ogóle możesz korzystać z najważniejszych funkcji.


3. Porównanie terminali – 6 kandydatów

Testowaliśmy każdy terminal w tym samym środowisku: macOS, sesje Claude Code trwające po kilka godzin, Agent Teams z 3-4 agentami przez tmux, typowa praca z kodem i długie outputy AI. Oto co ustaliliśmy.

Ghostty – rekomendacja

Ghostty to stosunkowo młody projekt (publiczny release w grudniu 2024), napisany w Zig z GPU-accelerated renderingiem przez OpenGL. Twórca, Mitchell Hashimoto (znany z HashiCorp, Vagrant, Terraform), zaprojektował go z myślą o jednej rzeczy: byciu najlepszym emulatorem terminala, bez kompromisów.

Co działa świetnie:

  • Wydajność renderowania jest na najwyższym poziomie. Przy długich outputach Claude Code – a agent potrafi wygenerować setki linii kodu w jednej odpowiedzi – Ghostty nie zwalnia. Scrollowanie po sesji z 200K tokenów kontekstu jest płynne.
  • Integracja z tmux działa bezbłędnie. Agent Teams w Claude Code przez tmux na Ghostty to stabilne, szybkie doświadczenie. Panele renderują się poprawnie, nie ma artefaktów, przełączanie między agentami jest natychmiastowe.
  • Shift+Enter działa od Claude Code 2.1.0 bez żadnej dodatkowej konfiguracji. To było bolączką wczesnych wersji, ale dzisiaj wpisujesz wieloliniowe prompty bez problemów.
  • Konfiguracja to prosty plik tekstowy – żadnego Lua, żadnego YAML z 200 opcjami. Plik ~/.config/ghostty/config z kilkunastoma liniami i masz wszystko ustawione. Zmiana czcionki, kolorów, key bindingów – minuty, nie godziny.
  • Zużycie pamięci ~100 MB przy typowej sesji. To mniej niż iTerm2, mniej niż WezTerm, porównywalnie z Kitty.

Ograniczenia:

  • Ghostty nie ma natywnej multipleksacji – nie obsługuje split-pane wewnętrznie jak Kitty czy WezTerm. Do Agent Teams potrzebujesz tmux. W praktyce to nie problem, bo tmux i tak jest bardziej elastyczny niż wbudowane rozwiązania, ale jeśli chcesz uniknąć tmux za wszelką cenę, Ghostty nie jest odpowiedzią.
  • Projekt jest młody. Ekosystem pluginów nie istnieje, community dopiero rośnie. Jeśli potrzebujesz niszowej funkcji, możesz jej jeszcze nie znaleźć.
  • Brak wersji na Windows (stan na luty 2026). Linux i macOS – tak. Windows – nie.

Werdykt: Najlepszy terminal do pracy z AI ogólnie. Szybki, lekki, stabilny, świetnie współpracuje z tmux i Claude Code. Jeśli masz wybrać jeden terminal i nie chcesz się zastanawiać – wybierz Ghostty.

Kitty – terminal dla power userów

Kitty to GPU-accelerated terminal autorstwa Kovida Goyala, na rynku od 2017 roku. Ma jedną cechę, która wyróżnia go na tle konkurencji: własny protokół graficzny pozwalający wyświetlać obrazy bezpośrednio w terminalu. Do tego wbudowany multiplekser, system pluginów („kittens”) i bardzo rozbudowana konfiguracja.

Co działa świetnie:

  • Wbudowana multipleksacja – Kitty ma natywne okna i zakładki, więc technicznie możesz prowadzić Agent Teams bez tmux. W praktyce Claude Code oficjalnie wspiera tmux, więc i tak warto go użyć, ale sam fakt, że Kitty daje ci podziały paneli „za darmo” jest wygodny w codziennej pracy.
  • Kittens to system pluginów w Pythonie. Możesz pisać własne rozszerzenia, customizować zachowanie terminala, tworzyć skróty do złożonych operacji. Dla ludzi, którzy lubią automatyzować workflow, to duży plus.
  • Protokół graficzny Kitty – jeśli twój AI tool generuje diagramy czy wykresy, Kitty wyświetli je inline. To niszowa funkcja, ale w kontekście narzędzi, które coraz częściej produkują wizualny output, może zyskać na znaczeniu.

Ograniczenia:

  • Twórca Kitty otwarcie nazywa tmux „anti-pattern” i promuje własny multiplekser. To tworzy tarcie – Claude Code wymaga tmux do Agent Teams, a dokumentacja Kitty aktywnie zniechęca do jego używania. Tmux działa z Kitty, ale to nie jest „wspierana” konfiguracja z perspektywy twórcy terminala.
  • Konfiguracja jest znacznie bardziej złożona niż w Ghostty. Plik kitty.conf potrafi rozrosnąć się do setek linii, a ilość opcji jest przytłaczająca dla nowych użytkowników.
  • Zużycie pamięci (~150 MB) jest wyższe niż Ghostty i Alacritty, choć wciąż rozsądne.

Werdykt: Najlepszy wybór dla power userów, którzy chcą jeden terminal do wszystkiego i nie boją się złożonej konfiguracji. Jeśli już znasz Kitty i masz go skonfigurowanego – nie ma powodu, żeby zmieniać. Ale jeśli zaczynasz od zera i szukasz terminala pod AI, Ghostty będzie prostszy w starcie.

Alacritty – surowa prędkość

Alacritty to terminal, który robi jedną rzecz i robi ją najlepiej: renderuje tekst tak szybko, jak to możliwe. Napisany w Rust, z GPU-accelerated renderingiem przez OpenGL, ma najniższą zmierzoną latencję inputu ze wszystkich terminali w tym porównaniu.

Co działa świetnie:

  • Latencja – jeśli mierzysz czas od naciśnięcia klawisza do pojawienia się znaku na ekranie, Alacritty wygrywa. Dla programistów, którzy spędzają cały dzień w terminalu, ta różnica jest odczuwalna.
  • Zużycie pamięci ~50 MB – to połowa Ghostty i ułamek iTerm2. Na maszynach z ograniczoną pamięcią (albo gdy masz otwartych 15 sesji Claude Code) to się liczy.
  • Cross-platform – działa na macOS, Linux i Windows. Identycznie skonfigurowany wszędzie.

Ograniczenia:

  • Alacritty celowo nie implementuje niczego poza renderowaniem tekstu. Brak ligatur czcionek, brak protokołów graficznych, brak zakładek, brak podziału paneli. Do Agent Teams potrzebujesz tmux, do ligatur – innego terminala.
  • Konfiguracja przez TOML jest minimalistyczna, ale właśnie dlatego, że opcji jest mało. Nie skonfigurujesz tego, co nie istnieje.

Werdykt: Najlepsza surowa wydajność. Jeśli zależy ci na absolutnym minimum zużycia zasobów i najniższej latencji, a tmux jest twoim naturalnym środowiskiem – Alacritty jest idealny. Ale musisz zaakceptować, że poza renderowaniem tekstu nie dostaniesz nic.

WezTerm – programowalność przede wszystkim

WezTerm to terminal napisany w Rust z renderingiem przez WebGPU i jedną unikalną cechą: konfiguracja w Lua. To nie plik z opcjami – to pełnoprawny program, który definiuje zachowanie terminala.

Co działa świetnie:

  • Lua config pozwala na rzeczy niemożliwe w innych terminalach: dynamiczne zmiany layoutu, warunkowe key bindingi, integracja z zewnętrznymi API. Jeśli potrzebujesz terminala, który robi dokładnie to, co chcesz – WezTerm da ci narzędzia.
  • Wbudowany multiplekser z natywnym wsparciem dla sesji SSH. Możesz multipleksować panele lokalnie i zdalnie, bez tmux. Dla pracy z remote dev environments to rewelacja.
  • Multiplekser WezTerm działa jako serwer – możesz podłączyć się do sesji z innej maszyny, co przy pracy z rozproszonymi zespołami agentów AI jest praktyczne.

Ograniczenia:

  • ~320 MB RAM to najwyższe zużycie pamięci w tym porównaniu (pomijając Warp). Dla pojedynczej sesji nieistotne, ale przy wielu oknach sumuje się.
  • Lua config jest potężny, ale wymaga nauki Lua. Próg wejścia jest wyższy niż w Ghostty (plik tekstowy) czy Alacritty (TOML).

Werdykt: Najlepszy terminal do remote development i do sytuacji, gdzie potrzebujesz programowalnej konfiguracji. Solidny wybór, choć cięższy od konkurencji.

iTerm2 – klasyk macOS

iTerm2 to terminal, którego nie trzeba przedstawiać użytkownikom macOS. Na rynku od ponad dekady, z ogromnym ekosystemem i jedną cechą, która w kontekście tego artykułu jest kluczowa: natywne wsparcie dla Claude Code Agent Teams bez tmux.

Co działa świetnie:

  • Jedyny terminal (poza tmux) oficjalnie wspierany przez Anthropic do Agent Teams. Możesz orkiestrować wielu agentów Claude Code w natywnych split-pane’ach iTerm2, bez instalowania tmux. Dla ludzi, którzy nie chcą się uczyć tmux – to argument rozstrzygający.
  • Najlepsza integracja z tmux ze wszystkich terminali. Tryb tmux -CC w iTerm2 mapuje sesje tmux na natywne okna i zakładki. Dostajesz pełną wydajność tmux z GUI iTerm2 – scrollowanie myszką, resize paneli kursorem, natywne powiadomienia.
  • Profile i triggery – możesz ustawić różne konfiguracje dla różnych projektów, automatyczne akcje przy określonym output’cie, integrację z macOS.

Ograniczenia:

  • Brak GPU-accelerated renderingu w trybie porównywalnym z Ghostty czy Alacritty. iTerm2 renderuje przez Metal, ale przy naprawdę długich outputach AI (tysiące linii w sekundę) różnica jest odczuwalna. Scrollowanie po wielogodzinnej sesji Claude Code jest wolniejsze niż w GPU-accelerated terminalach.
  • ~200 MB RAM i ogólnie cięższy niż nowoczesna konkurencja.
  • Tylko macOS – jeśli pracujesz cross-platform, iTerm2 nie jest opcją.

Werdykt: Najlepsze natywne wsparcie dla Claude Code na macOS. Jeśli nie chcesz tmux i pracujesz wyłącznie na Macu – iTerm2 jest oczywistym wyborem. Ale jeśli nie przeszkadza ci tmux, Ghostty da ci lepszą wydajność.

Warp – dlaczego odradzamy

Warp to terminal, który próbuje być „terminalem przyszłości” – z wbudowanym AI, block-based input, nowoczesnym UI. Problem polega na tym, że ta wizja przyszłości koliduje z tym, jak działają AI coding tools.

Dlaczego nie:

  • Uruchomienie tmux w Warp wyłącza WSZYSTKIE unikalne funkcje Warpa. Block editing, AI command search, wbudowany autocomplete – wszystko znika. Zostajesz z gołym terminalem, który nie jest szczególnie szybki. A tmux jest wymagany do Claude Code Agent Teams.
  • Warp wymaga konta w chmurze do działania. Dla wielu developerów i firm to dyskwalifikacja ze względów bezpieczeństwa i prywatności.
  • Warp jest zaprojektowany jako zamiennik tmux, nie jego towarzysz. Filozofia produktu jest sprzeczna z wymaganiami Claude Code. To nie bug – to fundamentalny konflikt architektoniczny.

Werdykt: Nie używaj z Claude Code Agent Teams. Warp ma swoje zastosowania, ale współpraca z AI coding tools opartymi o tmux nie jest jednym z nich.

Tabela porównawcza

Terminal Wydajność RAM tmux Agent Teams Prostota konfiguracji
Ghostty 5/5 ~100 MB tak tak (tmux) 5/5
Alacritty 5/5 ~50 MB tak tak (tmux) 4/5
Kitty 4/5 ~150 MB tak tak (tmux) 3/5
WezTerm 4/5 ~320 MB tak tak (tmux) 3/5
iTerm2 3/5 ~200 MB tak+ tak (natywnie) 4/5
Warp 3/5 ~250 MB nie* nie 5/5

*Warp technicznie pozwala uruchomić tmux, ale wyłącza przy tym wszystkie swoje unikalne funkcje, co czyni go de facto gołym terminalem bez przewag.

Uwaga do tabeli: „tak+” przy tmux dla iTerm2 oznacza najlepszą w branży integrację z tmux przez tryb tmux -CC, który mapuje sesje na natywne elementy UI.


Zrób to z ekspertem Bezpłatna 30-minutowa konsultacja — bez zobowiązań.
Zarezerwuj termin →

4. Dlaczego tmux? I kiedy go nie potrzebujesz

Co daje tmux

tmux to multiplekser terminala – program, który tworzy warstwę pośrednią między twoim emulatorem terminala a powłoką systemową. W praktyce daje trzy kluczowe rzeczy.

Session persistence – procesy przetrwają zamknięcie terminala. Wyobraź sobie: Claude Code generuje refaktor 200 plików, a ty przypadkiem zamykasz okno. Bez tmux tracisz wszystko. Z tmux sesja działa w tle – otwierasz terminal ponownie, wpisujesz tmux attach i wracasz dokładnie tam, gdzie skończyłeś.

Split panes – wiele paneli w jednym oknie. Możesz mieć Claude Code w lewym panelu, logi aplikacji w prawym, a na dole git diff śledzący zmiany w czasie rzeczywistym. Wszystko bez przełączania okien.

Remote development – sesja przeżywa zerwanie połączenia SSH. Uruchamiasz agenta AI na zdalnym serwerze, SSH się rozłącza bo Wi-Fi padło na chwilę – sesja tmux dalej działa. Łączysz się ponownie i kontynuujesz.

Kiedy MUSISZ mieć tmux

Są sytuacje, w których tmux nie jest opcją, a wymogiem:

  • Claude Code Agent Teams w trybie split-pane – jeśli nie używasz iTerm2, potrzebujesz tmux do uruchomienia wielu agentów obok siebie. Ghostty, Kitty, Alacritty – żadne z nich nie ma natywnego API do programowego dzielenia okna.
  • Praca zdalna z persistence – jeśli SSH-ujesz się do serwera i uruchamiasz procesy trwające godzinami (trening modelu, długi build, migracja danych), tmux to jedyny sposób na bezpieczne odłączenie się bez przerywania pracy.
  • Serwery produkcyjne – monitoring, logi, deploymenty – tmux pozwala mieć wszystko w jednej sesji, która przetrwa restart połączenia.

Kiedy możesz bez tmux

Nie zawsze potrzebujesz dodatkowej warstwy:

  • Claude Code w trybie in-process – przełączanie między instancjami za pomocą Shift+Up/Down działa natywnie w każdym terminalu. Jeśli nie potrzebujesz widzieć kilku agentów jednocześnie, to wystarczy.
  • iTerm2 na macOS – ma natywne wsparcie dla Agent Teams przez swoje API. tmux jest zbędny.
  • Gemini CLI lub Cursor – te narzędzia nie wymagają tmux do żadnej ze swoich funkcji. Cursor i tak działa w GUI, a Gemini CLI to pojedynczy proces.

tmux w kontekście AI coding

W erze agentów AI tmux zyskuje nowe znaczenie. Agent pracuje w tle nawet gdy zamkniesz terminal – nie tracisz kontekstu rozmowy, historii zmian ani stanu agenta. Session persistence oznacza, że możesz zamknąć laptopa wieczorem, otworzyć go rano i wrócić do sesji z pełnym kontekstem. A split panes pozwalają obserwować kilku agentów jednocześnie – jeden refaktoryzuje backend, drugi pisze testy, trzeci generuje dokumentację. Widzisz postęp wszystkich naraz.


5. Konfiguracja: Ghostty + tmux krok po kroku

To jest kompletny przewodnik konfiguracji. Każdy krok przetestowany, każdy blok kodu gotowy do skopiowania i wklejenia.

Krok 0: Sprawdzenie środowiska

Zanim cokolwiek skonfigurujesz, upewnij się, że masz odpowiednie narzędzia.

# Sprawdź architekturę Maca
uname -m
# arm64 = Apple Silicon (M1/M2/M3/M4)
# x86_64 = Intel

# Sprawdź czy Homebrew (https://brew.sh) jest zainstalowany
which brew
# Jeśli brak: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Zainstaluj tmux
brew install tmux

# Sprawdź ścieżkę do tmux -- zapamiętaj ją
which tmux
# /opt/homebrew/bin/tmux  (Apple Silicon)
# /usr/local/bin/tmux     (Intel)

Ghostty powinien być już zainstalowany. Jeśli nie – pobierz go z oficjalnej strony Ghostty. Warto też zainstalować czcionkę JetBrains Mono jeśli jej jeszcze nie masz.

Krok 1: Znajdź config Ghostty

Ghostty szuka konfiguracji w dwóch lokalizacjach. Sprawdź, która istnieje u ciebie:

# Lokalizacja 1 (preferowana)
ls ~/.config/ghostty/config

# Lokalizacja 2 (alternatywna na macOS)
ls ~/Library/Application\ Support/com.mitchellh.ghostty/config

Jeśli żaden plik nie istnieje, stwórz pierwszy wariant:

mkdir -p ~/.config/ghostty
touch ~/.config/ghostty/config

Krok 2: Backup obecnej konfiguracji

Zawsze rób backup przed zmianami:

cp ~/.config/ghostty/config ~/.config/ghostty/config.backup.$(date +%Y%m%d)

Jeśli coś pójdzie nie tak, przywrócisz oryginał jednym poleceniem:

cp ~/.config/ghostty/config.backup.* ~/.config/ghostty/config

Krok 3: Stwórz skrypt auto-startu tmux

Ten skrypt automatycznie tworzy nową sesję tmux dla każdego taba Ghostty. Dzięki temu Cmd+T otwiera czystą sesję, a nie podłącza się do już istniejącej – co jest kluczowe przy pracy z wieloma projektami jednocześnie.

cat > ~/.config/ghostty/ghostty-tmux.sh << 'SCRIPT'
#!/bin/bash

# Auto-detekcja lokalizacji tmux
if [ -f "/opt/homebrew/bin/tmux" ]; then
    TMUX_BIN="/opt/homebrew/bin/tmux"
elif [ -f "/usr/local/bin/tmux" ]; then
    TMUX_BIN="/usr/local/bin/tmux"
else
    echo "tmux nie znaleziony! Zainstaluj: brew install tmux" >&2
    exit 1
fi

# Każdy tab Ghostty dostaje unikalną sesję tmux
# Pierwszy tab = "ghostty", kolejne = "ghostty-2", "ghostty-3", itd.
SESSION_BASE="ghostty"
SESSION_NAME="$SESSION_BASE"
COUNTER=2
while $TMUX_BIN has-session -t "$SESSION_NAME" 2>/dev/null; do
    SESSION_NAME="${SESSION_BASE}-${COUNTER}"
    COUNTER=$((COUNTER + 1))
done

exec $TMUX_BIN new-session -s "$SESSION_NAME"
SCRIPT

Dlaczego osobna sesja per tab? Gdy Claude Code uruchamia Agent Teams w trybie split-pane, dzieli bieżącą sesję tmux na panele. Gdyby wszystkie taby współdzieliły jedną sesję, agenci z jednego projektu mieszaliby się z drugim. Osobne sesje oznaczają pełną izolację – w jednym tabie agenci pracują nad backendem, w drugim nad frontendem, bez interferencji.

Nadaj uprawnienia do wykonania:

chmod +x ~/.config/ghostty/ghostty-tmux.sh

Przetestuj skrypt ręcznie, zanim podepniesz go do Ghostty:

~/.config/ghostty/ghostty-tmux.sh

Powinieneś wylądować w sesji tmux o nazwie „ghostty”. Wyjdź z niej przez Ctrl+B, potem d (detach).

Krok 4: Konfiguracja Ghostty

Otwórz plik konfiguracyjny i wklej poniższe ustawienia:

# Automatyczny start tmux
command = ~/.config/ghostty/ghostty-tmux.sh

# Nowy tab (Cmd+T) otwiera się w tym samym katalogu co aktualny
window-inherit-working-directory = true

# Czcionka -- JetBrains Mono (https://www.jetbrains.com/lp/mono/) jest świetna do kodu
font-family = JetBrains Mono
font-size = 14

# Motyw (https://catppuccin.com) -- UWAGA: nazwa z wielkimi literami i spacją!
theme = Catppuccin Mocha

# Przezroczystość tła (wartość 0.0 - 1.0)
background-opacity = 0.95

# Padding okna dla lepszej czytelności
window-padding-x = 10
window-padding-y = 10

# Shift+Enter wysyła literalny newline (przydatne w Claude Code)
keybind = shift+enter=text:\n

Ważna uwaga dotycząca motywu: Nazwa to Catppuccin Mocha – z wielkimi literami i spacją. Nie catppuccin-mocha, nie catppuccin_mocha. Ghostty ma wbudowane motywy i dokładna nazwa ma znaczenie.

Krok 5: Konfiguracja Claude Code do pracy z tmux

Aby Claude Code używał tmux do orchestracji agentów, ustaw tryb teammateMode w pliku konfiguracyjnym:

# Otwórz (lub stwórz) plik ustawień Claude Code
# Lokalizacja: ~/.claude/settings.json

Dodaj lub zmień następujące ustawienia:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "teammateMode": "tmux"
}
  • CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS – włącza funkcję Agent Teams (w momencie publikacji nadal oznaczoną jako eksperymentalna)
  • teammateMode: "tmux" – mówi Claude Code, żeby używał tmux do tworzenia paneli dla agentów. Alternatywa to "iterm2" jeśli wolisz natywne panele iTerm2

Uwaga: Jeśli masz już inne ustawienia w settings.json (permissions, pluginy), dopisz te klucze do istniejącego obiektu JSON – nie nadpisuj całego pliku.

Po zapisaniu pliku zrestartuj Claude Code (wyjdź i uruchom ponownie claude), żeby ustawienia zostały załadowane.

Krok 6: Test konfiguracji

Zamknij Ghostty całkowicie (Cmd+Q, nie tylko zamknięcie okna) i uruchom ponownie.

# Sprawdź czy jesteś w tmux
echo $TMUX
# Powinno wyświetlić ścieżkę, np. /tmp/tmux-501/default,12345,0

# Sprawdź aktywne sesje
tmux ls
# Powinno pokazać: ghostty: 1 windows (created ...)

# Test persistence -- zamknij Ghostty (Cmd+Q), otwórz ponownie
# Powinieneś wrócić do tej samej sesji

# Test podziału paneli
# Ctrl+B %    -- podział pionowy (lewa/prawa)
# Ctrl+B "    -- podział poziomy (góra/dół)

Rozwiązywanie problemów

„tmux: command not found” – Ghostty może nie widzieć tmux jeśli PATH nie jest poprawnie ustawiony. Rozwiązanie: w skrypcie ghostty-tmux.sh używamy pełnych ścieżek, więc ten problem nie powinien wystąpić. Jeśli jednak się pojawia, sprawdź which tmux i upewnij się, że ścieżka zgadza się z tą w skrypcie.

„theme not found” albo brzydkie kolory – sprawdź wielkość liter w nazwie motywu. Użyj ghostty +list-themes w terminalu, żeby zobaczyć dostępne motywy i ich dokładne nazwy.

„sessions should be nested with TMUX_TMPDIR” – to znaczy, że już jesteś wewnątrz tmux i próbuje się uruchomić kolejna sesja. To dobrze – skrypt działa poprawnie. Ten komunikat pojawia się tylko gdy ręcznie próbujesz odpalić tmux będąc już w sesji.

Ghostty się nie uruchamia / biały ekran – zakomentuj linię command w configu (dodaj # na początku), uruchom Ghostty i debuguj skrypt ręcznie z poziomu terminala.

Ściągawka – komendy tmux

+------------------------------------------------------------------+
|                        OKNA (Windows)                            |
+------------------------------------------------------------------+
| Ctrl+B c          | Nowe okno                                    |
| Ctrl+B 0-9        | Przejdź do okna o danym numerze              |
| Ctrl+B n          | Następne okno                                |
| Ctrl+B p          | Poprzednie okno                              |
| Ctrl+B ,          | Zmień nazwę okna                             |
+------------------------------------------------------------------+
|                        PANELE (Panes)                            |
+------------------------------------------------------------------+
| Ctrl+B %          | Podział pionowy (lewa/prawa)                 |
| Ctrl+B "          | Podział poziomy (góra/dół)                   |
| Ctrl+B strzałki   | Nawigacja między panelami                    |
| Ctrl+B x          | Zamknij bieżący panel                        |
| Ctrl+B z          | Zoom (pełny ekran / przywróć)                |
+------------------------------------------------------------------+
|                        SESJE (Sessions)                          |
+------------------------------------------------------------------+
| Ctrl+B d          | Odłącz się od sesji (detach)                 |
| tmux ls           | Lista aktywnych sesji                        |
| tmux attach       | Podłącz do ostatniej sesji                   |
| tmux attach -t X  | Podłącz do sesji o nazwie X                  |
| tmux kill-session -t X | Usuń sesję o nazwie X                    |
+------------------------------------------------------------------+

6. Rekomendacje – co wybrać?

Wybór terminala zależy od tego, jakich narzędzi AI używasz i na jakiej platformie pracujesz. Oto drzewo decyzyjne.

Używasz Claude Code Agent Teams?

  • macOS: iTerm2 (zero konfiguracji, natywne wsparcie) lub Ghostty + tmux (szybszy rendering, wymaga konfiguracji powyżej)
  • Linux: Ghostty + tmux lub Kitty + tmux – oba działają świetnie, Ghostty jest prostszy w konfiguracji

Głównie Cursor?

  • Terminal jest drugorzędny, bo większość pracy odbywa się w GUI. Ale jeśli używasz wbudowanego terminala Cursora i czujesz lag, Ghostty lub Kitty jako zewnętrzny terminal z GPU-accelerated renderingiem rozwiążą problem.

Gemini CLI?

  • Każdy terminal wystarczy. Jeśli zależy ci na maksymalnej wydajności, Alacritty – nie ma prostszego i szybszego terminala.

Mix narzędzi + praca zdalna?

  • WezTerm – multiplekser wbudowany, Lua scripting pozwala zautomatyzować różne workflow’y, cross-platform bez niespodzianek.

Chcesz najprostrze rozwiązanie?

  • Ghostty – sensowne defaulty, minimalna konfiguracja, szybki. Zainstaluj i zacznij pracować.

Nasze top 3

1. Ghostty + tmux – najlepszy balans między wydajnością, prostotą i kompatybilnością z narzędziami AI. Konfiguracja z sekcji 5 daje gotowy do pracy setup w 10 minut. Ghostty jest szybki, dobrze wygląda out of the box i ma rosnącą społeczność. tmux dodaje brakującą warstwę persistence i split panes.

2. iTerm2 – najłatwiejszy wybór na macOS. Natywne wsparcie dla Claude Code Agent Teams bez tmux, bogaty zestaw funkcji, stabilne API. Jedyna wada to brak GPU-accelerated renderingu – przy bardzo długich outputach agentów AI możesz zauważyć różnicę w płynności. W praktyce dla większości użytkowników to nie ma znaczenia.

3. Kitty + tmux – dla zaawansowanych użytkowników, którzy chcą pełnej kontroli. Kitty ma własny protokół graficzny (wyświetlanie obrazów w terminalu), potężny system kitten-ów i świetną dokumentację. Krzywa uczenia jest bardziej stroma niż Ghostty, ale możliwości konfiguracji są praktycznie nieograniczone.


7. Podsumowanie

TL;DR – ranking terminali do pracy z AI

  • Najlepszy ogólnie: Ghostty – szybki, prosty, świetna kompatybilność z narzędziami AI
  • Najlepsza wydajność: Alacritty – minimalny, GPU-first, zero zbędnych funkcji
  • Najwięcej funkcji: Kitty – grafika w terminalu, kittens, pełna konfigurowalność
  • Najlepszy do pracy zdalnej: WezTerm – wbudowany multiplekser, Lua scripting, cross-platform
  • Najlepszy natywny na macOS: iTerm2 – zero konfiguracji dla Agent Teams, dojrzały ekosystem
  • Omijaj: Warp – zamknięty ekosystem, wbudowane AI koliduje z zewnętrznymi agentami

Co przyniesie przyszłość

Krajobraz narzędzi AI zmienia się szybko. Claude Code ma już browser IDE – terminale powoli stają się „cienkimi klientami”, które po prostu muszą szybko renderować tekst i nie przeszkadzać. Coraz więcej narzędzi AI będzie terminal-first, bo tekst to najefektywniejszy interfejs dla agentów. GPU-accelerated rendering przestaje być bonusem – staje się wymogiem, gdy agent generuje tysiąc linii kodu w kilka sekund. A kompatybilność z tmux to cecha, którą docenisz w momencie, gdy zaczniesz orkiestrować wiele agentów jednocześnie.

Nie ma jednego idealnego terminala. Ale jest terminal idealny dla twojego workflow. Mamy nadzieję, że ten przewodnik pomógł ci go znaleźć.


Masz pytania dotyczące konfiguracji terminala do pracy z AI? Odezwij się do nas na important.is – pomagamy zespołom wdrażać narzędzia AI w codziennej pracy programistycznej.

Zostań w pętli

Nowe artykuły, narzędzia i case study — prosto na maila.


Newsletter - Blog