Tag: bezpieczeństwo

  • 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

  • Claude z nowymi narzędziami bezpieczeństwa: wygasanie kluczy API i pełniejszy wgląd w wydarzenia administracyjne

    Claude z nowymi narzędziami bezpieczeństwa: wygasanie kluczy API i pełniejszy wgląd w wydarzenia administracyjne

    Anthropic rozszerzyło dokumentację Access Transparency dla zdarzeń cmek_preserve oraz wprowadziło możliwość ustawiania daty wygaśnięcia kluczy API bezpośrednio w konsoli Claude. Te zmiany, choć mogą wydawać się drobne, przynoszą znaczące korzyści dla zespołów DevOps i platform engineeringu w zakresie zarządzania bezpieczeństwem.

    Co konkretnie się zmieniło?

    • Access Transparency zawiera teraz przykładowy payload zdarzeń cmek_preserve oraz dwa nowe kody przyczyny: policy_violation_investigation i csae_report.
    • Dokumentacja wyjaśnia, że zdarzenie zachowania treści jest rejestrowane niezależnie od tego, czy proces został zainicjowany przez człowieka, czy przez zautomatyzowany pipeline bezpieczeństwa.
    • Klucze API można teraz tworzyć z określoną datą wygaśnięcia – predefiniowaną, niestandardową lub bezterminową.
    • Dla kluczy z okresem życia minimum 7 dni Anthropic wysyła do twórcy powiadomienie e-mail przed wygaśnięciem.
    • Pole expires_at w Admin API oraz tabela kluczy w konsoli pokazują status wygaśnięcia, co ułatwia audyt i rotację.

    Więcej przejrzystości wokół CMEK

    Access Transparency to mechanizm, który umożliwia organizacjom wgląd w to, kiedy i dlaczego Anthropic uzyskuje dostęp do ich treści. Rozszerzenie dokumentacji o filtry i konkretne przykłady payloadów dla zdarzeń cmek_preserve będzie szczególnie przydatne dla zespołów pracujących w regulowanych środowiskach.

    Ważnym uzupełnieniem jest wyjaśnienie dotyczące mechanizmu przechowywania treści. Kiedy organizacja korzysta z kluczy szyfrowania zarządzanych przez klienta (CMEK), zachowana treść jest ponownie szyfrowana poza tym kluczem. Dzięki temu dochodzenie może być kontynuowane niezależnie od tego, czy klient nadal udostępnia swój klucz, co jest istotne w przypadku incydentów bezpieczeństwa.

    W dokumentacji pojawiły się także kody przyczyn zachowania treści: safety_review, incident_response, policy_violation_investigation oraz csae_report. Dla audytorów to konkretna informacja – wiadomo nie tylko, że coś zostało zachowane, ale także dlaczego i czy stało za tym narzędzie automatyczne, czy decyzja człowieka.

    Koniec z wiecznymi kluczami

    Druga zmiana, choć bardziej praktyczna, jest równie istotna. W konsoli Claude można teraz ustawić datę wygaśnięcia klucza API już na etapie jego tworzenia. Użytkownicy mogą wybierać spośród okresów predefiniowanych, niestandardowych lub opcji "Nigdy". Istniejące klucze pozostają bez zmian, co zapobiega problemom z działaniem pipeline'ów.

    Długowieczne klucze API to klasyczny problem bezpieczeństwa – im dłużej klucz istnieje, tym większe ryzyko jego wycieku. Automatyczne przypomnienia e-mail dla kluczy z minimum tygodniowym okresem życia stanowią dodatkową warstwę zabezpieczeń. Jeśli ktoś zapomni o rotacji, system przypomni.

    Dla zespołów zarządzających sekretami i rotacją poświadczeń nowe pole expires_at w Admin API umożliwia budowanie własnych workflow opartych na tych danych. Ręczne śledzenie, który klucz kiedy wygasa, staje się zbędne.

    Co to oznacza w praktyce

    Te zmiany nie są rewolucyjne, ale wskazują na wyraźny trend: Claude z nowymi narzędziami bezpieczeństwa staje się coraz bardziej audytowalny i łatwiejszy do wdrożenia w środowiskach wymagających ścisłej kontroli. Więcej zdarzeń administracyjnych trafia do logów, a operatorzy zyskują narzędzia do zarządzania cyklem życia poświadczeń bez konieczności tworzenia własnych obejść.

    Dla osób wdrażających Claude'a w organizacjach z wymogami compliance, to dwie mniej rzeczy do zmartwień.

    Źródła

  • Anthropic wprowadza kontrolę daty ważności kluczy API — koniec z zapomnianymi tokenami

    Anthropic wprowadza kontrolę daty ważności kluczy API — koniec z zapomnianymi tokenami

    Anthropic wprowadziło nowe mechanizmy kontroli cyklu życia kluczy API w konsoli Claude Platform. Deweloperzy mają teraz możliwość ustawienia czasu wygaśnięcia klucza już w momencie jego tworzenia, wybierając spośród kilku predefiniowanych okresów lub decydując się na dostęp bezterminowy. Zmiana dotyczy zarówno kluczy osobistych, jak i administracyjnych (Admin API), a użytkownicy otrzymają powiadomienia e-mailowe ostrzegające przed zbliżającą się dezaktywacją.

    Kluczowe informacje o aktualizacji

    • Predefiniowane okresy ważności obejmują 3 godziny, 1 dzień, 7 dni oraz 30 dni — dostępna jest także opcja niestandardowego czasu oraz ustawienie „Nigdy”.
    • Powiadomienia e-mail są wysyłane do twórców kluczy z co najmniej 7-dniowym okresem życia — szczegółowe zasady różnią się w zależności od długości ważności.
    • Pole expires_at w Admin API umożliwia zespołom programistyczne śledzenie i audytowanie dat wygaśnięcia wszystkich kluczy.
    • Istniejące klucze pozostają bez zmian — nowe reguły dotyczą wyłącznie tokenów tworzonych po wdrożeniu funkcji.

    Jak działają nowe mechanizmy wygasania

    Podczas tworzenia klucza w konsoli Claude Platform użytkownik ma teraz wyraźny wybór okresu ważności. Opcje są jasne: od krótkich (3 godziny — idealne do testów czy sesji debugowania), przez dłuższe okna produkcyjne (7 lub 30 dni), aż po pełną elastyczność w postaci własnego zakresu czasowego.

    Klucze tworzone z flagą „Nigdy” nie mają daty wygaśnięcia — to rozwiązanie jest przeznaczone głównie dla organizacji korzystających z zewnętrznych systemów zarządzania sekretami, gdzie rotacją zarządza oddzielna warstwa narzędziowa.

    Po przekroczeniu daty ważności klucz przestaje działać. Żądania wysłane z wygasłym tokenem zwracają błąd 401 authentication_error, a jego reaktywacja nie jest możliwa — konieczne jest wygenerowanie nowego klucza.

    Powiadomienia, które ratują przed awarią

    Anthropic dodało do aktualizacji system ostrzeżeń e-mailowych. Zasady są dwustopniowe: dla kluczy utworzonych z okresem co najmniej 14 dni powiadomienie przychodzi na 7 dni przed wygaśnięciem. Jeśli klucz ma żywotność między 7 a 13 dni — ostrzeżenie pojawia się na dobę przed dezaktywacją.

    Tokeny krótsze niż 7 dni nie generują powiadomień, co jest uzasadnione — przy trzygodzinnym oknie czasowym mail dotarłby prawdopodobnie już po fakcie.

    Dla zespołów devopsowych to praktyczne zabezpieczenie. W mniejszych środowiskach, gdzie rotacja kluczy bywa odkładana, e-mail może uchronić przed nagłym przestojem integracji czy pipeline'u CI/CD.

    Admin API i pole expires_at

    Nowe pole expires_at w Admin API zwraca datę wygaśnięcia w formacie RFC 3339 lub wartość null dla kluczy bezterminowych.

    Dzięki temu zespoły mogą budować własne dashboardy monitorujące stan autoryzacji, pisać skrypty audytowe lub integrować sprawdzanie dat z istniejącymi systemami alertowymi. Data wygaśnięcia jest jawnie dostępna w odpowiedzi API, co eliminuje potrzebę zgadywania lub przeszukiwania logów.

    To także dobra wiadomość dla tych, którzy automatyzują zarządzanie dostępem. Pole expires_at ułatwia wykrywanie kluczy zbliżających się do końca cyklu życia i planowanie rotacji bez konieczności zewnętrznego bookkeepingu.

    Co to oznacza dla bezpieczeństwa

    Co to oznacza dla bezpieczeństwa

    Anthropic zaleca regularną rotację poświadczeń i trzymanie kluczy z dala od kodu źródłowego czy promptów. Nowe mechanizmy wspierają te zalecenia, ułatwiając ich stosowanie — deweloper nie musi już pamiętać o ręcznej wymianie tokena, ponieważ platforma automatycznie wymusi odświeżenie po zadanym czasie.

    Dla zespołów pracujących z agentami, serwisami produkcyjnymi czy współdzielonymi workloadami istotna jest możliwość odróżnienia typów kluczy. Platforma rozróżnia klucze osobiste, kont serwisowych i przestrzeni roboczych — dwa pierwsze typy automatycznie tracą ważność, gdy powiązane konto znika z organizacji.

    Nowa funkcjonalność nie zastąpi pełnoprawnego systemu zarządzania sekretami, ale dla wielu średnich i mniejszych wdrożeń może okazać się wystarczającym zabezpieczeniem. Szczególnie tam, gdzie zespół nie ma jeszcze wdrożonej federacji tożsamości czy zautomatyzowanej rotacji przez vault.

    Podsumowanie

    Aktualizacja Anthropic to krok, który realnie zmniejsza ryzyko w codziennej pracy. Wbudowana rotacja kluczy, czytelne ostrzeżenia i programistyczny dostęp do dat wygaśnięcia to zestaw, który powinien być standardem — cieszy, że w końcu trafił do Claude Platform.

    Źródła

  • Gemini CLI z krytyczną łatką bezpieczeństwa – co zmienia wersja v0.51.0-nightly.20260702

    Gemini CLI z krytyczną łatką bezpieczeństwa – co zmienia wersja v0.51.0-nightly.20260702

    Najnowsza wersja nocna Gemini CLI, oznaczona jako v0.51.0-nightly.20260702, wprowadza ważną poprawkę bezpieczeństwa dotyczącą przetwarzania importów pamięci w plikach GEMINI.md. Ta aktualizacja eliminuje podatność typu symbolic-link directory escape, która w określonych warunkach mogła umożliwić odczyt plików spoza zamierzonego katalogu projektu.

    Kluczowe fakty

    • Wersja nocna jest publikowana codziennie o północy UTC i zawiera najnowsze zmiany z głównej gałęzi kodu, ale nie przechodzi pełnej walidacji stabilności.
    • Wersja v0.51.0-nightly.20260702 zamyka lukę w procesorze importu pamięci, uniemożliwiając dowiązaniom symbolicznym wyjście poza dozwolone ścieżki.
    • Podatność dotyczyła plików GEMINI.md, gdzie zaufane importy pamięci mogły być wykorzystane do nieautoryzowanego odczytu plików hosta.
    • Użytkownicy kanału nightly powinni traktować tę aktualizację jako priorytetową, szczególnie w środowiskach, gdzie Gemini CLI operuje na wrażliwych danych projektowych.

    Co dokładnie zostało naprawione

    Problem dotyczył mechanizmu importu pamięci w plikach GEMINI.md, gdzie Gemini CLI przechowuje kontekst i instrukcje dla modelu, takie jak definicje projektu, reguły czy dodatkowe wskazówki. Okazało się, że przy użyciu dowiązań symbolicznych (symlinków) można było „oszukać” procesor importu, aby odczytał zawartość plików znajdujących się poza katalogiem roboczym.

    To stwarzało ryzyko wycieku danych z systemu plików na hosta. Deweloperzy pracujący z zewnętrznymi repozytoriami lub niesprawdzonymi plikami GEMINI.md byli narażeni na nieautoryzowany dostęp do lokalnych zasobów. Poprawka w wersji v0.51.0-nightly.20260702 blokuje tę możliwość – importy pamięci przechodzą teraz rygorystyczną walidację ścieżek, co uniemożliwia symlinkom wydostanie się poza granice projektu.

    Wydanie jest powiązane z konkretnym commitem gff00dacd9 i zostało zidentyfikowane jako build v0.51.0-nightly.20260702. To pokazuje, jak szybko zespół Google reaguje na zgłoszenia bezpieczeństwa – od wykrycia luki do publikacji łatki minęło zaledwie kilkanaście godzin.

    Czym różni się wersja nocna od stabilnych wydań

    Kanał nightly Gemini CLI to najbardziej dynamiczny strumień aktualizacji. Zespół Google publikuje tu codzienne snapshoty głównej gałęzi kodu – wszystko, co trafiło na main branch o północy UTC. Oficjalna dokumentacja Gemini CLI podkreśla, że to wydania z „najnowszymi zmianami”, przy których „należy zakładać obecność oczekujących walidacji i problemów”.

    Dla porównania, kanał stabilny (stable) przechodzi przez pełen cykl testów i jest rekomendowany do codziennego użytku produkcyjnego. Preview to miejsce dla funkcji eksperymentalnych gotowych na wczesne opinie. Wersja nocna to surowy front-end developmentu – idealny do testowania najnowszych funkcji, ale też obarczony ryzykiem regresji czy niedopracowanych modułów.

    Z tego powodu łatka bezpieczeństwa w kanale nightly ma szczególne znaczenie. Zanim trafi ona do preview i stable, użytkownicy wersji rozwojowych operują bez tego zabezpieczenia. Deweloperzy, którzy polegają na Gemini CLI w workflow web developmentu, AI toolingu czy DevOps, powinni rozważyć szybką aktualizację.

    Dlaczego to istotne dla zespołów deweloperskich

    Gemini CLI zyskuje na popularności jako narzędzie CLI do współpracy z modelami Gemini bezpośrednio z terminala. Deweloperzy używają go do generowania kodu, analizy repozytoriów i automatyzacji zadań w web developmencie. Narzędzie ma dostęp do lokalnego systemu plików, zmiennych środowiskowych i konfiguracji projektów – dlatego każda luka związana z eskalacją ścieżek czy odczytem plików jest potencjalnie groźna.

    Wersja v0.51.0-nightly.20260702 pokazuje, że nawet w szybkim cyklu nightly Google priorytetowo traktuje kwestie bezpieczeństwa. Przy tempie jednego buildu dziennie i stale rosnącej bazie użytkowników (projekt ma ponad 107 tysięcy gwiazdek na GitHubie), transparentność takich poprawek staje się kluczowa dla utrzymania zaufania społeczności deweloperskiej.

    Źródła

  • Codex 0.141.0 stawia na bezpieczne zdalne wykonanie i rozbudowę wtyczek

    Codex 0.141.0 stawia na bezpieczne zdalne wykonanie i rozbudowę wtyczek

    OpenAI wprowadziło wersję 0.141.0 swojego narzędzia CLI Codex, koncentrując się na bezpieczeństwie komunikacji oraz elastyczności ekosystemu wtyczek. Zdalne egzekutory zyskały szyfrowane połączenia end-to-end za pomocą protokołu Noise, a deweloperzy mogą teraz korzystać z nowych katalogów w marketplace oraz aktywować serwery MCP na poziomie pojedynczego wątku. Dodatkowo, wprowadzono usprawnienia w kliencie czasu rzeczywistego oraz optymalizacje wydajności dla sesji z dużą liczbą narzędzi.

    Kluczowe zmiany w skrócie

    • Zdalne egzekutory korzystają teraz z szyfrowanych kanałów Noise relay, które zastąpiły wcześniejsze połączenia WebSocket z tokenami bearer.
    • Cross-platform zachowuje natywne katalogi robocze, powłoki i ścieżki uprawnień systemu plików po obu stronach połączenia.
    • Marketplace wtyczek wzbogacił się o katalog "created-by-me" oraz wyselekcjonowane katalogi związane z autoryzacją.
    • Serwery MCP można teraz aktywować dla wybranych wtyczek egzekutora na poziomie wątku.
    • Wydajność poprawiła się dzięki cache'owaniu wyszukiwania narzędzi oraz eliminacji zbędnych kopii requestów.

    Noise relay zamiast WebSocketów – co to zmienia

    Do tej pory komunikacja między app-serverem a exec-serverem opierała się na tokenach bearer przesyłanych przez WebSocket. Choć to proste rozwiązanie, infrastruktura pośrednicząca miała teoretyczny dostęp do ruchu w plaintextcie. Wersja 0.141.0 wprowadza uwierzytelnione, szyfrowane kanały Noise relay, co oznacza, że warstwa relayowa nie widzi treści wykonywanych poleceń ani ich wyników.

    Dla zespołów pracujących w rozproszonych środowiskach oraz korzystających z hostingu agentów to istotna zmiana w modelu bezpieczeństwa. Noise to lekki protokół kryptograficzny, który dobrze sprawdza się w scenariuszach z niskim narzutem. Szyfrowanie odbywa się bezpośrednio od klienta do serwera docelowego, bez przystanków na deszyfrację.

    Codex zajął się również cross-platformowymi rozbieżnościami. Zdalne egzekutory zachowują natywne katalogi robocze i powłoki, a ścieżki uprawnień systemu plików pozostają spójne niezależnie od systemu, na którym działa app-server i exec-server. Automatyzując CI na Windowsie i łącząc się z Maca, nie stracisz kontekstu ścieżek.

    Wtyczki i marketplace idą do przodu

    Rozbudowa możliwości wtyczek to drugi filar tego wydania. W marketplace pojawił się katalog "created-by-me", który pokazuje wtyczki stworzone przez zalogowanego użytkownika, co ułatwia zarządzanie własnym ekosystemem narzędzi. Dodatkowo, wprowadzono wyselekcjonowane katalogi związane z autoryzacją, co oznacza, że dostępne w marketplace wtyczki mogą się różnić w zależności od poziomu dostępu.

    Największym krokiem naprzód jest jednak możliwość aktywacji serwerów MCP (stdio) bezpośrednio z poziomu wtyczek egzekutora i to na poziomie wątku. Architektura staje się bardziej modularna, co pozwala na aktywację różnych zestawów narzędzi dla różnych sesji bez konieczności przeładowywania całego środowiska. Udoskonalono także routing autoryzacji przy odkrywaniu wtyczek oraz atrybucji marketplace, a także poprawiono widoczność limitów oraz księgowanie wyników importu.

    Realtime i wydajność dla ciężkich sesji

    Klient czasu rzeczywistego zyskał nowe opcje sterowania mową, co ma na celu lepszą kontrolę nad interakcjami głosowymi podczas sesji na żywo.

    Optymalizacje wprowadzono także w zakresie wydajności. W sesjach z dużą liczbą narzędzi występowały problemy z nadmiarowymi kopiami requestów oraz powtórnymi przeszukiwaniami historii. Zespół wprowadził cache'owanie wyszukiwania narzędzi i wyeliminował zbędne kopiowanie, co skutkuje niższymi opóźnieniami oraz mniejszym zużyciem pamięci, szczególnie w scenariuszach typowych dla vibe codingu, gdzie agent nieustannie uruchamia narzędzia i przegląda kontekst.

    Warto również odnotować poprawki niezawodności wykonania na Windowsie oraz limit 64 MB na obrazy w pamięci. Te zmiany pokazują, że wersja 0.141.0 to nie tylko nowe funkcje, ale także systematyczne rozwiązywanie problemów w codziennym użytkowaniu.

    Co z tego wynika dla deweloperów

    Codex 0.141.0 wprowadza istotne zmiany w architekturze rozproszonej. Szyfrowane kanały Noise odpowiadają na potrzeby zespołów, które nie chcą ufać infrastrukturze pośredniczącej. Rozbudowa wtyczek oraz aktywacja serwerów MCP na poziomie wątku wskazują na kierunek ku bardziej modułowym środowiskom deweloperskim, gdzie agent łączy narzędzia w locie, bez konieczności restartów i przeładowań konfiguracji.

    Jeśli pracujesz z dużymi sesjami narzędziowymi lub stawiasz własne zdalne egzekutory, aktualizacja jest warta uwagi ze względu na poprawę wydajności. Pozostałe zmiany stanowią solidny fundament pod przyszłe, bardziej złożone workflow.

    Źródła

  • Claude Code 2.1.183 blokuje destrukcyjne komendy — nowa era bezpieczeństwa w trybie auto

    Claude Code 2.1.183 blokuje destrukcyjne komendy — nowa era bezpieczeństwa w trybie auto

    Anthropic wypuścił 19 czerwca 2026 roku wersję Claude Code 2.1.183, która wprowadza blokady na destrukcyjne operacje Git i infrastrukturalne w trybie automatycznym. To pierwsza aktualizacja, która zamiast ostrzeżeń wprowadza konkretne techniczne bariery — agent nie wyczyści lokalnych zmian ani nie zniszczy środowiska bez wyraźnego polecenia użytkownika.

    Kluczowe zmiany w pigułce

    • Destrukcyjne komendy Git — git reset --hard, git checkout -- ., git clean -fd i git stash drop są blokowane w trybie auto, chyba że użytkownik sam zażądał odrzucenia lokalnych zmian.
    • Operacje infrastrukturalne terraform destroy, pulumi destroy i cdk destroy również podlegają blokadzie, dopóki docelowy stack nie zostanie wskazany bezpośrednio przez użytkownika.
    • Nowa pomoc konfiguracyjna /config --help wyświetla klawisze skrótów dla ustawień, co upraszcza zarządzanie w zespołach.
    • Poprawki błędów obejmują korupcję TUI w Windows Terminal, zrywanie komunikacji subagentów i awarie zadań w tle.

    Koniec z przypadkowym resetem repozytorium

    Tryb auto w Claude Code był dotychczas miejscem, gdzie agent mógł wykonać niemal każdą operację bez pytania. Problem polegał na tym, że jedno nieprecyzyjne polecenie mogło spowodować, że git reset --hard wyczyściłby godziny pracy. Teraz to się zmienia — blokada działa nawet wtedy, gdy model uzna, że reset jest "najlepszym rozwiązaniem".

    Co ważne, ochrona nie kończy się na reset. Blokowane są także git checkout -- . (nadpisanie wszystkich zmodyfikowanych plików), git clean -fd (usunięcie nieśledzonych plików i katalogów) oraz git stash drop (bezpowrotne usunięcie schowka). Wersja 2.1.183 wprowadza dodatkowe ograniczenie: git commit --amend jest zablokowany, jeśli poprawiany commit nie został utworzony przez agenta w bieżącej sesji. Oznacza to, że nie można przypadkowo nadpisać pracy innego developera.

    Infrastruktura też bezpieczniejsza

    DevOpsi mogą odetchnąć z ulgą. Komendy terraform destroy, pulumi destroy i cdk destroy, które mogą usunąć środowisko produkcyjne jednym kliknięciem, są traktowane tak samo jak destrukcyjne operacje Git. Agent wykona je tylko wtedy, gdy użytkownik wskaże konkretny stack do zniszczenia.

    W praktyce oznacza to, że nawet jeśli model błędnie uzna, że "trzeba posprzątać staging", infrastruktura nie zniknie bez ludzkiej decyzji. W kontekście CI/CD i Infrastructure as Code, ta zmiana realnie zmniejsza ryzyko katastrofy wdrożeniowej.

    Konfiguracja bez zgadywania

    Konfiguracja bez zgadywania

    Zarządzanie ustawieniami Claude Code w środowiskach zespołowych bywało trudne — każdy musiał pamiętać nazwy kluczy i ich dokładną składnię. Aktualizacja 2.1.183 dodaje /config --help, które wypisuje wszystkie dostępne skróty konfiguracyjne. Teraz wystarczy rzucić okiem, aby wiedzieć, jak przełączyć motyw, zmienić model czy dostosować limity.

    Nowością dla tych, którzy nie chcą linków do sesji claude.ai w commitach, jest attribution.sessionUrl, które pozwala całkowicie pominąć URL w opisach commitów i pull requestów. To mała zmiana, ale istotna dla osób pracujących w trybie Remote Control.

    Bugi, które naprawdę przeszkadzały

    Bugi, które naprawdę przeszkadzały

    Lista poprawek w tej wersji jest konkretna. Windows Terminal przestał korumpować TUI podczas dłuższych sesji, a subagenty nie będą się gubić przy generowaniu tytułów sesji. Problem z wywołaniami WebSearch w subagentach (puste wyniki) także został rozwiązany.

    Szczególnie uciążliwy był błąd z zadaniami w tle: zadanie uruchomione przez "teammate'a" było zabijane w momencie, gdy ten kończył swoją turę. W 2.1.183 ten problem został usunięty. Dodatkowo powiadomienia z harmonogramu i webhooków nie mogą już zatwierdzać oczekujących akcji ani zmieniać tytułu sesji w trybie auto, co poprawia bezpieczeństwo.

    Co to zmienia w codziennej pracy

    Dla web developerów i zespołów DevOps ta aktualizacja przesuwa Claude Code z kategorii "użyteczne, ale ryzykowne" do "użyteczne i przewidywalne". Vibe coding czy agent-assisted development przestają być ryzykowne — agent nie zresetuje brancha, nie nadpisze cudzego commita i nie zniszczy klastra, dopóki człowiek nie wyda wyraźnego polecenia.

    Takie blokady powinny być standardem od dawna. Dobrze, że pojawiły się teraz, gdy coraz więcej zespołów testuje agentowe narzędzia w produkcyjnych pipeline'ach.

    Źródła

  • Factory otwiera się na npm – nowe wsparcie dla pluginów i zabezpieczenia sesji w wersji v0.150.0

    Factory otwiera się na npm – nowe wsparcie dla pluginów i zabezpieczenia sesji w wersji v0.150.0

    Najnowsza aktualizacja Factory (v0.150.0) wprowadza wsparcie dla pluginów publikowanych jako pakiety npm. Do tej pory rozszerzenia można było dystrybuować na kilka sposobów, ale teraz dołącza do nich najpopularniejszy rejestr ekosystemu JavaScript. Zmiana jest istotna, ponieważ npm to domyślne źródło zależności dla wielu zespołów developerskich. Dodatkowo, zespół Factory wprowadził mechanizm potwierdzenia przy zamykaniu aktywnych sesji Droid, poprawki wydajności dla długich czatów oraz lepszą widoczność statusu rozliczeniowego.

    Kluczowe informacje o aktualizacji

    • npm jako źródło pluginów – w definicji marketplace’u można teraz wskazać pakiet npm wraz z opcjonalną wersją, rejestrem i tokenem do prywatnych repozytoriów.
    • Bezpieczna instalacja z wyłączonymi skryptami – Droid pobiera pluginy przez npm install z flagami --ignore-scripts --no-save --no-audit --no-fund, a kod jest kopiowany do cache’u; żaden skrypt cyklu życia się nie uruchamia.
    • Potwierdzenie przed zamknięciem – nowy monit zapobiega przypadkowemu przerwaniu pracy Droid, gdy sesja jest w toku.
    • Optymalizacja długich czatów – poprawki wydajnościowe zmniejszają opóźnienia przy rozbudowanych workflow, gdzie kontekst rośnie z każdą turą.
    • Czytelniejszy status rozliczeniowy – użytkownicy widzą teraz stan konta wyraźniej podczas korzystania z narzędzia.

    Jak działa nowe źródło pluginów

    Factory definiuje plugin przez wpis w pliku marketplace. Nowa składnia dla źródła npm jest prosta. Deweloper podaje nazwę pakietu (obsługiwane są też pakiety z zakresem, np. @firma/nazwa), opcjonalną wersję zgodną z semver lub dist-tagiem oraz – jeśli plugin znajduje się w prywatnym rejestrze – adres URL rejestru HTTPS i nazwę zmiennej środowiskowej z tokenem.

    Brak wersji oznacza, że Droid automatycznie pobierze najnowszą oznaczoną jako latest. Dla zespołów korporacyjnych to wygodne rozwiązanie – nie trzeba budować obejść, aby podłączyć prywatne repozytorium. Wystarczy podać registry i authTokenEnvVar, a Factory respektuje te ustawienia bez grzebania w globalnej konfiguracji npm.

    Zespół Factory zadbał o bezpieczeństwo – Droid wykonuje npm install w tymczasowym katalogu roboczym, a następnie kopiuje rozpakowany pakiet do cache’a. Wszystkie skrypty cyklu życia są blokowane, co oznacza, że nie uruchamiają się preinstall, install ani postinstall. W ostatnich latach ataki na łańcuch dostaw przez npm stały się powszechne – złośliwe pakiety wykorzystywały instalacyjne skrypty do kradzieży tokenów czy eksfiltracji sekretów CI/CD. GitHub ogłosił, że w npm v12 domyślnie wyłączy automatyczne wykonywanie tych skryptów. Factory podąża tą samą drogą.

    Sesje pod ochroną

    Nowy monit potwierdzenia przed zamknięciem może wydawać się drobiazgiem, ale każdy, kto przypadkowo przerwał agentowi pracę nad złożonym zadaniem, wie, jak irytujące to może być. Droid potrafi wykonywać wieloetapowe operacje: klonuje repozytoria, modyfikuje pliki, odpytuje API. Przypadkowe wciśnięcie Ctrl+C mogło zostawić projekt w niedokończonym stanie. Teraz Factory pyta, czy na pewno chcesz wyjść, gdy sesja jest aktywna. To drobna zmiana, która oszczędza nerwy.

    Dodatkowo poprawiono wydajność długich rozmów z Droidem. W rozbudowanych workflow, gdzie kontekst rośnie z każdą kolejną turą, mniejsze opóźnienia oznaczają płynniejszą pracę. Zespół Factory nie podał szczegółów technicznych, ale efekt jest odczuwalny szczególnie przy sesjach trwających przez wiele interakcji.

    Dlaczego to ma znaczenie

    Rynek narzędzi AI dla developerów staje się coraz bardziej konkurencyjny. Cursor, Windsurf, Cline – każdy szuka swojej niszy. Factory stawia na rozszerzalność. Pluginy to nie tylko komendy i umiejętności, ale też Droidy, hooki i serwery MCP, które można udostępniać między projektami i zespołami. Wsparcie dla npm eliminuje trudności związane z dystrybucją przez mniej standardowe kanały. Dla web developerów i zespołów DevOps oznacza to, że łatwiej będzie budować własne, firmowe rozszerzenia i dzielić się nimi jak z każdą inną zależnością JavaScript. Factory pokazuje, że korzysta z infrastruktury, którą developerzy już znają i której ufają.

    Źródła

  • Factory v0.148.1: podpisane binarki CLI stabilizują środowiska odcięte od sieci

    Factory v0.148.1: podpisane binarki CLI stabilizują środowiska odcięte od sieci

    Factory wydało wersję v0.148.1, która rozwiązuje istotny problem dla zespołów pracujących w środowiskach air-gapped. Aktualizacja zapewnia, że wszystkie binarki CLI są teraz poprawnie podpisywane i publikowane, co umożliwia instalacjom offline pobieranie najnowszych wersji bez ryzyka związanego z niezweryfikowanym oprogramowaniem.

    Poprawka trafiła do użytkowników 14 czerwca 2026 roku jako część wydania CLI v0.148.1 i Desktop v0.105.0. Choć na pierwszy rzut oka wygląda to na drobną zmianę konfiguracyjną, dla branż objętych ścisłymi regulacjami bezpieczeństwa oznacza koniec ręcznych obejść i potencjalnych luk w łańcuchu dostaw.

    Kluczowe fakty

    • Binarki CLI dla środowisk air-gapped są teraz podpisywane i publikowane, eliminując ryzyko instalacji nieautoryzowanych wersji.
    • Aktualizacja jest częścią szerszego pakietu usprawnień korporacyjnych Factory, obejmującego kontrolę ruchu sieciowego i zarządzanie logami.
    • Wdrożenia w sektorze obronnym i administracji państwowej korzystają z trybu fully air-gapped, gdzie Factory Cloud nie jest osiągalny podczas działania Droidów.
    • Weryfikacja binarek odbywa się przez artifact repositories i procesy offline, co wymaga zaufanego podpisu cyfrowego na każdym etapie dystrybucji.

    Dlaczego podpisywanie binarek ma znaczenie w odciętych środowiskach

    W standardowym modelu SaaS aplikacja pobiera aktualizacje bezpośrednio z serwerów producenta. Środowiska air-gapped odwracają tę logikę – wszystko, co trafia do wewnętrznej sieci, musi przejść przez bramki bezpieczeństwa, skanery i ręczne audyty. Nie ma tu miejsca na automatyczne pobieranie paczek z internetu.

    Droidy Factory działające w takim reżimie polegają na artefaktach importowanych przez repozytoria offline. Jeśli binarka CLI nie jest podpisana, system nie może potwierdzić jej integralności. W takim przypadku administratorzy albo blokują instalację, albo – co gorsza – dopuszczają ją na ślepo, narażając infrastrukturę na ataki typu supply chain.

    Poprawka z v0.148.1 eliminuje ten dylemat. Teraz każda wersja CLI przeznaczona dla środowisk izolowanych przechodzi pełną ścieżkę podpisywania, zanim trafi do kanałów dystrybucyjnych. Dla zespołów DevOps oznacza to mniej ręcznej pracy przy weryfikacji i krótszy czas od wydania nowej funkcji do jej wdrożenia na produkcji.

    Szerszy kontekst: kontrola nad ruchem i modelami

    Warto spojrzeć na tę aktualizację w kontekście całej strategii Factory dla klientów enterprise. Dokumentacja wdrożeniowa platformy opisuje model, w którym nie tylko binarki, ale też punkty końcowe modeli AI i kolektory OTEL pozostają wewnątrz izolowanej sieci.

    Factory umożliwia uruchamianie Droidów w konfiguracji fully air-gapped, gdzie jedynym połączeniem ze światem zewnętrznym jest zaplanowany import artefaktów. To domyślny wzorzec dla sektorów takich jak obronność czy administracja rządowa, gdzie wyciek danych przez niekontrolowany ruch sieciowy jest niedopuszczalny.

    Ostatnie miesiące przyniosły też inne usprawnienia w tym obszarze: lepszą widoczność połączeń MCP, nowe kontrolki organizacyjne dla automatycznych aktualizacji, usprawnione zarządzanie logami i odświeżone procesy uwierzytelniania. Wszystko to składa się na obraz platformy, która działa w izolacji w sposób przewidywalny i audytowalny.

    Co to oznacza dla zespołów developerskich

    Dla programistów pracujących z Factory na co dzień, v0.148.1 nie przynosi nowych funkcji w interfejsie ani zmian w API. To wydanie ma charakter czysto infrastrukturalny. Jednak jego wpływ na stabilność środowisk CI/CD może być odczuwalny natychmiast.

    Zespoły utrzymujące pipeline'y w odciętych sieciach często borykają się z problemem nieaktualnych narzędzi. Każda aktualizacja CLI wymagała dotąd sprawdzania sum kontrolnych, ręcznego podpisywania i konfiguracji zaufanych źródeł. Teraz ten proces jest zautomatyzowany po stronie Factory, a administratorzy otrzymują gotowe, zweryfikowane paczki.

    To jedna z tych poprawek, których nikt nie zauważa, dopóki nie przestanie działać. Ale właśnie takie detale decydują o tym, czy platforma nadaje się do użytku w środowiskach o zaostrzonych wymogach bezpieczeństwa.

    Źródła

  • Qwen-Code 0.18.1 stawia na bezpieczeństwo i stabilność długich sesji agentowych

    Qwen-Code 0.18.1 stawia na bezpieczeństwo i stabilność długich sesji agentowych

    Alibaba wypuściła 15 czerwca 2026 roku wersję 0.18.1 swojego terminalowego agenta AI – Qwen-Code 0.18.1. To wydanie nie wprowadza jednej dużej funkcji, lecz koncentruje się na kluczowych aspektach, które są istotne dla użytkowników korzystających z narzędzia na co dzień: zwiększonej autonomii i mniejszej liczbie awarii podczas długotrwałych zadań.

    Co konkretnie zmieniono

    • Twarda blokada dostępu do shella w trybie demona – teraz wymaga jawnego potwierdzenia, co eliminuje przypadkowe ekspozycje sesji powłoki.
    • Zapisywanie zbyt dużych wyników narzędzi na dysku – zabezpieczenie przed wyczerpaniem pamięci przy analizie buildów czy wieloplikowych diffów.
    • Przekazywanie próśb o uprawnienia z podagentów do sesji nadrzędnej – zwiększa kontrolę nad działaniami procesów działających w tle.
    • Poprawki telemetrii ACP dla procesów demona – zapewniają ciągłość śledzenia kontekstu między zadaniami, co jest istotne przy debugowaniu w środowiskach produkcyjnych.

    Mniej przypadków, więcej kontroli

    Zespół Qwen postawił na dojrzałość narzędzia. Najważniejszym sygnałem tej wersji jest przesunięcie w stronę bezpieczniejszej autonomicznej egzekucji. Wcześniejsze wersje działały sprawnie, dopóki nie napotykały niespodziewanych sytuacji. Teraz dodano mechanizmy, które mają zapobiegać problemom.

    Blokada shella w trybie demona odpowiada na realny problem. Gdy agent działa w tle przez dłuższy czas, może dojść do przypadkowej ekspozycji sesji. Qwen-Code 0.18.1 wprowadza twardą bramkę – bez jawnego potwierdzenia nie ma dostępu do powłoki. To proste, ale skuteczne rozwiązanie.

    Mechanizm przechwytywania próśb o uprawnienia również działa na korzyść użytkowników. Jeśli podagent potrzebuje dodatkowych praw, jego żądanie trafia do sesji nadrzędnej, co pozwala zespołom DevOps szybciej reagować na nieoczekiwane zachowania.

    Stabilność przy dużych obciążeniach

    Stabilność przy dużych obciążeniach

    Kolejnym ważnym aspektem tego wydania jest stabilność. Qwen-Code 0.18.1 zapisuje teraz zbyt duże wyniki działania narzędzi bezpośrednio na dysk, zamiast trzymać je w pamięci. To istotne dla osób analizujących logi buildów, przeglądających duże repozytoria lub pracujących z wieloetapowymi zadaniami, gdzie pojedynczy wynik może ważyć setki megabajtów.

    Wcześniej takie sytuacje często kończyły się wyczerpaniem pamięci i restartem sesji. Teraz agent zapisuje nadmiarowe dane na dysku i odwołuje się do nich w razie potrzeby. To zmiana, która przy długotrwałych zadaniach ma znaczący wpływ.

    Dodatkowo, wyniki przeszukiwania kodu mogą teraz spełniać warunki wcześniejszych sprawdzeń odczytu, co ogranicza zbędne ponowne przeszukiwania. Mniej redundantnych operacji przekłada się na krótszy czas wykonania i mniejsze zużycie zasobów.

    Drobiazgi, które robią różnicę

    Drobiazgi, które robią różnicę

    Wśród mniejszych poprawek warto odnotować aktualizację dokumentacji – usunięto nieaktualne odwołania do listy modeli Coding Plan oraz inne przestarzałe referencje. To ważne, aby dokumentacja była zgodna z rzeczywistością, zwłaszcza w przypadku narzędzia, które rozwija się tak szybko jak Qwen-Code 0.18.1.

    Poprawki telemetrii dotyczące propagacji śladów ACP w procesach demona również są istotne. Dzięki nim zespoły korzystające z Qwen-Code 0.18.1 w pipeline'ach produkcyjnych mogą lepiej śledzić, co agent robił podczas długiego zadania, ponieważ kontekst śledzenia nie urywa się przy przełączaniu między procesami.

    Co dalej z ekosystemem

    Wersja 0.18.1 nie jest rewolucyjna, ale pokazuje, że zespół Qwen słucha użytkowników, którzy sygnalizowali problemy ze stabilnością przy dłuższych zadaniach oraz potrzebę lepszej kontroli nad działaniami agentów w tle. Kierunek rozwoju jest jasny: mniej efektownych nowości, więcej solidności.

    Warto zauważyć, że Qwen-Code 0.18.1 rozwija się szybko – wkrótce po tej aktualizacji pojawiły się nowe wersje z obsługą protokołu MCP 2026, integracją z zewnętrznymi serwerami MCP oraz zaawansowanymi workflow. To sugeruje, że ta wersja była przystankiem technicznym przed większymi zmianami architektonicznymi, które już są w drodze.

    Źródła