# Logi i diagnostyka

Strona `/logs` (**System health** w aplikacji) scala logi kontenerów oraz usług działających po stronie hosta w jeden strumień. Nad nim znajdziesz pasek stanu zdrowia, a same szczegóły możesz spakować do zgłoszenia błędu.

Wiesz już, na czym polega problem? Zacznij od [Rozwiązywania problemów](/pl/docs/guides/troubleshooting/). Tutaj przychodzisz po surowe logi albo po paczkę do załączenia.

## Sprawdź pasek stanu systemu

1. Otwórz `/logs`. Pasek stanu pokazuje status ogólny (`healthy` albo `degraded`), a obok niego kolorową kropkę oraz etykietę dla `vm`, `containers`, `ide_bridge` i `mcp_os`.
2. Kliknij status ogólny, aby rozwinąć wiersz ze szczegółami: nazwę i status każdego kontenera, a także edytory IDE wykryte przez Speedwave wraz z ich portami.
3. Jeśli Speedwave wykrył IDE, którego jeszcze nie wybrałeś, w komórce `ide_bridge` pojawi się link **connect →** prowadzący do Integracji. O tym, do czego służy ten mostek, przeczytasz w [IDE Bridge](/pl/docs/features/ide-bridge/).
4. Kliknij **refresh**, aby wymusić odświeżenie pomiędzy automatycznymi cyklami co 5 sekund.

<DesktopFrame screen="logs" />

## Czytaj strumień logów

1. Pod paskiem widok logów na żywo śledzi scalony strumień, domyślnie ostatnie 500 linii. Odświeża się co 5 sekund i pozostaje przy dolnej krawędzi, dopóki nie przewiniesz go wyżej.
2. Zawęź to, co widzisz, za pomocą **znaczników poziomu** (`all`, `debug`, `info`, `warn`, `error`).
3. Aby wyodrębnić jedno źródło, skorzystaj z **rozwijanej listy źródeł**. Przy każdym z nich widnieje liczba jego linii.
4. Najedź na znacznik czasu, aby zobaczyć jego surową wartość. Wyświetlana godzina odpowiada twojej lokalnej strefie czasowej.

Speedwave zapisuje logi na poziomie trace i nie da się tego przełączyć, dzięki czemu eksport diagnostyczny niesie zawsze najpełniejszy kontekst, a ty nigdy nie musisz odtwarzać problemu z większą szczegółowością. Kilka gadatliwych bibliotek zewnętrznych ograniczono do poziomu warn, aby strumień pozostał czytelny.

W wersji Desktop logi te są też zapisywane na dysku: `~/Library/Logs/pl.speedwave.desktop` na macOS oraz `%LOCALAPPDATA%/pl.speedwave.desktop/logs` na Windows. Pliki są rotowane po osiągnięciu 50 MB, przy czym zachowuje się ostatnie 10 segmentów.

### Logi debugowania HTTP zostają skondensowane

Ustaw `ANTHROPIC_LOG=debug`, aby podejrzeć surowy ruch SDK Claude Code. Zamiast wypisywać surowy, wielowierszowy wynik, Speedwave zwinie każde rozwlekłe żądanie lub odpowiedź do jedno- albo dwuwierszowego podsumowania oznaczonego znacznikiem `[log_ID]`:

```
-> POST /v1/messages (model=claude-opus-4, max_tokens=4096, stream=true, messages=12) [a1b2c3]
<- 200 /v1/messages (content-type=text/event-stream, from api.anthropic.com, in 842ms) [a1b2c3]
```

SDK emituje każdą odpowiedź w trzech fragmentach, a Speedwave scala je w ten jeden wiersz. Wszystko, czego nie rozpozna, przechodzi dalej bez zmian.

## Wyeksportuj paczkę diagnostyczną

Przycisk **export diagnostics** pakuje logi aplikacji, logi kontenerów oraz informacje o systemie w oczyszczone archiwum ZIP, bez żadnych tokenów i sekretów. Jest nieaktywny w trakcie eksportu oraz wtedy, gdy nie masz otwartego żadnego projektu.

1. Na stronie `/logs` kliknij **export diagnostics**. Na czas budowania archiwum etykieta przycisku zmienia się na "exporting…".
2. Po udanym eksporcie pojawia się okno zatytułowane **Diagnostics archive saved** ze ścieżką do pliku ZIP.
3. Kliknij **copy path**, aby skopiować ścieżkę, a następnie **close**.
4. Udostępnij paczkę samodzielnie, przekaż ją wsparciu technicznemu albo załącz do swojego zgłoszenia błędu. Nic nie wysyła się automatycznie.

Plik ZIP trafia do twojego katalogu Downloads (a gdy Speedwave go nie znajdzie, do katalogu domowego), pod nazwą `speedwave-diagnostics-<unix-timestamp>.zip`.
**Załączasz ją samodzielnie:** Speedwave zapisuje plik i pokazuje ci ścieżkę do niego. Nie otwiera menedżera plików, nie wysyła paczki ani nie załącza jej za ciebie.

### Co zawiera paczka

- speedwave-diagnostics-&lt;timestamp&gt;.zip
  - logs/
    - **\*.log** pliki logów aplikacji
  - containers/
    - compose.log logi kontenerów i compose
    - compose.yml plik compose projektu
  - mcp-os/
    - mcp-os.log jeśli istnieje
  - claude/
    - claude-session.log jeśli istnieje
  - lima/
    - serial.log log konsoli szeregowej Limy, tylko macOS
  - system-info.txt system operacyjny, architektura, wersja aplikacji, `claude_pinned` (przypięta wersja Claude Code)
Źródła jednoplikowe (log mcp-os, log sesji Claude, `serial.log` z Limy tylko macOS) pojawiają się wyłącznie wtedy, gdy istnieją.

Zanim Speedwave zapisze ZIP, jego mechanizm oczyszczania logów zastępuje wszystko, co wrażliwe, napisem `***REDACTED***`:

| Kategoria | Przykłady |
|---|---|
| Klucze API | Anthropic (`sk-ant-...`), Google (`AIza...`), ogólne `sk-*` |
| Tokeny hostingu Git | GitHub (`ghp_`, `ghs_`, `gho_`, `ghu_`, `github_pat_`), GitLab (`glpat-`), Atlassian Cloud |
| Tokeny czatu | Slack (`xoxb`, `xoxp`, `xoxa`, `xoxr`, `xoxs`, `xoxe`) |
| Dane uwierzytelniające | nagłówki `Authorization`/`Bearer`, `Set-Cookie`/`Cookie`, JWT-y, dane uwierzytelniające w userinfo URL |
| Inne | klucze prywatne PEM, nazwy użytkowników z katalogu domowego, parametry `password`/`secret`/`api_key`/`token`, `X-Redmine-API-Key`, nagłówki eksportera OTEL |

Dane awarii, których mechanizm oczyszczania nie potrafi odczytać jako tekst, zwijają się do `unknown panic payload`, zamiast ryzykować ich wyciek. Katalog z tokenami nigdy nie trafia do archiwum. Wyjątkiem jest `system-info.txt`, zapisywany bez zmian, z systemem operacyjnym, architekturą, wersją aplikacji oraz przypiętą wersją Claude Code.

W razie niezgodności wersji sprawdź najpierw `claude_pinned` w `system-info.txt`. Speedwave sam przypina tę wersję, więc rozbieżność zwykle oznacza, że twój kontener `claude` wymaga przebudowy. Jak to naprawić, opisano w [Rozwiązywaniu problemów](/pl/docs/guides/troubleshooting/).