Polecenia CLI

Na tej stronie znajdziesz wszystkie podpolecenia speedwave. O tym, czym jest CLI i kiedy sięgnąć po nie zamiast po Desktop, przeczytasz w przeglądzie funkcji CLI.

Lista poleceń

Polecenie	Przeznaczenie
speedwave [--project <nazwa>]	Uruchamia kontenery projektu i otwiera interaktywną sesję Claude
speedwave init [nazwa]	Rejestruje bieżący katalog jako projekt
speedwave login [--project <nazwa>]	Loguje do Anthropic
speedwave logout [--project <nazwa>]	Usuwa dane logowania Claude z projektu
speedwave check	Uruchamia sprawdzenia wymagań wstępnych i bezpieczeństwa
speedwave update [--project <nazwa>]	Przebudowuje obrazy i tworzy kontenery od nowa
speedwave self-update	Zastępuje plik binarny CLI najnowszym wydaniem
speedwave plugin install <ścieżka.zip>	Instaluje podpisaną wtyczkę
speedwave plugin list	Wyświetla zainstalowane wtyczki i ich status
speedwave plugin remove <slug>	Usuwa wtyczkę
speedwave plugin enable <id> --project <nazwa>	Włącza wtyczkę dla projektu
speedwave plugin disable <id> --project <nazwa>	Wyłącza wtyczkę dla projektu
speedwave --help / -h / help	Wypisuje sposób użycia i kończy działanie

Nieznane polecenie wypisuje unknown command: '<x>'. Run 'speedwave --help' for usage. Nadmiarowy argument po poprawnym poleceniu wypisuje unexpected argument: '<x>'. --help, -h i help działają nawet wtedy, gdy środowisko nie jest uruchomione, więc listę poleceń sprawdzisz, zanim zainstalujesz Desktop albo gdy konfiguracja jest akurat rozsypana.

Jak CLI wybiera projekt

Większość poleceń działa na pojedynczym projekcie, a flaga --project <nazwa> obowiązuje przy uruchomieniu bez argumentów oraz w poleceniach login, logout i update. Docelowy projekt CLI wybiera w następującej kolejności:

1. Flaga --project <nazwa>, jeśli ją podasz. Działają obie formy, --project <nazwa> i --project=<nazwa>, z dowolnego katalogu, a nazwa musi pasować do zarejestrowanego projektu.
2. Aktywny projekt z pola active_project w ~/.speedwave/config.json, ustawiany przez przełącznik projektów w Desktop.
3. Pierwszy skonfigurowany projekt, jeśli żaden nie jest oznaczony jako aktywny.

Jeśli żaden z tych kroków nie wskaże projektu, polecenie kończy się błędem No project configured.

Katalog roboczy nigdy nie decyduje o wyborze projektu. Jedyny wyjątek to speedwave init, które rejestruje katalog, w którym się właśnie znajdujesz.

Uruchomienie speedwave bez argumentów buduje przy okazji wszystkie brakujące obrazy kontenerów projektu, zanim wystartuje, i wypisuje wtedy Built N container image(s) for this app version. Po zbudowaniu synchronizuje z projektem umiejętności i polecenia Claude (a gdy synchronizacja albo sprawdzenie obrazów się nie powiedzie, ostrzega, że umiejętności mogą być nieaktualne), po czym usuwa zastąpione tagi obrazów, ostrzegając w razie niepowodzenia, lecz nie przerywając uruchomienia. To co innego niż jawne polecenie speedwave update.

Zarejestruj projekt

speedwave init rejestruje bieżący katalog jako projekt. Bez podanej nazwy Speedwave wyprowadza ją z nazwy katalogu:

speedwave init          # registers as "acme"
speedwave init my-app   # registers under a name you choose

Nazwa projektu liczy najwyżej 63 znaki, zaczyna się od małej litery lub cyfry i składa się wyłącznie ze znaków a-z, 0-9, _, . oraz -. Wielkie litery i pozostałe znaki są odrzucane, a Speedwave proponuje wtedy formę zapisaną małymi literami. Jeśli katalog jest już zarejestrowany, init wypisuje jego dotychczasową nazwę i kończy działanie bez błędu. Uruchomione środowisko nie jest do tego potrzebne.

Logowanie i wylogowanie

speedwave login uruchamia kontenery projektu, a następnie od razu wykonuje claude auth login --claudeai wewnątrz kontenera, dzięki czemu OAuth startuje natychmiast. Nie musisz wpisywać żadnego polecenia /login: CLI wypisuje Starting Anthropic sign-in. Follow the prompt, then close the terminal when done., a proces kończy się z kodem wyjścia tego polecenia. Powstałe dane logowania Claude Code zapisuje w punkcie montowania claude-home projektu, więc przetrwają one ponowne uruchomienie.

Zanim sesja się rozpocznie, login wymusza również, by aktywnym dostawcą LLM w projekcie był Anthropic. Jeśli skonfigurowany jest własny dostawca (na przykład lokalny model w LM Studio), Speedwave najpierw przenosi tę konfigurację, żeby jej nie skasować, a dopiero potem przełącza aktywnego dostawcę na Anthropic. Gdy taka zmiana dostawcy się nie powiedzie, login kończy działanie z błędem i kodem 1, zanim sesja w ogóle wystartuje. Wykonanie polecenia czyści zaś wszystkie zmienne środowiskowe nadpisujące dostawcę i kieruje ANTHROPIC_BASE_URL na proxy Speedwave, więc nieaktualne ustawienie lokalnego dostawcy nie przecieknie do logowania.

