# Ścieżki tokenów i danych uwierzytelniających Wszystkie dane uwierzytelniające, które przechowuje Speedwave, trafiają do jednego katalogu danych, domyślnie `~/.speedwave/`. Ustaw zmienną środowiskową `SPEEDWAVE_DATA_DIR`, żeby przenieść go gdzie indziej: wszystkie ścieżki poniżej rozwiną się wtedy w wybranej przez ciebie lokalizacji. Speedwave odczytuje tę zmienną raz na proces, więc jej zmiana wymaga restartu. Pełną listę zmiennych, które Speedwave odczytuje przy starcie, znajdziesz w [zmiennych środowiskowych](/pl/docs/reference/env-vars/), a zasady bezpieczeństwa, dzięki którym jedna usługa nie odczyta plików innej, opisuje strona o [obsłudze danych uwierzytelniających](/pl/docs/security/credentials/). ## Struktura katalogów - ~/.speedwave/ - tokens/ - **<project>**/ - **<service>**/ dane uwierzytelniające workera dla danej usługi - … pliki uwierzytelniające - llm/ - **<provider_id>**\_api_key klucz API dostawcy LLM - claude-home/ - **<project>**/ - .claude/ - .credentials.json OAuth Anthropic (zarządzane przez Claude Code) - oauth/ - **<project>**/ - **<service>**.json tokeny odświeżające OAuth wtyczki (poza punktem montowania) - plugin-state/ - **<slug>**/ - bridge-token zapisany token mostka do hosta - ide-bridge/ - **<port>**.lock token UUID IDE Bridge `` to przestrzeń nazw przypisana danemu projektowi. `` to identyfikator usługi MCP: albo wbudowanego workera, albo wtyczki. `` to identyfikator dostawcy LLM z `claude.llm`. `` to identyfikator wtyczki, a `` to port IDE Bridge. ## Ścieżki w skrócie | Ścieżka | Zawiera | Punkt montowania | Tryb | | --- | --- | --- | --- | | `tokens///` | Dane uwierzytelniające jednej usługi MCP | Tylko worker tej usługi, pod `/tokens` (tylko do odczytu) | plik `0o600`, katalog `0o700` | | `tokens//llm/_api_key` | Klucz API jednego dostawcy LLM | Tylko kontener `proxy`, pod `/tokens` (tylko do odczytu), jako zmienna środowiskowa `SPW_KEY_` | plik `0o600`, katalog `0o700` | | `claude-home//.claude/.credentials.json` | Dane uwierzytelniające OAuth Anthropic | `${CLAUDE_HOME}` pod `/home/speedwave` (odczyt i zapis) | zarządzane przez Claude Code | | `oauth//.json` | Tokeny odświeżające OAuth wtyczki i sekrety klienta | Bez punktu montowania; odczytuje je worker `oauth` po stronie hosta | plik `0o600`, katalog `0o700` | | `plugin-state//bridge-token` | Zapisany token uwierzytelniający mostka do hosta | Bez punktu montowania | plik `0o600`, gdy istnieje | | `ide-bridge/.lock` | Token uwierzytelniający UUID v4 dla IDE Bridge | `/home/speedwave/.claude/ide/` (tylko do odczytu) | plik `0o600`, katalog `0o700` | ## Tokeny workerów dla poszczególnych usług Każda usługa MCP, która przechowuje dane uwierzytelniające, dostaje własny katalog, `tokens///`, z plikami zadeklarowanymi przez tę usługę. Speedwave zakłada go tylko dla usług, których lista plików uwierzytelniających nie jest pusta. [Ten jeden katalog jest montowany tylko do odczytu w odpowiadającym mu workerze](/pl/docs/under-the-hood/workers/), pod `/tokens`, a reguła SecurityCheck o nazwie `PLUGIN_TOKEN_PATH_MISMATCH` sprawdza jeszcze przed startem kontenera, czy zamontowana ścieżka faktycznie odpowiada `tokens///`. Dzięki temu przejęty worker ujawnia wyłącznie dane uwierzytelniające własnej usługi. ## Klucze dostawców LLM Klucz dostawcy LLM skonfigurowany w `claude.llm` ląduje w `tokens//llm/_api_key`, gdzie nazwa pliku to identyfikator dostawcy z dopiskiem `_api_key`. Katalog `llm` montuje się tylko do odczytu wyłącznie w kontenerze `proxy`, a każdy klucz trafia tam jako zmienna środowiskowa o nazwie `SPW_KEY_`, czyli identyfikator dostawcy zapisany wielkimi literami, z myślnikami zamienionymi na podkreślenia: ```text title="Przykłady nazw SPW_KEY i ścieżek" openrouter -> SPW_KEY_OPENROUTER my-anthropic -> SPW_KEY_MY_ANTHROPIC tokens/proj/llm/openrouter_api_key ``` **Caution:** Klucze dostawców LLM nigdy nie docierają do kontenera `claude`: reguła SecurityCheck `PROXY_VOLUMES` ogranicza punkty montowania kontenera `proxy` do `config:ro`, `tokens//llm:/tokens:ro` i `usage:rw`, bez żadnych innych woluminów i bez `network_mode`. Jedyny wyjątek to klucz API Anthropic, który zostaje w zmiennych środowiskowych kontenera `claude`, bo Claude Code przekazuje go dalej bezpośrednio. ## Dane uwierzytelniające OAuth Anthropic Dane uwierzytelniające OAuth Anthropic znajdują się pod `claude-home//.claude/.credentials.json`, gdzie zapisuje je i odświeża Claude Code, wewnątrz montowania typu bind `${CLAUDE_HOME}` pod `/home/speedwave`. Rola Speedwave sprowadza się tu do wskazania tego pliku dla montowania w compose oraz wyczyszczenia go po `speedwave logout`. ## Tokeny odświeżające OAuth wtyczek Tokeny odświeżające OAuth wtyczek oraz sekrety klienta nigdy nie trafiają pod `tokens/`. Zamiast tego lądują poza punktem montowania, w `oauth//.json`, dzięki czemu wszystko pod `tokens/` pozostaje tylko do odczytu, gdziekolwiek jest zamontowane. Nazwą pliku jest identyfikator usługi, więc wbudowana usługa OAuth, na przykład `sharepoint`, zapisuje plik `sharepoint.json`. ## Stan wtyczki i token mostka Zmienny stan poszczególnych wtyczek znajduje się pod `plugin-state//`, w oderwaniu od podpisanych plików samej wtyczki. Przykładem jest zapisany token uwierzytelniający mostka do hosta, `plugin-state//bridge-token`. Mostek hosta w Desktop zapisuje go z uprawnieniami `0o600` i tylko wtedy, gdy manifest wtyczki włącza opcję `persistent_token`. ## Plik blokady IDE Bridge [Plik blokady IDE Bridge](/pl/docs/features/ide-bridge/), `ide-bridge/.lock`, zawiera token uwierzytelniający UUID v4, który Desktop generuje od nowa przy każdym starcie i nigdy nie zachowuje między restartami. Zapisuje się go z uprawnieniami `0o600` wewnątrz katalogu nadrzędnego `0o700` i montuje do kontenera tylko do odczytu, pod `/home/speedwave/.claude/ide/`. ## Uprawnienia plików Speedwave ustawia każdy plik uwierzytelniający na tryb `0o600`, a jego katalog nadrzędny na `0o700`, których właścicielem jest twoje konto użytkownika. W Windows odpowiednikiem jest DACL z jednym wpisem pełnej kontroli dla twojego konta, nadawana w chwili tworzenia pliku lub katalogu. W systemach uniksowych Speedwave dodatkowo sprawdza te uprawnienia przy starcie i sam poprawia błędne bity; nie naprawi jednak niezgodnego właściciela, bo to wymaga uprawnień roota. Windows nie ma odpowiednika takiego sprawdzenia przy starcie: DACL nadaje się raz, w chwili tworzenia, i nigdy później nie jest ona ponownie weryfikowana ani naprawiana.