Tag: Cline

  • Cline v4.0.9 wprowadza modele GPT-5.6 i naprawia zawyżone raportowanie tokenów

    Cline v4.0.9 wprowadza modele GPT-5.6 i naprawia zawyżone raportowanie tokenów

    17 lipca 2026 roku ukazała się wersja Cline v4.0.9 — aktualizacja, która koncentruje się na trzech obszarach: dostępie do nowych modeli, dokładniejszym rozliczaniu użycia tokenów i drobnych poprawkach interfejsu. To wydanie nie wprowadza rewolucyjnych zmian, lecz rozwiązuje konkretne problemy zgłaszane przez użytkowników korzystających z subskrypcji ChatGPT i dostawców zgodnych z API OpenAI.

    Kluczowe zmiany w Cline v4.0.9

    • Modele z rodziny GPT-5.6 dostępne dla użytkowników z subskrypcją ChatGPT — Cline dodaje modele GPT-5.6 w integracji opartej na subskrypcji, co poszerza wybór bez konieczności użycia klucza API.
    • Dokładniejsze raportowanie tokenów — poprawiono logikę rozliczania dla dostawców, eliminując wielokrotne zliczanie tych samych tokenów.
    • Złagodzony komunikat o błędach — skrócono i złagodzono ostrzeżenie wyświetlane po osiągnięciu limitu kolejnych pomyłek, aby nie dezorientowało użytkownika.
    • Obsługa plików UTF-8 ze znacznikiem BOM — Cline potrafi teraz wczytywać pliki skills zapisane z bajtowym znacznikiem kolejności, co zwiększa kompatybilność z różnymi edytorami.

    Modele GPT-5.6 przez subskrypcję, nie przez API

    Zmiana w dostępie do modeli z rodziny GPT-5.6 jest istotna, ponieważ dotyczy praktycznego korzystania z agentów kodujących. Nie wszyscy programiści łączą się z modelami przez tradycyjny klucz API — część korzysta z subskrypcji ChatGPT jako wygodniejszej metody autoryzacji. Cline v4.0.9 dodaje odpowiednie modele dla tej grupy, co sprawia, że wybrane modele GPT-5.6 stają się widoczne i dostępne wewnątrz narzędzia bez dodatkowej konfiguracji.

    To posunięcie wpisuje się w szerszy trend, w którym agent kodujący musi obsługiwać różne modele oraz metody uwierzytelniania. Dla użytkownika końcowego ważne jest, czy model działa po zalogowaniu — szczegóły techniczne pozostają w tle.

    Dlaczego poprawka raportowania tokenów ma znaczenie

    Problem z zawyżonym użyciem tokenów dotyczył użytkowników korzystających z dostawców zgodnych z API OpenAI, takich jak bramki, samo-hostowane endpointy czy serwisy imitujące interfejs OpenAI. Niektóre z tych serwisów zwracają skumulowaną sumę tokenów zamiast przyrostu na żądanie. Gdy klient traktuje każdą odpowiedź jako nowy przyrost, te same tokeny są liczone wielokrotnie.

    W praktyce prowadziło to do zawyżonych szacunków kosztów i błędnych informacji o wykorzystaniu budżetu kontekstu. Dla agenta kodującego, który w ramach jednego zadania wykonuje dziesiątki wywołań modelu, nawet niewielki błąd w księgowości tokenów może prowadzić do znaczących rozbieżności. Poprawka w v4.0.9 pozwala Cline odróżniać sumy skumulowane od wartości przyrostowych, co sprawia, że dane o użyciu stają się znacznie bardziej dokładne.

    Drobne, ale odczuwalne poprawki UX

    Przy limicie kolejnych pomyłek Cline wcześniej wyświetlał komunikat, który niepotrzebnie alarmował użytkownika. Wersja 4.0.9 skraca tę wiadomość i nadaje jej spokojniejszy ton — zamiast sprawiać wrażenie awarii, informuje zwięźle o stanie, w jakim znalazł się agent. To drobiazg, ale w codziennej pracy z narzędziem takie szorstkości mogą być irytujące.

    Obsługa UTF-8 z BOM to kolejny krok w stronę kompatybilności. Niektóre edytory i narzędzia wstawiają bajtowy znacznik kolejności na początku plików tekstowych. Gdy Cline próbował wczytać taki plik jako skill, napotykał problem. Po aktualizacji pliki z BOM są interpretowane bez przeszkód.

    Szerszy kontekst wydania

    Cline v4.0.9 wpisuje się w okres intensywnych aktualizacji w różnych obszarach rozwoju. Równolegle z wersjami v4.0.x dla VS Code i głównego produktu, zespół prowadzi osobne serie wydań CLI oraz SDK. To pokazuje, że Cline nie jest monolitem — różne ścieżki dystrybucji rozwijają się we własnym tempie, a poprawki takie jak v4.0.9 trafiają do głównego kanału produktowego.

    Cline v4.0.9 — mała aktualizacja o praktycznym wydźwięku

    Wydanie nie zawiera spektakularnych nowości, nie publikowano też benchmarków wydajności ani danych o oszczędnościach tokenów. Jego wartość leży w dostępie do wybranych modeli GPT-5.6 dla użytkowników subskrypcji ChatGPT, dokładniejszym rozliczaniu tokenów dla niektórych dostawców oraz bardziej przyjaznym interfejsie. Dla osób na co dzień pracujących z Cline to właśnie takie poprawki decydują o przewidywalności działania narzędzia.

    Źródła

  • Kimi Code CLI 1.49.0 wprowadza inteligentne zarządzanie oknem kontekstowym

    Kimi Code CLI 1.49.0 wprowadza inteligentne zarządzanie oknem kontekstowym

    16 lipca 2026 roku wydano wersję 1.49.0 terminalowego agenta Kimi Code CLI, która zmienia sposób, w jaki narzędzie zarządza tokenami dla odpowiedzi modelu i obsługuje zapytania thinkujące. Ta aktualizacja jest istotna dla zespołów, które często borykają się z błędami przepełnienia kontekstu podczas długich sesji programistycznych.

    Co nowego w pigułce

    • Dynamiczne budżetowanie tokenów – CLI szacuje dostępne miejsce w oknie kontekstowym zamiast stosować sztywny limit 32 000 tokenów.
    • Nowa zmienna środowiskowa KIMI_MODEL_MAX_COMPLETION_TOKENS pozwala na ręczne ograniczenie długości generowanych odpowiedzi.
    • Ujednolicona obsługa modeli thinkujących przez parametr thinking.type, eliminując potrzebę automatycznego dodawania starszego reasoning_effort.
    • Poprawka historii konwersacji zapobiega gubieniu pustych wpisów rozumowania z historii sesji.

    Dlaczego stały limit tokenów był problemem

    W poprzednich wersjach Kimi Code CLI każde zapytanie do API miało ustawiony limit max_tokens=32000. To mogło wydawać się rozsądne, ale podczas długich sesji agent gromadził wiele plików źródłowych, logów testów, wyników narzędzi i historii poprawek. W rezultacie okno kontekstowe stawało się zbyt małe, a stały limit odpowiedzi nie mógł się zmieścić w dostępnej przestrzeni, co prowadziło do błędów invalid-request i przerywania pracy.

    Wersja 1.49.0 rozwiązuje ten problem poprzez dynamiczne szacowanie pozostałego miejsca w oknie kontekstowym przed każdym zapytaniem. max_completion_tokens jest automatycznie dostosowywane, aby zmieścić się w dostępnej przestrzeni. Dla zespołów DevOps i web-developerów oznacza to mniej awarii w pipeline'ach CI, na hostingu i w środowiskach kontenerowych.

    Kontrola nad limitem – zmienna środowiskowa w akcji

    Nowa wersja wprowadza również KIMI_MODEL_MAX_COMPLETION_TOKENS jako maksymalny limit dla generowanych tokenów. Jest to szczególnie przydatne w konfiguracjach współdzielonych, takich jak kontenery Dockera, zadania CI i środowiska deweloperskie. Stara zmienna KIMI_MODEL_MAX_TOKENS nadal działa jako alias kompatybilności, więc istniejące konfiguracje nie wymagają natychmiastowych poprawek.

    Ustawienie którejkolwiek z tych zmiennych na 0 lub wartość ujemną całkowicie wyłącza mechanizm przycinania, a CLI działa wtedy zgodnie ze standardowym zachowaniem API.

    Thinking models: porządek zamiast chaosu

    Obsługa modeli thinkujących również została zaktualizowana. Wersja 1.49.0 standaryzuje konfigurację wokół parametru thinking.type i przestaje automatycznie dodawać starszy reasoning_effort przy korzystaniu z natywnej konfiguracji Kimi.

    To jest istotne, ponieważ integracje korzystające z dostawcy Kosong i starszych endpointów kompatybilnych z Kimi mogą wymagać aktualizacji. Jeśli backend wciąż oczekuje reasoning_effort, należy go jawnie przekazać przez opcje generowania. Standaryzacja jednego parametru zmniejsza niejasności w kontrakcie między CLI, adapterem dostawcy a endpointem modelu, ale starsze serwery proxy i backendy API mogą wymagać ręcznej migracji.

    Dodatkowo poprawiono błąd, przez który puste wpisy rozumowania były usuwane z historii konwersacji. Zachowanie struktury wiadomości z polem reasoningowym, nawet jeśli jest ono puste, utrzymuje spójną historię tur dla modeli thinkujących. To jest zgodne z szerszym zachowaniem Kimi: rozumowanie z poprzednich tur jest domyślnie zachowywane, chyba że użytkownik jawnie je wyłączy przez [thinking] keep = "off".

    Co to znaczy dla codziennej pracy

    Praktyczne konsekwencje dla programistów są znaczące. Dłuższe sesje autonomicznego kodowania, takie jak vibe coding, refaktoryzacja czy debugowanie, przestaną kończyć się błędami po kilkudziesięciu minutach. Agent może pracować z dużym kontekstem repozytorium, wynikami testów i historią zmian bez potrzeby ręcznego czyszczenia sesji.

    Wersja 1.49.0 to wydanie maintenance'owe w ramach linii CLI, która, jak wskazuje dokumentacja projektu, przechodzi na nowszy produkt Kimi Code. Starsze repozytorium Python CLI zostało już zarchiwizowane, a to wydanie należy traktować jako ważną łatkę stabilizacyjną przed szerszą migracją.

    Podsumowanie

    Kimi Code CLI 1.49.0 to przede wszystkim wydanie poprawiające niezawodność: dynamiczne budżetowanie tokenów rozwiązuje problem przepełnienia kontekstu, zmienna środowiskowa daje zespołom kontrolę nad limitami, a standaryzacja parametrów thinkujących porządkuje kontrakt API. Przy aktualizacji warto sprawdzić kompatybilność endpointów – jeśli integracja opiera się na reasoning_effort, należy to jawnie skonfigurować. Pozostałe funkcje działają od razu i są bardziej stabilne.

    Źródła

  • Claude Code 2.1.211: subagenty w stream-json i poważne poprawki bezpieczeństwa

    Claude Code 2.1.211: subagenty w stream-json i poważne poprawki bezpieczeństwa

    Anthropic wprowadziło 15 lipca 2026 roku wersję 2.1.211 Claude Code. Choć aktualizacja może wydawać się niewielka, zawiera istotne zmiany w interfejsie wiersza poleceń (CLI). Najważniejszą nowością jest możliwość przekazywania tekstu i procesów myślowych subagentów do wyjścia stream-json, co zwiększa możliwości monitorowania w pipeline'ach CI/CD. Dodatkowo, wprowadzono istotne poprawki bezpieczeństwa dotyczące podglądów uprawnień oraz kilka usprawnień stabilności, które będą przydatne dla użytkowników uruchamiających Claude Code w środowiskach równoległych.

    Kluczowe informacje o wydaniu

    • Nowa flaga --forward-subagent-text umożliwia podglądanie tekstu i myślenia subagentów w stream-json. Wcześniej dostępne były jedynie bloki tool_use i tool_result, a nowa flaga dodaje tekst oraz bloki thinking.
    • Neutralizacja znaków zero-width, bidirectional-override i wizualnie podobnych cudzysłowów w podglądach uprawnień zapobiega wizualnemu oszustwu.
    • Wzmocniona kontrola hooków — decyzja ask z PreToolUse nie jest już nadpisywana przez tryb automatycznego zatwierdzania dla nieizolowanych komend Bash.
    • Poprawki stabilności dla sesji w tle, równoległych credential stores i subagentów z nadpisanymi modelami.

    Subagenty w stream-json: co to zmienia w praktyce

    Dotychczas uruchomienie Claude Code w trybie print z flagą --output-format stream-json (np. -p --output-format stream-json) pokazywało domyślnie bloki tool_use i tool_result generowane przez subagentów, ale bez ich tekstu i bloków thinking. Tekst generowany przez subagentów, które Claude wykorzystuje do realizacji konkretnych podzadań, pozostawał niewidoczny. Wersja 2.1.211 wprowadza mechanizm opt-in, który to zmienia.

    Flaga --forward-subagent-text (lub zmienna środowiskowa CLAUDE_CODE_FORWARD_SUBAGENT_TEXT=1) sprawia, że tekst i myślenie subagentów trafiają do strumienia JSON razem z identyfikatorem parent_tool_use_id. Dzięki temu systemy zewnętrzne mogą odtworzyć pełną hierarchię aktywności agentowej, co narzędzie zleciło które podzadanie i co dokładnie się w nim wydarzyło. Pełna obsługa każdego poziomu zagnieżdżenia jest dostępna od wersji 2.1.211.

    Funkcja ta będzie szczególnie przydatna dla zespołów pracujących z CI/CD i niestandardowymi interfejsami. Umożliwia teraz streamowanie postępów subagentów do logów builda, wyświetlanie zagnieżdżonej aktywności w dashboardach oraz debugowanie pośrednich kroków agenta, co ułatwia identyfikację problemów. Co istotne, mechanizm jest domyślnie wyłączony, więc istniejące skrypty nie odczują żadnej zmiany w formacie wyjścia.

    Bezpieczeństwo: koniec z oszustwami wizualnymi w podglądach

    Drugim ważnym elementem tej aktualizacji jest wzmocnienie podglądów uprawnień. Problem dotyczył sytuacji, gdy Claude Code wysyłał prośbę o zatwierdzenie akcji przez integrację z czatem, na przykład w Slacku lub przez zdalny workflow aprobacyjny. Okazało się, że znaki sterujące kierunkiem tekstu, znaki o zerowej szerokości oraz wizualnie podobne cudzysłowy mogły sprawić, że użytkownik widział w podglądzie coś innego niż rzeczywistą zawartość komendy.

    Neutralizacja tych znaków eliminuje ryzyko wizualnego oszustwa w podglądach uprawnień. To szczególnie istotne w środowiskach, gdzie decyzje aprobacyjne zapadają poza terminalem — w komunikatorach, systemach automatyzacji czy zdalnych panelach zarządzania.

    Dodatkowo, poprawiono działanie hooków PreToolUse w interakcji z trybem automatycznego zatwierdzania. Jeśli hook zwróci decyzję ask dla nieizolowanej komendy Bash, Claude Code zawsze poprosi użytkownika o potwierdzenie, nawet gdy sesja działa w trybie auto-approve. To daje zespołom odpowiedzialnym za bezpieczeństwo realną kontrolę nad operacjami powłoki wysokiego ryzyka.

    Stabilność i praca równoległa

    Stabilność i praca równoległa

    W tej wersji wprowadzono również poprawki błędów i usprawnienia niezawodności. Naprawiono między innymi zapisywanie uprawnień w git worktrees — zgody przyznane w worktree trafiają teraz do głównego repozytorium, co eliminuje potrzebę ich powtarzania przy każdej sesji. Ulepszono także persistencję sesji w tle, obsługę credential stores w równoległych sesjach oraz walidację uploadu plików.

    Warto również zwrócić uwagę na poprawkę dla subagentów z nadpisanym modelem — wcześniej po wznowieniu sesji lub wysłaniu follow-upa mogły wracać do modelu rodzica. Teraz utrzymują swój model.

    Dla zespołów pracujących wielowątkowo — w CI, na zdalnych środowiskach deweloperskich czy w repozytoriach z równoległymi worktrees — te poprawki oznaczają mniej niespodzianek i mniej ręcznego sprzątania po sesjach.

    Drobne, ale przydatne

    Drobne, ale przydatne

    Warto także wspomnieć o optymalizacji renderowania terminala oraz poprawionym formatowaniu zmiennych środowiskowych. Ulepszono również działanie cache'owania promptów dla providerów z rodziny Bedrock, Vertex, Mantle i Foundry — kontekst systemowy na końcu promptu przestał być liczony jako świeże tokeny, co może przełożyć się na niższe rachunki, choć Anthropic nie podało konkretnych oszczędności.

    Błędy MCP dla konfiguracji z url bez jawnego type również otrzymały bardziej zrozumiałe komunikaty — zamiast mylącego błędu o brakującym command stringu, użytkownik zobaczy sugestię dodania "type": "http".

    Podsumowanie

    Claude Code 2.1.211 wprowadza istotne zmiany, które poprawiają funkcjonalność i bezpieczeństwo, a także zwiększają stabilność działania w różnych środowiskach.

    Źródła

  • Claude Code 2.1.210 przynosi licznik czasu działania narzędzi i ostrzeżenia o ryzykownych uprawnieniach

    Claude Code 2.1.210 przynosi licznik czasu działania narzędzi i ostrzeżenia o ryzykownych uprawnieniach

    14 lipca 2026 roku Anthropic opublikowało wersję 2.1.210 Claude Code. Ta aktualizacja zawiera 33 zmiany w interfejsie CLI, które koncentrują się na poprawie widoczności pracy agentów, bezpieczeństwie konfiguracji uprawnień oraz stabilności sesji. Wydanie to jest istotne dla zespołów DevOps i deweloperów korzystających z Claude Code do zadań w tle, równoległego kodowania oraz zautomatyzowanych przepływów pracy z pull requestami.

    Kluczowe fakty o wydaniu

    • Licznik czasu rzeczywistego wyświetla się przy długo działających wywołaniach narzędzi, pokazując upływający czas na bieżąco.
    • Ostrzeżenia startowe informują o regułach uprawnień używających Write(path), NotebookEdit(path) lub Glob(path) zamiast bezpieczniejszych Edit(path) i Read(path).
    • Poprawka izolacji git worktree naprawia błąd, przez który subagenci mogli modyfikować główne repozytorium zamiast izolowanej gałęzi roboczej.
    • 33 zmiany CLI obejmują też usprawnienia dashboardu agentów, wsparcie dla czytników ekranu oraz zabezpieczenia przed prompt injection.

    Dlaczego widoczność działania narzędzi ma znaczenie

    Nowy licznik upływającego czasu pojawia się w zwiniętych podsumowaniach wywołań narzędzi i aktualizuje się w sposób ciągły. Dla dewelopera, który obserwuje trwający build, testy czy przeszukiwanie dużego repozytorium, to istotna zmiana — pozwala odróżnić proces, który faktycznie pracuje, od takiego, który się zawiesił. Wcześniej długo działające polecenia wyglądały identycznie jak te, które utknęły. Teraz można łatwo zobaczyć, czy coś się dzieje.

    W środowiskach CI/CD oraz przy zautomatyzowanych agentach działających w tle ta zmiana zmniejsza potrzebę ręcznego sprawdzania logów systemowych. Wystarczy rzut oka na interfejs Claude Code, aby ocenić postęp.

    Izolacja worktree — cicha, ale krytyczna poprawka

    Worktree to mechanizm gita, który pozwala wielu sesjom Claude Code operować na osobnych gałęziach i katalogach roboczych przy współdzielonej historii repozytorium. To fundament bezpiecznej pracy równoległej — jeden agent może robić refaktoring, inny przeglądać kod, a jeszcze inny generować dokumentację, każdy w swojej przestrzeni.

    Błąd naprawiony w wersji 2.1.210 powodował, że subagent skonfigurowany z isolation: "worktree" mógł wykonywać operacje modyfikujące główne repozytorium. To prowadziło do zanieczyszczenia gałęzi, nieoczekiwanych commitów oraz zmian poza zamierzonym zakresem. Dla zespołów korzystających z agentów do automatyzacji PR-ów była to potencjalnie kosztowna usterka. Poprawka przywraca pełną separację — agent z izolacją worktree nie może ingerować w swoją piaskownicę.

    Ostrzeżenia o uprawnieniach, zanim będzie za późno

    Claude Code 2.1.210 wprowadza komunikat wyświetlany przy starcie, gdy reguły uprawnień używają Write(path), NotebookEdit(path) lub Glob(path). Dokumentacja zaleca stosowanie Edit(path) i Read(path), które są bezpieczniejsze i lepiej oddają intencję. Problem nie jest tylko techniczny — reguła napisana złym poleceniem może dawać fałszywe poczucie ochrony. Deweloper może sądzić, że zabezpieczył plik, podczas gdy narzędzie działa inaczej niż zakładał.

    Ostrzeżenie przy starcie pozwala skorygować konfigurację przed wykonaniem jakiejkolwiek operacji na plikach. Z perspektywy zarządzania to mały krok, który może zapobiec poważnym problemom.

    Stabilność, dostępność i hardening

    Wydanie zawiera także szereg mniejszych, ale praktycznych usprawnień. Dashboard agentów teraz lepiej informuje o stanie i aktywności agentów równoległych — mniej zgadywania, co robi który proces. Użytkownicy czytników ekranu zyskali lepszą nawigację po terminalowym interfejsie Claude Code. Poprawiono również obsługę sesji w tle oraz błędy powodujące ich awarie.

    W zakresie bezpieczeństwa warto zauważyć hardening narzędzia Agent przed prompt injection, co jest istotne przy przetwarzaniu niezaufanych treści z repozytoriów, komentarzy czy webhooków. Dodatkowo poprawiono działanie ultracode, które nie będzie już niepotrzebnie aktywowane na wejściu niepochodzącym od człowieka, takim jak komentarze do PR-ów.

    Wersja 2.1.210 wskazuje kierunek, w jakim zmierza Claude Code: agent ma działać szybciej, przewidywalniej i bezpieczniej. Dla każdego, kto wdraża kod na produkcję za pomocą agenta AI, ta aktualizacja jest warta natychmiastowego wdrożenia.

    Źródła

  • Gemini CLI z lepszą diagnostyką limitów i pewniejszym anulowaniem zadań

    Gemini CLI z lepszą diagnostyką limitów i pewniejszym anulowaniem zadań

    Google wprowadziło nową wersję nocną Gemini CLI – v0.52.0-nightly.20260714, która zawiera kilka istotnych poprawek w kluczowych obszarach narzędzia. Aktualizacja wprowadza bardziej zrozumiałe komunikaty o przekroczeniu limitów dla współdzielonych projektów, niezawodne zatrzymywanie zadań w serwerze A2A oraz obsługę ścieżek względnych w trybie planowania. Dodatkowo zaktualizowano bibliotekę Google Auth do wersji 10.9.0.

    Co nowego w wersji nightly

    • Limit współdzielonych projektów – błędy związane z wyczerpaniem puli zasobów zawierają teraz wskazówkę konfiguracyjną, która prowadzi użytkownika do odpowiednich ustawień projektu.
    • Anulowanie zadań A2A – serwer agent-to-agent natychmiast przerywa aktywną pętlę wykonawczą po żądaniu anulowania, zamiast tylko zmieniać stan zadania.
    • Ścieżki względne w Plan Mode – narzędzie akceptuje teraz zapis plików planu w formacie względnym, co eliminuje wcześniejsze błędy przy typowych strukturach repozytoriów.
    • Google Auth 10.9.0 – aktualizacja zależności uwierzytelniającej, która zapewnia zgodność z najnowszymi poprawkami bezpieczeństwa.

    Diagnostyka limitów, która wreszcie mówi, co zrobić

    Każdy, kto pracował z Gemini CLI w zespole, prędzej czy później napotkał na problem związany z limitami. Dotychczas komunikat był mało informacyjny – na przykład „quota exceeded” – co pozostawiało użytkownika w niepewności. Wersja z 14 lipca dodaje do tego błędu wskazówkę konfiguracyjną.

    Zamiast przeszukiwać dokumentację, użytkownik otrzymuje informację, które ustawienia projektu wymagają poprawy. To drobna zmiana, ale znacząco zmniejsza frustrację przy konfigurowaniu współdzielonej puli zasobów w zespole. Jest to szczególnie pomocne dla osób, które dopiero wdrażają Gemini CLI w swojej organizacji.

    A2A: anulowanie, które faktycznie zatrzymuje pracę

    W przepływach agent-to-agent szybkie przerwanie długiego zadania jest kluczowe. Wyobraź sobie, że uruchamiasz złożone zapytanie, które okazuje się niepotrzebne – klikasz „cancel”, ale serwer w tle nadal wykonuje pętlę. W poprzednich wersjach występował ten problem: anulowanie aktualizowało stan zadania, ale proces nadal działał.

    Nowa wersja eliminuje to zachowanie. Żądanie anulowania natychmiast przerywa aktywną pętlę wykonawczą. Dla workflow, w którym jeden agent zleca pracę drugiemu, to różnica między kontrolowanym zatrzymaniem a niekontrolowanym zużywaniem zasobów, co jest szczególnie ważne przy kosztownych obliczeniowo zadaniach.

    Plan Mode i ścieżki względne – koniec z niespodziankami

    Tryb planowania w Gemini CLI umożliwia zapisanie wygenerowanego planu działania do pliku. Wcześniej polityka zapisu wymagała stosowania ścieżek bezwzględnych. Próba zapisu do pliku plan.md w bieżącym katalogu kończyła się błędem, co było irytujące przy pracy w tymczasowych katalogach roboczych.

    Aktualizacja upraszcza tę politykę, akceptując ścieżki względne. W efekcie Plan Mode działa teraz przewidywalnie – plik planu ląduje dokładnie tam, gdzie go oczekujesz, bez konieczności stosowania absolutnych ścieżek.

    Co z tego wynika dla codziennej pracy

    Te zmiany to solidne poprawki operacyjne, które mogą poprawić codzienną pracę. Lepsze komunikaty o limitach skracają czas diagnozowania problemów konfiguracyjnych. Poprawne anulowanie zadań eliminuje sytuacje, w których zatrzymany proces nadal konsumuje zasoby. Wsparcie dla ścieżek względnych sprawia, że Plan Mode lepiej integruje się z codziennymi workflow w repozytoriach.

    Aktualizacja biblioteki autoryzacyjnej to rutynowy, ale istotny krok – Gemini CLI intensywnie korzysta z kont Google, OAuth i kluczy API, więc opóźnienia w zależnościach bezpieczeństwa byłyby ryzykowne.

    Wersja jest oznaczona jako nightly, co oznacza codzienne budowanie z głównej gałęzi rozwojowej. Google informuje, że takie buildy mogą zawierać błędy, które nie przeszły jeszcze pełnej walidacji. Jeśli jednak polegasz na Gemini CLI w projektach zespołowych lub korzystasz z przepływów agent-to-agent, warto sprawdzić, czy te poprawki wkrótce trafią do stabilnego kanału.

    Źródła

  • Codex 0.144.3: cicha aktualizacja, która porządkuje wersjonowanie

    Codex 0.144.3: cicha aktualizacja, która porządkuje wersjonowanie

    OpenAI opublikowało 13 lipca 2026 roku wersję 0.144.3 swojego narzędzia Codex CLI. To wydanie nie wprowadza nowych funkcji ani nie naprawia błędów — jest to aktualizacja wyłącznie wersyjna, oparta na kodzie z wersji 0.144.3. Dla zespołów, które mają sztywno przypięte numery wersji, takie posunięcie ma znaczenie.

    Kluczowe fakty

    • Codex CLI 0.144.3 to wydanie typu patch, opublikowane bez żadnych zmian w kodzie źródłowym.
    • Brak scalonych pull requestów od czasu tagu rust-v0.144.3 — changelog informuje, że nie dodano nowego kodu.
    • Stabilna kompilacja oparta na wersji 0.144.3, co zapewnia ciągłość pakietu dla użytkowników npm.
    • Komenda instalacji to standardowe npm install -g @openai/[email protected].
    • Analiza repozytorium z tego taga pokazuje 2640 plików źródłowych Rusta, 178 zmiennych środowiskowych i 40 identyfikatorów modeli AI.

    Co właściwie jest w środku

    Zespół deweloperski zdecydował się na podniesienie numeru wersji bez dołączania jakichkolwiek poprawek. To typowy ruch konserwacyjny w dużych projektach.

    Wydanie 0.144.3 powstało jako kopia stanu kodu oznaczonego tagiem rust-v0.144.3. Od tego czasu nie scalono ani jednego pull requesta. Oficjalny wpis w changelogu stwierdza, że „to wydanie wyłącznie wersyjne nie zawiera żadnych zmian z pull requestów od czasu rust-v0.144.3”. W mediach społecznościowych zaznaczono, że chodzi o stabilną kompilację — nic więcej.

    Dla użytkowników Codexa na co dzień ta informacja jest praktycznie niewidoczna. Narzędzie działa tak samo jak w wersji 0.144.3. Jednak dla administratorów infrastruktury i osób zarządzających pipeline'ami CI/CD to jasny sygnał: można bezpiecznie wskazać tę wersję jako punkt kontrolny.

    Rust, monorepo i skala projektu

    Rust, monorepo i skala projektu

    Codex CLI to projekt napisany w Ruście, zorganizowany jako monorepo — jedno repozytorium, które zawiera wiele powiązanych ze sobą skrzynek (crates). Analiza tagu rust-v0.144.3 pokazuje, że w workspace codex-rs znajduje się 2640 plików źródłowych.

    To spora baza kodu. Znajdują się tam 178 nazw zmiennych środowiskowych i 40 ciągów identyfikujących modele AI. Takie liczby ukazują złożoność narzędzia — nawet jeśli z zewnątrz wygląda na prosty terminalowy interfejs, pod spodem kryje się rozbudowana struktura.

    Monorepo ma swoje zalety: ułatwia współdzielenie kodu między modułami i upraszcza zarządzanie zależnościami. Wymaga jednak dyscypliny w wersjonowaniu. Stąd takie wydania jak 0.144.3 — służą jako punkty synchronizacji, które pozwalają zespołowi utrzymać porządek wśród współbieżnie rozwijanych gałęzi.

    Dlaczego pusta łatka ma sens

    Dlaczego pusta łatka ma sens

    W ekosystemie npm przypięcie wersji do konkretnego numeru to standardowa praktyka. Jeśli zespół testował swoją aplikację z Codexem 0.144.3 i wszystko działało, to przejście na 0.144.3 nie niesie ryzyka regresji — kod pozostaje ten sam.

    Z punktu widzenia DevOps to czysty zysk. Można zaktualizować zależność, zachowując pełną kompatybilność, a jednocześnie uniknąć ostrzeżeń narzędzi do audytu bezpieczeństwa, które czasami panikują przy starszych numerach wersji. Nie ma tu żadnych przełomów. Jest za to przewidywalność — cecha, którą inżynierowie utrzymania cenią bardziej niż nowe funkcje.

    Podsumowanie

    Codex 0.144.3 to przykład wydania, które niczego nie zmienia. OpenAI przyjęło konserwatywne podejście: podniesienie wersji, zapewnienie społeczności stabilnego punktu odniesienia i unikanie niepotrzebnych regresji. Dla użytkowników końcowych to wydarzenie może być nieistotne, ale dla tych, którzy zarządzają zależnościami w poważnych projektach, jest to mały, ale użyteczny sygnał, że wszystko jest pod kontrolą.

    Źródła

  • Gemini CLI zyskuje lepszą kontrolę nad zadaniami i czytelniejsze komunikaty o limitach

    Gemini CLI zyskuje lepszą kontrolę nad zadaniami i czytelniejsze komunikaty o limitach

    Nowa wersja narzędzia Gemini CLI wprowadza kilka poprawek, które wpływają na komfort pracy programistów. Zespół Google skupił się na trzech obszarach: komunikacji błędów związanych z limitami, niezawodności anulowania zadań w trybie agentowym oraz uproszczeniu konfiguracji dla planowania zmian w repozytoriach.

    Co się zmieniło?

    • Komunikaty o limitach zostały wzbogacone o wskazówkę dotyczącą konfiguracji, co ułatwia diagnozę problemów z wyczerpanym limitem współdzielonego projektu.
    • Anulowanie zadań na serwerze A2A działa teraz pewniej – przerwane zadania natychmiast zatrzymują pętlę wykonawczą, zamiast kontynuować pracę po anulowaniu.
    • Tryb planowania obsługuje ścieżki względne w politykach zapisu, co upraszcza konfigurację w lokalnych repozytoriach.
    • Aktualizacja zależności google-auth-library do wersji 10.9.0 to standardowa poprawka bezpieczeństwa i kompatybilności.

    Mniej frustracji przy limitach – konkretne podpowiedzi zamiast enigmatycznych błędów

    Jedną z przeszkód w pracy z narzędziami AI jest sytuacja, gdy limit tokenów wyczerpuje się w połowie sesji. Do tej pory użytkownicy Gemini CLI musieli samodzielnie dochodzić, dlaczego nagle stracili dostęp. Teraz to się zmienia.

    Nowa wersja wzbogaca komunikaty o błędach limitu współdzielonego projektu o wskazówkę dotyczącą konfiguracji. Zamiast suchego „przekroczono limit”, użytkownicy otrzymują informację, co konkretnie zrobić, by rozwiązać problem. W praktyce ma to znaczenie dla zespołów korzystających z różnych usług Gemini na tym samym projekcie w Google Cloud. Limity współdzielone mogą blokować dostęp zarówno w CLI, jak i w innych narzędziach, więc jasny komunikat oszczędza czas na szukanie przyczyny.

    Gemini CLI oferuje również komendę /stats model, która pozwala sprawdzić bieżące zużycie tokenów, zanim limit zostanie przekroczony.

    Anulowanie, które naprawdę działa – poprawka dla serwera A2A

    Autonomiczne przepływy pracy i agenci AI to ważny temat w środowisku web devu i DevOps. Długotrwałe zadania muszą dać się niezawodnie zatrzymać. W przeciwnym razie tracimy kontrolę nad tym, co wykonuje nasz kod.

    Poprawka w serwerze A2A (Agent-to-Agent) rozwiązuje ten problem. Wcześniej zdarzało się, że anulowane zadanie kontynuowało wykonanie – pętla nie była przerywana prawidłowo. Po aktualizacji anulowanie natychmiast przerywa cykl wykonawczy. Dla programistów pracujących z vibe codingiem czy automatyzacją CI oznacza to mniej niespodzianek i większą przewidywalność działania narzędzia.

    Ścieżki względne w trybie planowania – mniej absolutnych zależności

    Tryb Plan Mode w Gemini CLI to środowisko tylko do odczytu, w którym można zaplanować zmiany przed ich wprowadzeniem. Przełącza się do niego komendą /plan. Dotychczas polityki zapisu w tym trybie opierały się na ścieżkach bezwzględnych, co bywało kłopotliwe przy pracy z repozytoriami klonowanymi w różnych lokalizacjach.

    Teraz polityki zapisu obsługują ścieżki względne. Dla zespołów pracujących lokalnie to ułatwienie – konfiguracja staje się przenośna między maszynami i środowiskami deweloperskimi. Nie trzeba już dostosowywać ścieżek za każdym razem, gdy projekt ląduje w innym katalogu.

    Co dalej dla Gemini CLI?

    Aktualizacja zależności google-auth-library do wersji 10.9.0 to ruch w tle, ale istotny dla bezpieczeństwa. Narzędzia integrujące się z tożsamością Google i usługami chmurowymi muszą nadążać za poprawkami w bibliotekach uwierzytelniania – to standardowa praktyka, która zmniejsza ryzyko luk.

    Choć zmiany w tej wersji nie są spektakularne wizualnie, dotykają newralgicznych punktów: diagnostyki błędów, kontroli nad procesami i elastyczności konfiguracji. W narzędziu do AI, które coraz częściej działa nie tylko jako asystent, ale jako autonomiczny agent, niezawodność tych mechanizmów jest kluczowa. Gemini CLI zmierza w kierunku bardziej dojrzałego środowiska produkcyjnego, a nie tylko zabawki do eksperymentów.

    Źródła

  • Factory v0.171.0 stawia na stabilność: lepsze zarządzanie kontekstem i wsparcie CLI dla Windows

    Factory v0.171.0 stawia na stabilność: lepsze zarządzanie kontekstem i wsparcie CLI dla Windows

    Platforma Factory otrzymała aktualizację v0.171.0, która koncentruje się na niezawodności narzędzia i ułatwieniu pracy programistom korzystającym z systemu Windows. Deweloperzy zyskali nowy skrypt instalacyjny dla Droid CLI, a także znaczące usprawnienia w zarządzaniu serwerami MCP. Aktualizacja przynosi szereg poprawek, które eliminują uciążliwe problemy techniczne i przyspieszają wdrożenie agenta AI w środowisku deweloperskim.

    Co nowego w pigułce

    • Nowy skrypt instalacyjny dla Windows automatycznie dodaje katalog instalacyjny do PATH, co pozwala na natychmiastowe działanie CLI po instalacji.
    • Przebudowane menu MCP ułatwia podłączanie zewnętrznych narzędzi oraz zarządzanie serwerami w workflow agenta.
    • Wyświetlanie zużycia kontekstu pojawia się od razu po wznowieniu sesji, eliminując potrzebę zgadywania.
    • Poprawione wykrywanie architektury instalatora Windows eliminuje błędy przy wyborze wersji.
    • Wiele krytycznych poprawek, w tym timeouty połączeń MCP, wykrywanie motywu przez SSH oraz błędy interfejsu.

    Windows wreszcie obywatelem pierwszej kategorii

    Deweloperzy na Windows od dawna czuli się niedoceniani w kontekście narzędzi agentowych. Wersja v0.171.0 zmienia tę sytuację. Skrypt instalacyjny dla Droid CLI nie tylko kopiuje pliki, ale także sprawdza, czy katalog docelowy jest już w PATH. Jeśli nie, dodaje go i aktualizuje zmienną w bieżącej sesji terminala.

    Dzięki temu po wpisaniu droid w konsoli narzędzie działa natychmiast, bez potrzeby ręcznego edytowania zmiennych środowiskowych. Choć to może wydawać się drobnym szczegółem, każdy, kto konfigurował toolchain na Windows, wie, że takie detale mogą decydować o czasie potrzebnym na wdrożenie narzędzia.

    Dodatkowo poprawiono wykrywanie architektury instalatora. Wcześniej zdarzały się sytuacje, w których instalator błędnie identyfikował system i próbował zainstalować niekompatybilną wersję. Teraz ten problem został rozwiązany, a CLI uruchamia się szybciej po instalacji dzięki usunięciu zbędnego kroku konfiguracji konsoli.

    MCP i zarządzanie kontekstem bez frustracji

    Kolejnym istotnym elementem tej aktualizacji są poprawki związane z Model Context Protocol (MCP). MCP to mechanizm, który pozwala Factory na łączenie się z zewnętrznymi narzędziami, takimi jak bazy danych czy API monitoringu. W wersji v0.171.0 naprawiono timeouty połączeń, które mogły przerywać sesję w nieodpowiednich momentach.

    Przebudowane menu MCP ułatwia zarządzanie serwerami. Teraz można szybciej zidentyfikować aktywne serwery, a konfiguracja nowych jest bardziej intuicyjna. Dla zespołów devopsowych, które integrują Droid z własnym stackiem, to oszczędność czasu i nerwów.

    Zarządzanie kontekstem również zostało znacząco poprawione. Po wznowieniu sesji od razu widać, ile miejsca w oknie kontekstowym zajmują dotychczasowe wiadomości i dokumenty. To istotna funkcjonalność, która pozwala na lepsze monitorowanie, kiedy agent może zacząć gubić wątki z powodu przekroczenia limitu tokenów.

    Drobne rzeczy, które robią różnicę

    W tej aktualizacji rozwiązano także kilka bardziej szczegółowych problemów. Automatyczne wykrywanie motywu interfejsu nie działało poprawnie przez SSH, co było szczególnie irytujące podczas pracy zdalnej, gdy aplikacja nagle zmieniała wygląd. Teraz działa bez zarzutu.

    Poprawiono również obsługę powiadomień w desktopowej aplikacji oraz niezawodność zapisywania ustawień misji. Choć to nie są zmiany, które przyciągną uwagę na okładkach, to właśnie one sprawiają, że narzędzie staje się bardziej funkcjonalne i mniej uciążliwe w codziennym użytkowaniu.

    Co to oznacza dla zespołów

    Factory pozycjonuje CLI jako główne narzędzie do delegowania pracy agentowi AI z poziomu terminala. Każda aktualizacja, która upraszcza instalację i zwiększa stabilność podstawowych mechanizmów, wpływa na tempo adopcji w zespołach developerskich.

    Dla osób, które wcześniej testowały Factory i napotkały problemy na Windowsie lub frustrujące timeouty MCP, wersja v0.171.0 to dobra okazja, aby dać platformie drugą szansę. Dla tych, którzy już korzystają z Factory na co dzień, aktualizacja oznacza mniej przerw w pracy oraz bardziej przejrzyste informacje o stanie sesji.

    Źródła

  • Cline 4.0.8 otwiera się na GCP Vertex — teraz wpiszesz własny model z palca

    Cline 4.0.8 otwiera się na GCP Vertex — teraz wpiszesz własny model z palca

    Cline w wersji 4.0.8 wprowadza istotne zmiany w integracji z Google Cloud Vertex AI, poszerzając ofertę o więcej gotowych modeli oraz wprowadzając możliwość ręcznego wpisywania identyfikatorów dla niestandardowych konfiguracji. Deweloperzy korzystający z Vertex mogą teraz łatwiej uzyskać dostęp do nowych modeli, regionalnych oraz wewnętrznych, bez konieczności czekania na aktualizację katalogu.

    Co nowego w integracji z Vertex AI

    • Rozszerzona lista modeli — w interfejsie Cline dostępnych jest więcej modeli hostowanych na platformie Vertex.
    • Swobodny wpis identyfikatora — nowa opcja w rozwijanym menu umożliwia ręczne podanie nazwy modelu, zamiast wyboru z gotowej listy.
    • Autoryzacja bez zmian — konfiguracja opiera się na koncie serwisowym lub domyślnych poświadczeniach aplikacji, z wymogiem aktywnego projektu GCP i włączonej usługi Vertex AI.
    • Przepustowość bez blokady — niestandardowe identyfikatory są przekazywane bez modyfikacji, co umożliwia natychmiastowe działanie modeli eksperymentalnych czy prywatnych wdrożeń.

    Dlaczego to ma znaczenie dla zespołów na GCP

    Vertex AI jest kluczowym elementem ekosystemu Google, oferującym zarządzanie dostępem i kontrolę na poziomie projektu. Cline od dawna wspiera Vertex jako jednego z dostawców modeli, ale wcześniej użytkownicy byli ograniczeni do listy modeli przygotowanej przez zespół Cline. To działało dobrze dla popularnych modeli, ale pojawiały się problemy, gdy nowe modele były dostępne w regionie, ale nie były jeszcze widoczne w interfejsie.

    Dzięki nowej opcji ręcznego wpisywania identyfikatora, można teraz łatwo skopiować identyfikator modelu z konsoli Google Cloud i wkleić go w ustawieniach Cline. Dla zespołów pracujących w złożonych środowiskach, gdzie dostępność modeli różni się między regionami i projektami, oznacza to koniec ręcznego dostosowywania konfiguracji.

    Szerszy obraz: mniej tarć, więcej elastyczności

    Cline od początku stawia na wielodostawczość. Umożliwia użytkownikom przełączanie się między różnymi modelami, takimi jak Claude, Gemini, modele z Vertex czy Deep Seek, bez przywiązywania się do jednego ekosystemu. Wprowadzenie opcji ręcznego wpisywania identyfikatorów dla Vertex to krok w stronę większej elastyczności, pozwalający użytkownikom na samodzielne wybieranie modeli, które najlepiej odpowiadają ich potrzebom.

    W notkach do przyszłych wydań Cline zaznaczono, że identyfikatory modeli Vertex przechodzą przez system bez ingerencji. Oznacza to, że nawet wewnętrzne wdrożenia fine-tuned modeli, przypisane do konkretnego projektu GCP, będą działać tak, jakby były natywnie wspierane. Wystarczy poprawna autoryzacja i aktywny endpoint.

    Jak to skonfigurować

    Proces konfiguracji pozostał bez zmian w porównaniu do wcześniejszych wersji. W ustawieniach Cline należy wybrać GCP Vertex AI jako dostawcę, a następnie podać identyfikator projektu oraz region. Uwierzytelnienie można zrealizować za pomocą klucza konta serwisowego lub domyślnych poświadczeń aplikacji. Różnica polega na tym, że zamiast wybierać z listy modeli, można teraz wpisać własną wartość, na przykład gemini-2.0-flash-exp lub identyfikator wewnętrznego modelu organizacji.

    To oznacza szybszy dostęp do testowych wersji modeli i łatwiejsze włączenie Cline w istniejące pipeline'y AI w firmach. Dla mniejszych zespołów developerskich to jedno kliknięcie mniej i mniej powodów do szukania obejść.

    Aktualizacja jest dostępna w głównym repozytorium Cline na GitHubie, a szczegóły techniczne można znaleźć w oficjalnych changelogach oraz dokumentacji providera w docs.cline.bot.

    Źródła

  • Claude Code 2.1.200: sterowanie uprawnieniami wraca w ręce programisty, agenty w tle przestają się sypać

    Claude Code 2.1.200: sterowanie uprawnieniami wraca w ręce programisty, agenty w tle przestają się sypać

    Anthropic wypuścił wersję 2.1.200 narzędzia Claude Code, która domyślnie przełącza model uprawnień na Manual i wymusza ręczne zatwierdzanie dialogów AskUserQuestion we wszystkich interfejsach — CLI, VS Code oraz JetBrains. Zmiany te mają na celu ograniczenie przypadkowego wykonania kodu bez nadzoru, co przy pracy z agentami bywało poważnym ryzykiem.

    Równolegle zespół dostarczył zestaw poprawek stabilności dla agentów działających w tle. Sesje backgroundowe doczekały się łatek na zakleszczenia demonów, awarie procesów i błędy autoryzacji socketów. Dodatkowo wprowadzono ulepszenia dostępności dla czytników ekranu oraz usunięto kilka błędów renderowania i zarządzania sesjami.

    Co konkretnie zmienia Claude Code 2.1.200

    • Uprawnienia Manual zastępują poprzedni model domyślny we wszystkich głównych interfejsach; alias manual działa zamiennie z default w konfiguracji.
    • Dialogi AskUserQuestion przestały kontynuować automatycznie — wymagają jawnego działania użytkownika po każdej odpowiedzi.
    • Agenci w tle otrzymali poprawki eliminujące zakleszczenia demonów, nagłe awarie procesów i problemy z autoryzacją socketów.
    • Czytniki ekranu zyskały ulepszenia dostępnościowe w terminalu i integracjach edytorowych.
    • Sesje backgroundowe nie będą już cicho zatrzymywać się w połowie tury po uśpieniu systemu lub ponownym otwarciu wstrzymanej pracy.

    Dlaczego „Manual” robi różnicę

    Wcześniej domyślne uprawnienia Claude Code pozwalały agentowi na samodzielne wykonywanie wielu operacji — czasem bez wyraźnego potwierdzenia ze strony programisty. Przy szybkim tempie pracy zdarzało się, że narzędzie kontynuowało działanie, gdy użytkownik odwrócił uwagę od terminala. Nowy tryb Manual oznacza, że każde wywołanie wymagające zgody czeka na bezpośrednią reakcję. Nie ma już automatycznego przechodzenia dalej.

    Dla zespołów DevOps i osób pracujących w środowiskach zbliżonych do produkcyjnych to istotna zmiana. Zmniejsza się ryzyko niekontrolowanej modyfikacji konfiguracji serwerów czy kodu infrastrukturalnego. Deweloperzy korzystający z subagentów docenią również alias manual — dokumentacja potwierdza, że od wersji 2.1.200 można go używać zamiennie z default, co ułatwia migrację starszych konfiguracji bez grzebania w plikach ustawień.

    Stabilność agentów, która naprawdę działa

    Background agents w Claude Code to mechanizm pozwalający na uruchamianie długotrwałych zadań bez konieczności trzymania otwartego terminala. Niestety, wcześniejsze wydania miały kilka dokuczliwych usterek: blokady demonów mogły zawiesić sesję, procesy agentów niespodziewanie znikały, a sockety gubiły autoryzację w trakcie pracy.

    Wersja 2.1.200 celuje w te problemy. Wyeliminowano przypadki, w których sesja backgroundowa przestawała działać w połowie tury po wybudzeniu komputera ze snu albo po ponownym podłączeniu do wstrzymanego zadania. To konkretna korzyść dla osób uruchamiających wielogodzinne procesy, takie jak "nightly buildy" czy skrypty monitorujące stan infrastruktury.

    W tej wersji pojawiła się także infrastruktura dla eksperymentalnych „obserwatorów” — drugi agent może nadzorować głównego i raportować przez ObserverReport, co otwiera możliwości bardziej złożonych przepływów pracy z podwójną kontrolą.

    Drobne, ale potrzebne poprawki

    Nie samymi uprawnieniami i agentami żyje programista. Wersja 2.1.200 wprowadza kilka mniej widocznych, ale przydatnych łatek: błędy renderowania w różnych widokach zostały naprawione, zarządzanie sesjami nie gubi stanu przy przełączaniu kontekstów, a czytniki ekranu zyskały wsparcie, które zwiększa użyteczność narzędzia w zespołach dbających o dostępność.

    Dla użytkowników pracujących w VS Code i JetBrains zmiana etykiety uprawnień na Manual pojawia się także w panelach pomocy (--help), co sprawia, że nowe zachowanie jest od razu widoczne — nie trzeba go szukać w changelogu.

    Podsumowanie

    Claude Code 2.1.200 to aktualizacja, która nie wprowadza spektakularnych nowości, ale przesuwa akcenty w kierunku kontroli i niezawodności. Przejście na Manual jako domyślny tryb uprawnień daje programistom większą decyzyjność, a stabilizacja background agents sprawia, że długotrwałe zadania stają się bardziej przewidywalne. W codziennej pracy oznacza to mniej niespodzianek i więcej stabilności — co jest kluczowe w narzędziach AI wspomagających kodowanie.

    Źródła