speedwave logout usuwa pliki z danymi logowania Claude, .claude/.credentials.json oraz .claude.json, z katalogu claude-home projektu. Uruchomione środowisko nie jest do tego potrzebne, polecenie można bezpiecznie wywołać dwukrotnie, a gdy nie ma czego usuwać, wypisuje No Claude credentials found. logout czyści wyłącznie logowanie do Claude. Aby usunąć zapisane dane uwierzytelniające i konfigurację wtyczki, sięgnij po Desktop, bo to on odpowiada za takie porządki. Zobacz Korzystanie z wtyczek.

Sprawdź wymagania wstępne i bezpieczeństwo

speedwave check uruchamia sprawdzenia wymagań systemu operacyjnego oraz kontrolę bezpieczeństwa pliku compose, wypisuje dla każdej reguły wiersz OK albo FAIL i kończy działanie z kodem 0, gdy wszystko przejdzie, albo 1, gdy coś zawiedzie. Ma charakter wyłącznie diagnostyczny i nie uruchamia kontenerów: zgłasza problemy z uprawnieniami, ale ich nie usuwa. Aby poznać dokładny zakres kontroli bezpieczeństwa, zajrzyj do SecurityCheck i jego reguł.

Uwaga

Przed uruchomieniem większości poleceń CLI weryfikuje podpisy zainstalowanych wtyczek. Jeśli któraś z wtyczek przestała odpowiadać temu, co zostało podpisane, polecenie wypisuje listę takich wtyczek na standardowe wyjście błędów i kończy działanie z kodem 2, zanim zrobi cokolwiek innego. Naprawisz to poleceniem speedwave plugin remove <slug>, które celowo pomija tę weryfikację. Weryfikacja omija także --help, self-update, init, plugin install oraz plugin list.

Zaktualizuj kontenery

speedwave update przebudowuje te wbudowane obrazy, których dane wejściowe się zmieniły, i tworzy kontenery od nowa. Po pomyślnym zakończeniu wypisuje Updated N containers (M images rebuilt).

Zanim aktualizacja się rozpocznie, Speedwave zapisuje w ~/.speedwave/snapshots/<project>/snapshot.json migawkę z plikiem compose i manifestami włączonych wtyczek sprzed aktualizacji. Jeśli aktualizacja zawiedzie już po usunięciu kontenerów, Speedwave przywraca tę migawkę i wypisuje Rolled back to the previous container state. Gdy nie powiedzie się także samo przywracanie, Speedwave prosi cię, byś ręcznie uruchomił kontenery poleceniem speedwave.

Zaktualizuj CLI

speedwave self-update pobiera najnowszy plik binarny speedwave z GitHub Releases i zastępuje nim ten, którego właśnie używasz. Kiedy zmienia się wersja, przebudowuje następnie obrazy twoich kontenerów, wypisując Rebuilding container images..., a potem Container images rebuilt successfully.

Jeśli uruchomisz self-update z wnętrza paczki .app aplikacji Desktop, polecenie odmówi wykonania i poprosi cię o aktualizację przez Desktop, co utrzymuje zgodność wersji CLI i Desktop.

Niezależnie od tego pozostałe polecenia CLI również sprawdzają w tle, najwyżej raz na dobę, czy jest dostępne nowsze wydanie, i zapisują wynik w pamięci podręcznej w <data-dir>/update-check.json. Gdy pojawia się nowsza wersja, polecenie wypisuje na standardowe wyjście błędów Update available: speedwave <cur> -> <new>. Run: speedwave self-update, nie blokując ani nie opóźniając uruchomionego polecenia. To sprawdzenie pomijane jest dla --help, dla samego self-update oraz zawsze wtedy, gdy uruchamiasz polecenie z wnętrza paczki .app, bo użytkownicy Desktop aktualizują się przez aplikację.

Zarządzaj wtyczkami

speedwave plugin install ./acme-plugin.zip
speedwave plugin list
speedwave plugin remove <slug>
speedwave plugin enable <service_id> --project acme
speedwave plugin disable <service_id> --project acme

install weryfikuje podpis Ed25519 wtyczki, rozpakowuje ją i rejestruje, wypisując Plugin '<name>' (<slug>) installed successfully. Jeśli budowanie obrazu zostało odłożone, polecenie wypisuje na standardowe wyjście błędów informację, że budowa ponowi się przy kolejnym uruchomieniu, ale mimo to kończy działanie z kodem 0. list wypisuje każdą wtyczkę w postaci <name> (<slug>): <version> z dopiskiem [verified] albo [UNVERIFIED: <reason>], bądź komunikat No plugins installed, i pomija weryfikację podpisów przy starcie. remove wypisuje Plugin '<slug>' removed i jest poleceniem naprawczym dla wtyczki, która nie przechodzi weryfikacji. Oba polecenia, enable i disable, wymagają flagi --project <nazwa>: enable żąda zweryfikowanej wtyczki i odrzuca niezweryfikowaną, disable zaś weryfikacji nie wymaga, więc uszkodzoną wtyczkę zawsze zdołasz wyłączyć.