Nanocoder — agent kodujący działający lokalnie na dowolnym modelu

Agentowe kodowanie w terminalu przestało być nowinką i zrobiło się kategorią produktów. Prawie wszystkie mają jednak tę samą cechę: stoi za nimi firma, która decyduje, jaki model obsłuży twoje żądanie, gdzie pojadą twoje pliki i które funkcje trafią za paywall. Dla wielu zespołów to układ całkowicie akceptowalny. Dla części — nie, i to nie z ideologii, a z zapisów w umowach z klientami.

Nanocoder jest propozycją z drugiej strony: agentem kodującym, którego buduje kolektyw, a nie spółka, i który zakłada, że model przyprowadzasz własny — lokalny przez Ollamę albo dowolny zgodny z API OpenAI. Autorzy formułują to zwięźle: przyprowadź swój model, trzymaj kod na swojej maszynie i nie bądź nikomu nic winien.

Stan projektu

Repozytorium: Nano-Collective/nanocoder. 2462 gwiazdki, 315 forków, start w lipcu 2025. Tempo pracy jest wysokie — commity na gałęzi main pochodzą z dnia powstania tego wpisu, a wydania idą w rytmie miesięcznym: v1.30.0 z 26 sierpnia 2026, wcześniej v1.29.0 w lipcu, v1.28.1 i v1.28.0 w czerwcu, v1.27.0 w maju. Na npm jest pięćdziesiąt dziewięć wersji, a plik z listą zmian waży 122 kB. Otwartych zgłoszeń jest 158, co przy takim tempie jest raczej objawem ruchu niż zaniedbania.

Licencja to MIT, prawa po stronie Nano Collective. Warto o tym powiedzieć, bo GitHub raportuje dla tego repozytorium NOASSERTION — nie z powodu jakiegoś haczyka, a dlatego, że plik nazywa się LICENSE.md i zaczyna się nagłówkiem, czego automat rozpoznający licencje nie łyka. Treść w środku to zwykły, niezmieniony MIT.

Kolektyw, nie firma

Model organizacyjny jest tu częścią produktu, więc wypada go opisać. Za projektem stoi Nano Collective — wspólnota budująca narzędzia oparte o modele językowe nie dla zysku. Autorzy piszą wprost, czego z tego wynika: nie ma płatnych poziomów, nie ma telemetrii wysyłającej twoje prompty w świat i nie ma planu rozwoju sterowanego tym, co najlepiej się monetyzuje. Wielodostawcowość jest w tym ujęciu zasadą, nie funkcją — nigdy nie jesteś przypisany do modelu jednego producenta.

Uczciwie trzeba dodać dwie rzeczy z drugiej strony. Praca jest finansowana przez sponsorów, a jeden z obecnych sponsorów to platforma dostarczająca dostęp do modeli — czyli podmiot z tej samej branży, w której narzędzie pośredniczy. Nie widzę w tym problemu, bo wybór dostawcy pozostaje po stronie użytkownika i nie ma tu żadnego domyślnego wskazania, ale warto o tym wiedzieć, zamiast dowiedzieć się później. Druga rzecz: kolektyw prowadzi „kartę ekonomiczną" opisującą, jak działają płatne zlecenia o określonym zakresie — więc nie jest to czysty wolontariat, a model mieszany, opisany jawnie.

Uruchomienie

Instalacja jest zwyczajna, a poza npm dostępne są Homebrew oraz Nix Flakes — w repozytorium widać zarówno katalog z formułą, jak i plik flake.nix:

npm install -g @nanocollective/nanocoder
nanocoder

Dostawcę, model i tryb startowy można wskazać wprost, a polecenie run uruchamia zadanie nieinteraktywnie — co czyni to narzędzie użytecznym w potokach CI, nie tylko przy klawiaturze:

nanocoder --provider ollama --model llama3.1
nanocoder --provider openrouter --model google/gemini-3.1-flash run "przeanalizuj src/app.ts"
nanocoder --mode plan run "zaudytuj moduł uwierzytelniania"

Warto odnotować szczegół dotyczący samego terminala, bo pokazuje dbałość o detal. Domyślnie interfejs renderuje się w trybie liniowym: zakończone wiadomości trafiają raz do natywnej historii przewijania terminala, więc pasek przewijania, kółko myszy i wyszukiwanie działają jak zwykle, a zapis rozmowy zostaje po wyjściu. Tryb pełnoekranowy (--alt-screen) daje układ o stałej wysokości z własnym przewijaniem — a skoro przechwytuje zdarzenia myszy i zabiera terminalowi zaznaczanie, to skrót Ctrl+P przełącza tryb zaznaczania, żeby dało się skopiować tekst. To rodzaj problemu, o którym się nie myśli, dopóki nie spróbuje się czegoś skopiować.

