Claude Code Unhandled case object Object – to dokładnie ten komunikat, który w czwartek 14 maja 2026 rano część deweloperów zobaczyła na czerwonym banerze po uruchomieniu nowej wersji rozszerzenia w VS Code. Sesja startowała normalnie, model zaczynał odpowiadać, po czym wszystko się sypało. W technicznym zapisie banner brzmi Unhandled case: [object Object]. Sesja przerywała się mniej więcej w połowie odpowiedzi. Logi pokazywały Stream started, potem stream_idle_partial, na końcu sdk_stream_ended_no_result z had_error: true. Wszystko wyglądało jak awaria całej sesji. Najbardziej zaskakujący szczegół? Odpowiedź modelu czasem była w pełni zapisana w pliku transkryptu JSONL, mimo że okno webview niczego nie pokazało. Podobne sygnały pojawiły się też w społeczności użytkowników, jednak główne źródło techniczne to GitHub issue #58989 ze szczegółowymi logami i etykietą regression. Wspólny mianownik to świeża wersja Claude Code 2.1.141, która zaczęła trafiać na komputery przez auto-update. Najszybsza odpowiedź to rollback do 2.1.140 przez okno Extensions w VS Code.
Jak rozpoznać błąd Claude Code Unhandled case object Object
Najpierw lista, której warto się trzymać przy diagnostyce. Komunikat Claude Code Unhandled case object Object to objaw, nie przyczyna. Pod nim siedzi konkretny wzorzec, który warto rozpoznać:
- czerwony banner
Unhandled case: [object Object]w oknie Claude Code, - odpowiedź zaczyna się generować, po czym znika z widoku,
- w logach Claude Code pojawia się
Stream started, następniestream_idle_partialiStreaming stall detected, - końcowy wpis
sdk_stream_ended_no_resultzhad_error: true, - czasem treść odpowiedzi i tak jest w pliku
.jsonlz sesji, pomimo pustego UI.
Co więcej, banner pojawia się przy dowolnym promptcie – nie tylko przy konkretnym zadaniu. To również podpowiedź diagnostyczna. Jeśli widzisz ten zestaw u siebie, problem prawdopodobnie nie siedzi w twoim kodzie ani w konkretnym narzędziu MCP, tylko w samym rozszerzeniu.