Cztery tryby pracy

To najważniejsza część interfejsu, bo decyduje o tym, ile agent może zrobić bez pytania. Tryby przełącza się w trakcie rozmowy skrótem Shift+Tab, a bieżący widać na pasku stanu.

normal — każde wywołanie narzędzia wymaga jawnego potwierdzenia. Domyślny w sesji interaktywnej.
auto-accept — większość wywołań idzie bez pytania, ale polecenia powłoki i niszczące operacje gita (twardy reset, wymuszone usunięcie, porzucenie schowka) nadal proszą o zgodę. Domyślny dla trybu run.
yolo — wszystko wykonuje się natychmiast, bez wyjątków, wraz z poleceniami powłoki i niszczącymi operacjami gita. Pasek stanu robi się czerwony. Zostaje jedno zabezpieczenie: jeśli model powtórzy identyczne wywołanie zbyt wiele razy pod rząd, Nanocoder zatrzymuje się i pyta, czy kontynuować — żeby zapętlony model nie przepalił budżetu bez nadzoru.
plan — tryb wyłącznie analityczny. Agent dostaje jedynie narzędzia do czytania, nie może edytować plików, uruchamiać powłoki ani zmieniać stanu gita i zadań. Produkuje uporządkowany plan (podsumowanie, lista plików do zmiany, kroki po kolei, zależności i ryzyka, pytania otwarte), który jest zapisywany, żebyś mógł go przeczytać i zaakceptować, zanim cokolwiek się wykona.

Rozdzielenie domyślnych trybów jest przemyślane: przy klawiaturze dostajesz ostrożny normal, a w trybie run — gdzie nikt nie klika potwierdzeń — auto-accept, który wciąż zatrzymuje się przed powłoką. Nieprawidłowa wartość --mode kończy się błędem, a nie cichym fallbackiem.

Piaskownica, której domyślnie nie ma

Ta sekcja jest najważniejsza w całym wpisie, a jednocześnie jest miejscem, w którym dokumentacja tego projektu zasługuje na wyróżnienie — bo mówi rzeczy, które większość narzędzi tej kategorii przemilcza.

Stan wyjściowy: narzędzia plikowe odmawiają ścieżek spoza projektu, ale execute_bash i skrót !polecenie tego nie robiły — uruchamiają sh z pełnymi uprawnieniami twojego użytkownika. Można to obudować jailem systemowym, ustawiając nanocoder.sandbox na true. Domyślnie jest wyłączone. Przy okazji drobiazg pokazujący staranność: łańcuch "true" jest ignorowany i traktowany jako wyłączenie, z ostrzeżeniem — bo autorzy przewidzieli, że ktoś wpisze wartość jako tekst.

Co daje włączona piaskownica, zależy od systemu:

macOS — sandbox-exec, o którym dokumentacja uczciwie pisze, że jest przez Apple oznaczony jako przestarzały, choć nadal obecny. Brak sieci; zapis dozwolony w katalogu projektu, w katalogu tymczasowym na polecenie i w /tmp.
Linux — bwrap (bubblewrap): brak sieci, montowanie całego systemu plików tylko do odczytu plus zapisywalny katalog projektu i katalog tymczasowy. I zachowanie, które należy chwalić: jeśli bwrap nie ma albo nie potrafi utworzyć przestrzeni nazw użytkownika, narzędzie zwraca błąd i nie schodzi po cichu do niesandboksowanej powłoki. Awaria zamyka, a nie otwiera.
Windows — nieobsługiwane w tej wersji. Włączona flaga skutkuje błędem.

A teraz zdanie, które autorzy stawiają sami i które trzeba przeczytać dwa razy: to nie jest granica dla sekretów. Sieć jest zablokowana, zapis poza projektem zablokowany, ale czytanie nie jest ograniczone — dokumentacja podaje wprost, że cat ~/.ssh/id_rsa nadal działa, a jego wyjście nadal trafia do modelu. Piaskownica nie obejmuje też narzędzi własnych ani serwerów MCP.

Wniosek praktyczny jest jednoznaczny i dotyczy każdego narzędzia tej klasy, nie tylko tego. Jeśli uruchamiasz agenta na maszynie, na której leżą klucze SSH, pliki .env z hasłami produkcyjnymi albo poświadczenia do chmury, to model — namówiony treścią repozytorium, cudzym zgłoszeniem czy komentarzem w kodzie — może je odczytać i wypisać do rozmowy. Ta rozmowa idzie potem do dostawcy, którego wybrałeś. Odpowiedzią nie jest rezygnacja z narzędzia, a przeniesienie sekretów poza maszynę roboczą, korzystanie z modelu lokalnego przy pracy na wrażliwych repozytoriach i traktowanie trybu yolo jak tego, czym jest.

Punkty kontrolne i dokumentacja, która nie ściemnia

Mechanizm punktów kontrolnych zapisuje migawkę sesji — historię rozmowy, zmienione pliki i konfigurację dostawcy oraz modelu — żeby dało się spróbować ryzykownej przebudowy i wrócić. Obsługuje się to poleceniami /checkpoint create, list, load i delete, a dane leżą w .nanocoder/checkpoints/ w katalogu projektu (i wypada je dopisać do .gitignore). Pliki zapisywane są bajt w bajt, więc binaria — obrazy, czcionki, artefakty kompilacji — przechodzą podróż w obie strony bez zmian.

Ale to nie mechanizm mnie tu przekonał, a sposób jego opisania. Dokumentacja ma osobną sekcję o niekompletnych punktach kontrolnych i wymienia dokładnie, kiedy migawka nie obejmie całości: plik, którego nie dało się przeczytać w momencie tworzenia (bo trzymał go edytor albo antywirus, albo zabrakło uprawnień), nie został przechwycony; przechwytywanych jest najwyżej pięćdziesiąt zmienionych plików, a nadwyżka wypada; plik przechwycony, którego zapisana kopia zniknęła, nie da się przywrócić. I zdanie kluczowe: każda z tych sytuacji jest raportowana przy przywracaniu, z nazwami plików, które nie wróciły — żeby częściowe przywrócenie nigdy nie wyglądało jak kompletne.

Jest jeszcze detal, który pokazuje przemyślenie granic. Migawki pomijają to, co pasuje do .gitignore, ale celowo ignorują plik .nanocoderignore — bo ukrycie pliku przed listingami modelu nie powinno po cichu wykluczyć go z przywracania. Plik ukryty przed modelem nadal jest zapisywany i nadal jest cofany. To jest właśnie ten rodzaj rozgraniczenia, którego brak psuje potem czyjś dzień.

Jedno ograniczenie warto zapamiętać: wczytanie punktu kontrolnego przywraca pliki natychmiast, ale odtworzenie historii rozmowy wymaga ponownego uruchomienia programu.

Umiejętności, demon i tempo zmian

Rozszerzalność stoi na „umiejętnościach" (skills), obejmujących własne polecenia, podagentów, własne narzędzia i wyzwalacze zdarzeń, oraz na demonie działającym per projekt. To ten demon budzi zadania, gdy zadziała wyzwalacz — w tym wyzwalacz czasowy typu cron, dopisywany wprost we frontmatterze polecenia albo w manifeście pakietu umiejętności.

I tu przykład tempa, w jakim ten projekt się zmienia, wart uwagi przy planowaniu wdrożenia. Samodzielny harmonogram — polecenia /schedule create, add, start i plik .nanocoder/schedules.json — został usunięty i zastąpiony subskrypcjami umiejętności. Dziś /schedule jest wyłącznie do odczytu i pokazuje, co i kiedy zadziała, a żeby dodać wyzwalacz, edytuje się plik źródłowy i restartuje demona. Stary plik nie jest już czytany, a jego obecność wywołuje głośne ostrzeżenie o wycofaniu, wskazujące stronę z instrukcją migracji.

Jest to zmiana łamiąca zgodność, przeprowadzona porządnie: z jawnym komunikatem, dokumentem migracyjnym i przykładami przed i po. Ale też sygnał, że przy wersji 1.30 po roku istnienia projekt jeszcze przestawia własne fundamenty — więc jeśli oprzesz na nim automatyzację, licz się z podobnymi przeprowadzkami i czytaj listę zmian przed aktualizacją.

Reszta ekosystemu i jakość inżynierska

Sam katalog dokumentacji funkcji liczy dwadzieścia dwa pliki i pokazuje zakres tego projektu lepiej niż lista w README. Poza omówionymi są tam: zaczepy cyklu życia, podagenci, własne narzędzia i polecenia, kompresja kontekstu, pamięć semantyczna, zarządzanie sesjami i zadaniami, załączniki graficzne, powiadomienia, eksplorator plików, skróty klawiszowe, konwencje wyjścia narzędzi, obsługa protokołu klienta agenta oraz rozszerzenie do Visual Studio Code (którego dokumentacja sama waży 16 kB).