Co o tym mówi GitHub issue #58989
Issue otwarto 14 maja 2026 z etykietami regression, bug, area:api oraz platform:vscode. Autor opisał ten sam wzorzec – długie sesje wpadające w streaming stalls, slow first byte około 30 sekund, stall około 50 sekund i wreszcie sdk_stream_ended_no_result. Ponadto wskazał wersję 2.1.140 jako ostatnią działającą i potwierdził, że powrót do niej rozwiązał problem, a zbuforowana odpowiedź pokazała się dopiero po rollbacku. Issue ma też etykietę platform:linux, więc regresja nie dotyczy wyłącznie Windowsa. W społeczności użytkowników Claude Code pojawiły się też sygnały o identycznym brzmieniu objawu, jednak traktujemy je jako sygnał społecznościowy, a nie oficjalne potwierdzenie. Solidne źródło to issue na GitHubie – tam pierwsza pojawi się informacja o naprawie.
Awaria zaczyna się od strony narzędzia. Stream zerwany w VS Code nie znaczy, że Claude przestał odpowiadać po stronie API.
Co widzieliśmy u siebie – case study
Lokalna wersja awarii pojawiła się rano. Katalog rozszerzenia anthropic.claude-code-2.1.141-win32-x64 powstał o godzinie 8:31. To była zatem typowa cicha aktualizacja, którą rozszerzenie pobrało z kanału latest ustawionego globalnie. Pierwszy raz objaw pojawił się natomiast w projekcie SEO. W tej samej sesji równolegle leciał timeout do jednego z serwerów MCP, dlatego trop poszedł najpierw w stronę warstwy MCP. Wyłączenie tego serwera chwilowo pomogło. Mimo to identyczny banner wrócił później w projekcie Marketing, w którym żaden taki serwer nie był podpięty. W rezultacie warstwa MCP zniknęła z listy podejrzanych. Winowajcą okazała się sama wersja Claude Code, a timeout MCP był osobnym, równolegle występującym zakłóceniem.
Następna obserwacja była jednak najciekawsza. Mimo że banner Claude Code Unhandled case object Object wyglądał na pełną awarię sesji, w projekcie Marketing po awarii zajrzeliśmy do najnowszego pliku .jsonl w katalogu transkryptów Claude Code. Okazało się, że odpowiedź modelu była tam w całości, z stop_reason: end_turn i około czterema tysiącami tokenów wygenerowanej treści. UI po prostu jej nie wyrenderował. To jak rozmowa telefoniczna, w której druga osoba skończyła zdanie, ale aplikacja nie odświeżyła ekranu z transkrypcją – sygnał doszedł, tylko obraz utknął. W efekcie wnioskowanie po stronie API się skończyło, natomiast webview Claude Code zgubił ostatni kawałek transmisji. To zmienia ton zalecenia. Jeśli widzisz banner, nie zakładaj automatycznie, że praca przepadła – zacznij od sprawdzenia transkryptu.
Rollback do 2.1.140 – szybka procedura
Najpewniejsza ścieżka idzie przez wbudowane okno Extensions w VS Code, bez pobierania VSIX-a z Marketplace. Krok po kroku:
- Otwórz VS Code, przejdź do panelu Extensions po lewej stronie.
- Znajdź pozycję Claude Code na liście zainstalowanych rozszerzeń.
- Kliknij zębatkę przy rozszerzeniu i wybierz
Install Another Version.... - Z listy wskaż wersję
2.1.140. - Uruchom polecenie
Developer: Reload Windowalbo zrestartuj edytor.
Po reloadzie Claude Code wystartuje na wersji 2.1.140. W naszym przypadku stream zaczął kończyć się normalnie, dodatkowo buforowane odpowiedzi z poprzedniej sesji wreszcie się pojawiły. Procedura zadziałała u nas, a ponadto autor issue #58989 potwierdza ten sam efekt – dlatego to obecnie najbezpieczniejszy workaround.
Tymczasowe wyłączenie auto-update rozszerzeń
Na czas regresji warto zatrzymać auto-aktualizacje rozszerzeń VS Code. W settings.json ustaw:
"extensions.autoUpdate": falseUwaga – to dotyczy wszystkich rozszerzeń, nie tylko Claude Code. Jak tylko Anthropic wypuści naprawiony build, wróć do poprzedniej wartości, żeby nie blokować aktualizacji innych narzędzi.
Drugim krokiem warto zmienić kanał aktualizacji samego Claude Code w jego globalnym settings.json:
"autoUpdatesChannel": "stable"To nie cofa zainstalowanej wersji, ponieważ działa tylko od następnego update’u, jednak zmniejsza ryzyko, że kolejny zepsuty build trafi z kanału latest.
Pułapka VSIX na Windowsie
Jeśli z jakiegoś powodu rollback przez Extensions nie zadziała, zostaje platformowy VSIX. Tutaj kluczowa uwaga – generyczny VSIX bez parametru platformy nie zawiera binarki dla win32-x64. Próba instalacji kończy się komunikatem:
Unsupported platform: win32-x64. No compatible Claude Code binary found.Potrzebny jest pakiet z parametrem ?targetPlatform=win32-x64. Po poprawnej instalacji binarka leży w C:\Users\<user>\.vscode\extensions\anthropic.claude-code-2.1.140\resources\native-binary\claude.exe. Weryfikacja przez PowerShell:
& "C:\Users\<user>\.vscode\extensions\anthropic.claude-code-2.1.140\resources\native-binary\claude.exe" --versionWynik powinien brzmieć 2.1.140 (Claude Code). Jeśli natomiast widzisz inny numer albo błąd, instalacja poszła z niewłaściwego pliku VSIX.
Drobna pułapka: UTF-8 BOM w settings.json
Po edycji settings.json z poziomu PowerShell pojawiła się jeszcze jedna pułapka. Set-Content -Encoding UTF8 w starszym Windows PowerShell potrafi dorzucić BOM-a na początku pliku. Wtedy nawet poprawnie zrolbackowany Claude Code 2.1.140 wita komunikatem:
Failed to parse settings.json: SyntaxError: Unexpected token ''Lekarstwo to zapis pliku w UTF-8 bez BOM-a. Działający fragment:
$path='C:\Users\<user>\.claude\settings.json'
$text = Get-Content -LiteralPath $path -Raw
$utf8NoBom = New-Object System.Text.UTF8Encoding($false)
[System.IO.File]::WriteAllText($path, $text, $utf8NoBom)To detal, jednak potrafi zablokować start narzędzia mimo poprawnego rollbacku. Warto mieć go pod ręką przy diagnostyce.
Jak sprawdzić, czy odpowiedź nie przepadła
Claude Code zapisuje każdą sesję w plikach JSONL na lokalnym dysku. Lokalizacja na Windowsie:
C:\Users\<user>\.claude\projects\Wewnątrz znajdziesz osobny katalog dla każdego projektu (na przykład d--Claude-Code-SEO albo d--Claude-Code-Marketing). Każdy plik .jsonl to chronologiczny zapis jednej sesji. Po awarii streamu otwórz najnowszy plik i poszukaj wpisu "type":"assistant" z "stop_reason":"end_turn". Jeśli go znajdziesz, model dokończył odpowiedź po stronie API – tylko interfejs jej nie pokazał. Pole text zawiera natomiast treść, którą można skopiować z powrotem do prompta albo wkleić do pliku, nad którym pracowałeś.
Ważna uwaga: tylko czytaj te pliki, nie modyfikuj ich ręcznie. To wewnętrzny stan Claude Code i każda zmiana może popsuć przyszłe sesje. Ten katalog jest natomiast cennym zasobem dla każdego, kto pracuje z narzędziem produkcyjnie. W razie regresji UI masz lokalną kopię tego, co model faktycznie odpowiedział.
Jeden plik JSONL ratuje pracę, której webview nie pokazał. Warto wiedzieć, gdzie szukać, zanim się go potrzebuje.
Kiedy nie panikować i co dalej
Pierwszy odruch na komunikat Claude Code Unhandled case object Object brzmi “Claude skasował mi pracę”. W tym przypadku to nieprawda. Mowa o regresji UI i streamu, a nie o zniszczeniu danych. Przypomina to przerwany podgląd transmisji, a nie skasowane nagranie – obraz znika z ekranu, plik wciąż leży na dysku. Pliki w żadnym projekcie nie zostały u nas dotknięte. Co więcej, sesja agentowa, która zaczynała kompozycję planu, dawała się odtworzyć z transkryptu. Czy to znaczy, że trzeba od razu restartować całe środowisko? Nie – najpierw sprawdź transkrypt, dopiero potem decyduj o rollbacku. Dlatego zachowaj spokój – to znacznie bardziej “stream urwany” niż “Claude usunął pracę”.
Co dalej? Obserwuj GitHub issue #58989 – tam pierwsza pojawi się informacja o naprawie i numer nowego buildu. Trzymaj kanał stable zamiast latest przez najbliższe dni. Jeśli pracujesz nad ważnym zadaniem, commituj częściej i staraj się rozbijać prompty na krótsze kroki, dopóki nie wróci nowsza wersja narzędzia. Podobny mechanizm widzieliśmy zresztą przy zmianach w Claude Code Agent View – nowe funkcje przychodzą bezgłośnie, więc warto śledzić changelog. Z kolei Claude Platform na AWS pokazuje, że ekosystem Anthropic szybko się rozrasta – tym istotniejsza staje się ścieżka awaryjna przy każdym kanale dystrybucji.
Kurs n8n 2.0 · Kodożercy
n8n + AI = automatyzacje, które naprawdę myślą
n8n pozwala podłączyć modele AI do swoich workflow – wysyłać dane do ChatGPT, analizować wyniki, reagować automatycznie. Kurs n8n 2.0 na Kodożercach pokaże Ci jak to połączyć.
Sprawdź jak to działa →

Podsumowanie
Claude Code Unhandled case object Object to objaw regresji w wersji 2.1.141, która urywa stream odpowiedzi i pokazuje czerwony banner w VS Code. Problem siedzi po stronie wersji rozszerzenia VS Code, a nie w API ani konkretnym projekcie czy serwerze MCP. Workaround jest prosty – powrót do 2.1.140 przez okno Extensions w VS Code. Jeśli UI nie pokazał odpowiedzi, zajrzyj do plików .jsonl w C:\Users\<user>\.claude\projects\ – zapis sesji często zawiera całość treści. Czekaj na komentarz Anthropic w issue #58989 i trzymaj kanał stable przez kolejne dni, dopóki nie pojawi się naprawiony build.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.