Zaplecze też wygląda poważnie i to rzadkość przy projekcie z rocznym stażem: konfiguracja Semgrepa do skanowania bezpieczeństwa, katalog testów porównawczych, knip do wykrywania martwego kodu, biome do formatowania i lintowania, changesets do wydań, husky na zaczepach gita, kontener deweloperski, plik flake.nix, osobny dokument z testami dymnymi oraz odznaki generowane automatycznie w potoku CI. Do tego przykładowe pliki .env.example i .mcp.example.json, czyli konfiguracja pokazana zamiast opisana.

Gdzie trafia twój kod

To pytanie, na które przy tym narzędziu odpowiedź jest w twoich rękach, i to jest jego główna zaleta w kontekście firmowym. Nanocoder sam nie prowadzi żadnego dostawcy: wskazujesz Ollamę na własnej maszynie albo w firmowej sieci — i wtedy treść plików nie opuszcza waszej infrastruktury — albo wskazujesz dostawcę zewnętrznego, i wtedy opuszcza dokładnie w takim zakresie, w jakim on to opisuje.

Praktycznie znaczy to, że na repozytoriach objętych umową z klientem można pracować z modelem lokalnym, a na własnych projektach z modelem zdalnym, którego jakość jest zwykle wyższa. Autorzy zapewniają przy tym, że nie ma telemetrii wysyłającej prompty — a przy licencji MIT i otwartym kodzie jest to twierdzenie, które da się sprawdzić, a nie tylko przyjąć na słowo.

Pułapki w jednym miejscu

Piaskownica jest domyślnie wyłączona, a execute_bash uruchamia powłokę z twoimi pełnymi uprawnieniami.
Włączona piaskownica nie ogranicza czytania. Autorzy piszą wprost, że to nie granica dla sekretów — klucze i pliki .env mogą trafić do rozmowy.
Piaskownica nie obejmuje narzędzi własnych ani serwerów MCP, a na Windowsie nie działa w ogóle.
Tryb yolo wykonuje wszystko, w tym twardy reset gita. Jedyne zabezpieczenie dotyczy powtarzanych identycznych wywołań.
W trybie run domyślny tryb to auto-accept, nie normal — o czym warto pamiętać, wpuszczając to do CI.
Punkt kontrolny obejmuje najwyżej 50 zmienionych plików i pomija te, których nie dało się odczytać.
Przywrócenie historii rozmowy wymaga restartu programu — same pliki wracają od razu.
Samodzielny harmonogram został usunięty. Jeśli macie .nanocoder/schedules.json, trzeba go przenieść do subskrypcji umiejętności.
Projekt przestawia własne fundamenty — czytaj listę zmian przed każdą aktualizacją.
GitHub raportuje licencję jako NOASSERTION z powodu nazwy pliku; treść to zwykły MIT.
158 otwartych zgłoszeń. Nie licz na szybką reakcję na swoje.

Podsumowanie

Nanocoder jest projektem, który rozwiązuje problem realny dla części firm: chcesz agentowego kodowania, ale nie chcesz oddawać decyzji o tym, gdzie jedzie twój kod, ani płacić za funkcje ukryte za poziomem abonamentu. Robi to bez ideologicznych deklaracji zamiast funkcji — po roku istnienia ma cztery przemyślane tryby pracy, punkty kontrolne, demona z wyzwalaczami i rozszerzenie do edytora.

Dowolny model, także lokalny — Ollama albo cokolwiek zgodnego z API OpenAI, bez domyślnego wskazania dostawcy.
Cztery tryby o jasnej semantyce, z trybem plan pozbawionym narzędzi mutujących i osobnymi wartościami domyślnymi dla pracy interaktywnej i wsadowej.
Punkty kontrolne z zapisem bajt w bajt, obejmujące także binaria, z uczciwym raportowaniem tego, czego nie udało się przywrócić.
Rozszerzalność przez umiejętności — własne polecenia, podagenci, narzędzia i wyzwalacze czasowe obsługiwane przez demona per projekt.
Tryb nieinteraktywny run, który czyni to narzędzie użytecznym w potokach CI.
Dokumentacja, która opisuje własne słabości — od przestarzałego mechanizmu piaskownicy na macOS po limit pięćdziesięciu plików w migawce.

Projekt jest wydany na licencji MIT z prawami Nano Collective — permisywnie, bez obowiązku otwierania własnych zmian, z możliwością komercyjnego użycia i dostarczania klientom. W przypadku narzędzia, które ma być alternatywą dla zamkniętych produktów, to licencja spójna z deklaracją: nie ma tu funkcji za paywallem, bo nie ma mechanizmu, którym dałoby się je zamknąć. Warto natomiast pamiętać, że MIT zdejmuje z autorów odpowiedzialność — a przy narzędziu, które za twoim przyzwoleniem uruchamia polecenia na twojej maszynie, ten zapis nie jest formalnością.