Kategoria: Oprogramowanie

  • Cursor trafia na iPhone’a — aplikacja mobilna już w publicznej becie

    Cursor trafia na iPhone’a — aplikacja mobilna już w publicznej becie

    Cursor udostępnił w publicznej becie natywną aplikację na iPhone’a, która umożliwia programistom zarządzanie agentami kodującymi w chmurze oraz na lokalnych maszynach bezpośrednio z telefonu. Od 29 czerwca 2026 roku użytkownicy płatnych planów mogą uruchamiać, monitorować i zatwierdzać pull requesty z iPhone’a lub iPada bez potrzeby korzystania z laptopa.

    Aplikacja wprowadza funkcję Remote Control, która łączy się z agentami działającymi na komputerze użytkownika. Wystarczy, że maszyna pozostanie włączona, a z telefonu można wydawać polecenia, sprawdzać postępy i przeglądać wygenerowane zmiany. Cursor dodaje również powiadomienia push oraz Live Activities na ekranie blokady, co pozwala użytkownikowi śledzić postępy agenta nawet przy wyłączonym ekranie.

    Kluczowe informacje

    • Aplikacja Cursor na iPhone’a jest dostępna w publicznej becie dla użytkowników płatnych planów — od Start po Enterprise.
    • Remote Control umożliwia zdalne sterowanie agentami uruchomionymi na własnym komputerze, także bez agentów chmurowych.
    • Agenci chmurowi działają na izolowanych maszynach wirtualnych z pełnym środowiskiem deweloperskim, testują zmiany i generują artefakty do weryfikacji.
    • Wymagania systemowe to iOS 16 lub nowszy na iPhonie oraz iPadOS 16 na iPadzie — starsze urządzenia nie są wspierane.

    Jak wygląda praca z poziomu telefonu

    Po otwarciu aplikacji użytkownik wybiera repozytorium i uruchamia agenta — proces ten przypomina doświadczenie z desktopowego Cursora. Agent może zaimplementować funkcję, zbadać błąd, odpowiedzieć na pytania dotyczące kodu lub przygotować zmiany do przeglądu. Użytkownik ma do dyspozycji komendy slash oraz wprowadzanie głosowe, co ułatwia opisanie zadania bez użycia klawiatury.

    Gdy agent działa w chmurze, jego sesja jest całkowicie niezależna od komputera użytkownika. Maszyna wirtualna Cursora testuje kod, tworzy zrzuty ekranu i nagrania demonstracyjne, a programista przegląda efekty na telefonie. Jeśli zmiany wymagają sprawdzenia lokalnie, sesję można przenieść z chmury na własny sprzęt — i odwrotnie. To samo dotyczy agentów lokalnych: za pomocą Remote Control można przejąć nad nimi kontrolę z aplikacji mobilnej, wysyłać dodatkowe instrukcje i śledzić postępy.

    Kiedy praca jest gotowa, aplikacja prezentuje różnice w zmianach oraz wygenerowany pull request. Użytkownik może przejrzeć kod, zostawić uwagi dla agenta i scalić PR — wszystko bez powrotu do komputera.

    Dla kogo to ma znaczenie

    Dla kogo to ma znaczenie
    Źródło: cursor.com

    Aplikacja nie zastępuje edytora kodu. Jest to raczej warstwa kontrolna i decyzyjna dla zespołów, które potrzebują szybkiej reakcji, nawet poza biurkiem. Przydaje się w sytuacjach awaryjnych — gdy ktoś otrzymuje alert podczas lunchu, może uruchomić agenta do analizy błędu i po powrocie mieć gotowy PR z propozycją poprawki.

    Aplikacja sprawdza się również przy zgłoszeniach klientów: jeśli awaria wymaga natychmiastowego działania, agent uruchomiony z telefonu odtwarza problem i pracuje nad rozwiązaniem. Zespół Cursora korzysta z aplikacji także do zbierania wizualnego feedbacku — zrzut ekranu z adnotacjami wysłany do agenta staje się kontekstem do zmian w interfejsie.

    Współpraca z chmurą oznacza, że długotrwałe zadania nie blokują lokalnego środowiska. Agent chmurowy działa asynchronicznie, ma własne narzędzia i zasoby, dzięki czemu może dłużej iterować, zbliżając się do kodu gotowego do scalenia.

    Ograniczenia i stan rozwoju

    Aplikacja jest w fazie beta — działanie niektórych funkcji może się zmieniać, a część mechanizmów jest wciąż rozwijana. Remote Control wymaga, aby komputer pozostał włączony i online; w ustawieniach Cursora na desktopie można włączyć opcję „Keep this computer awake”, która zapobiega uśpieniu maszyny. Funkcja nie działa przy zamkniętej pokrywie laptopa.

    Wymóg iOS 16 wyklucza starsze modele iPhone’ów i iPadów, co ogranicza bazę użytkowników. Należy również pamiętać, że aplikacja służy do kontroli agentów i przeglądu zmian — nie jest pełnoprawnym środowiskiem programistycznym.

    Mimo tych ograniczeń Cursor na iPhone’a wyznacza konkretny kierunek: chodzi o przeniesienie decyzyjności i nadzoru nad agentami tam, gdzie akurat znajduje się programista. Niezależnie od tego, czy to codzienna praca zdalna, czy szybka reakcja na awarię — telefon staje się narzędziem do zarządzania kodem.

    Źródła

  • Cline SDK v0.0.64 naprawia liczenie tokenów i pliki z Windows

    Cline SDK v0.0.64 naprawia liczenie tokenów i pliki z Windows

    Nowa wersja SDK Cline, oznaczona numerem 0.0.64, została udostępniona w repozytorium 17 lipca 2026 roku. Wprowadza dwie istotne poprawki dotyczące kompatybilności. Aktualizacja koncentruje się na ujednoliceniu obsługi maksymalnych tokenów wyjściowych w różnych ścieżkach providerów oraz na poprawnym parsowaniu plików zapisanych przez edytory Windows. Choć zmiany są technicznie niewielkie, eliminują uciążliwe błędy, które mogły zakłócić sesję agenta w nieoczekiwanym momencie.

    Kluczowe zmiany

    • Jednolita obsługa limitów tokenów dla trasowania przez bramkę, providera OpenAI i modeli reasoningowych
    • Pliki z BOM-em UTF-8 są teraz poprawnie parsowane — dotyczy frontmatter w Markdown i plików z instrukcjami
    • Automatyczna konwersja plików między Windows a innymi systemami — SDK radzi sobie z tym samodzielnie
    • Poprawki na styku providerów eliminują niespójne zachowania przy generowaniu kodu i wywołaniach narzędzi

    Tokeny pod kontrolą — bez względu na providera

    Problem z maksymalną liczbą tokenów wyjściowych był uciążliwy. Gdy konfiguracja ustalała limit, ale SDK nie przekazywało go poprawnie do konkretnego providera, model mógł przestać generować odpowiedź w trakcie wywołania narzędzia. W niektórych przypadkach zachowywał się inaczej, w zależności od tego, czy żądanie szło bezpośrednio przez OpenAI, przez bramkę, czy do modelu reasoningowego.

    Poprawka w wersji 0.0.64 nie zwiększa samego limitu, lecz zmienia sposób, w jaki SDK go przekazuje. Umożliwia to, aby skonfigurowana wartość docierała tam, gdzie powinna, i była respektowana przez każdą ścieżkę. Dla osób generujących długie pliki konfiguracyjne lub skomplikowane struktury kodu, ta zmiana oznacza mniej niespodzianek przy kompilacji.

    Warto dodać, że późniejsze wydania SDK wprowadzały dodatkowe poprawki dla modeli reasoningowych, które mogły pomijać kompaktowanie, gdy system niewłaściwie honorował jawny limit. To pokazuje, że zarządzanie budżetem tokenów pozostaje aktualnym tematem w ekosystemie agentów AI.

    BOM, którego już nie widać

    Druga zmiana dotyczy znacznika kolejności bajtów (BOM) w plikach UTF-8, który jest często dodawany przez starsze edytory w systemie Windows. Ten niewidoczny znacznik może skutecznie zakłócić parsowanie.

    Gdy plik z instrukcjami dla Cline zaczynał się od BOM-a, parser nie znajdował oczekiwanego delimitera frontmatter na pierwszej pozycji. W rezultacie odrzucał plik jako niepoprawny lub, co gorsza, interpretował go w sposób prowadzący do trudnych do zdiagnozowania błędów w działaniu agenta.

    Od wersji 0.0.64 SDK usuwa BOM-a przed parsowaniem. Dotyczy to plików Markdown z frontmatter w YAML, plików z instrukcjami użytkownika oraz reguł i workflow. Użytkownicy nie muszą już ręcznie konwertować plików do UTF-8 bez BOM za każdym razem, gdy edytują je w notatniku i wrzucają do repozytorium.

    Dlaczego to ma znaczenie

    Cline SDK to open-source'owy runtime agenta, wykorzystywany zarówno w rozszerzeniach IDE, jak i przez zespoły budujące własne aplikacje agentowe. Dla osób pracujących w web dev i DevOps obie poprawki są istotne, ponieważ dotyczą kluczowych punktów styku między systemami.

    Pierwszy problem dotyczy granicy między providerami modeli — niespójne limity tokenów mogą prowadzić do niekompletnego generowania kodu. Drugi problem to granica między systemami plików — pliki utworzone w Windows mogą nie działać poprawnie w środowisku linuksowym.

    Te zmiany mogą być niewidoczne, dopóki coś się nie zepsuje. Jednak w momencie wystąpienia problemu mogą powodować więcej frustracji niż skomplikowane błędy.

    Źródła

  • Cursor wchodzi na iOS — agenty AI teraz nadzorujesz z telefonu

    Cursor wchodzi na iOS — agenty AI teraz nadzorujesz z telefonu

    Firma Cursor udostępniła 29 czerwca 2026 roku natywną aplikację mobilną na iOS w publicznej becie. Użytkownicy wybranych płatnych planów mogą teraz uruchamiać, monitorować i zarządzać agentami AI bezpośrednio z iPhone'a lub iPada. Aplikacja nie jest miniwersją desktopowego IDE, lecz centrum dowodzenia dla agentów działających w chmurze lub na komputerze użytkownika.

    Kluczowe informacje o premierze

    • Cursor iOS jest dostępny w publicznej becie dla planów Premium, Super, Ultra, Teams, Enterprise oraz starszych planów Start, Pro, Pro+ i Ultra — pod warunkiem dostępu do Cloud Agents.
    • Agenci w chmurze uruchamiani z telefonu pracują w izolowanych maszynach wirtualnych z pełnym środowiskiem deweloperskim.
    • Remote Control pozwala na sterowanie agentem działającym na komputerze z poziomu aplikacji mobilnej. Część sterująca jest dostępna zdalnie, ale pliki, testy i lokalne narzędzia pozostają na komputerze użytkownika.
    • Powiadomienia push i Live Activities umożliwiają śledzenie postępów długich zadań bez konieczności trzymania aplikacji otwartej.
    • Wymagania systemowe — aplikacja działa na iPhone i iPadzie; do Remote Control potrzebny jest desktopowy klient Cursor w wersji 3.9.8 lub nowszej.

    Nie chodzi o pisanie kodu na ekranie dotykowym

    Mało kto chce pisać kod na klawiaturze telefonu, a Cursor również nie ma takiego zamiaru. Zamiast przenosić edytor na mały ekran, aplikacja koncentruje się na zarządzaniu pracą agentów.

    Użytkownik wybiera repozytorium, uruchamia cloud agenta — tak samo jak w desktopowej wersji — i zleca mu zadanie. Agent działa w izolowanym środowisku, ma dostęp do narzędzi deweloperskich, może uruchamiać testy, przygotowywać pull requesty i iterować po kodzie. W tym czasie użytkownik może zająć się innymi sprawami, a powiadomienia poinformują go, kiedy zadanie zostanie zakończone.

    Remote Control — twój komputer pracuje, ty jesteś gdzie indziej

    Remote Control to kluczowa funkcja mobilnego Cursora. Agent działa na komputerze użytkownika, z dostępem do lokalnych plików, testów i całego setupu, a część sterująca jest dostępna zdalnie. Użytkownik łączy się przez aplikację, widzi postęp i może wysyłać kolejne instrukcje.

    Aby to zadziałało, należy włączyć Remote Control w ustawieniach desktopowego klienta (Settings → Agents), uruchomić sesję przez /remote-control i sparować urządzenia. Komputer musi być włączony i online, ale Cursor oferuje opcję "Keep this computer awake", aby nie usypiał się w trakcie pracy agenta.

    Dla zespołów Teams i Enterprise administratorzy mogą włączać tę funkcję centralnie w ustawieniach organizacji.

    Przepływ pracy, który ma sens przy DevOps i nie tylko

    Przepływ pracy, który ma sens przy DevOps i nie tylko

    Wyobraź sobie taki scenariusz: zaczynasz planować funkcję lokalnie, a następnie wysyłasz zadanie do cloud agenta, aby pracował nad implementacją. W międzyczasie uczestniczysz w spotkaniu. Agent kończy, a użytkownik otrzymuje powiadomienie, przegląda różnice i artefakty na telefonie. Jeśli wszystko jest w porządku, może zmergować PR prosto z aplikacji. Jeśli nie — przekazuje sesję z powrotem na desktop, testuje lokalnie i zatwierdza zmiany.

    To nie jest tylko ciekawostka. Deweloperzy pracujący z CI/CD mogą na przykład triage'ować zgłoszenia bugów, przeglądać logi i zatwierdzać poprawki bez konieczności podpinania się do stacji roboczej — to przykłady zastosowań aplikacji.

    Kontekst rynkowy — agenty zamiast autouzupełniania

    Kontekst rynkowy — agenty zamiast autouzupełniania

    Wydanie mobilnej aplikacji Cursor wpisuje się w szerszy trend: przejście od AI-asystującego w pisaniu kodu do agentów autonomicznie wykonujących wieloetapowe zadania. Cloud agenci nie tylko sugerują linijkę kodu, ale potrafią przeanalizować całe repozytorium, uruchomić testy, zrozumieć kontekst i przygotować kompletny pull request.

    Na starcie Cursor oferował promocję — 75% zniżki na uruchomienia Composer 2.5 w aplikacji mobilnej, która obowiązywała do 5 lipca 2026 roku i już się zakończyła.

    Co to zmienia w praktyce

    Aplikacja nie zastępuje IDE. Jest warstwą kontrolną, która odciąża dewelopera od klawiatury w momentach, gdy obecność przy komputerze nie jest konieczna. Dla osób prowadzących kilka równoległych zadań, nadzorujących pracę zespołu lub po prostu nie chcących tracić czasu na czekanie przy ekranie — to praktyczne narzędzie.

    Oczywiście, beta oznacza, że nie wszystko będzie działać idealnie. Jednak kierunek rozwoju oprogramowania wskazuje na to, że przestaje być ono czynnością wyłącznie stacjonarną.

    Źródła

  • Claude Code 2.1.212: nowe komendy /fork i /subtask porządkują pracę równoległą

    Claude Code 2.1.212: nowe komendy /fork i /subtask porządkują pracę równoległą

    Anthropic wprowadziło 17 lipca 2026 roku wersję Claude Code 2.1.212, która rozdziela dotychczasowe działanie komendy /fork na dwa odrębne narzędzia. Teraz /fork tworzy niezależną sesję w tle, a nowa komenda /subtask uruchamia podagenta, który po wykonaniu zadania zwraca wynik do głównej konwersacji. Wprowadzone zostały również limity bezpieczeństwa oraz poprawki stabilności.

    Kluczowe zmiany w wydaniu

    • Komenda /fork w wersji 2.1.212 tworzy osobną sesję w tle, kopiując bieżącą konwersację, podczas gdy oryginalna sesja działa dalej niezależnie.
    • Nowa komenda /subtask deleguje konkretne zadanie podagentowi, który dziedziczy pełną historię rozmowy i zwraca rezultat po zakończeniu pracy.
    • Limit 200 wywołań WebSearch na sesję chroni przed zapętleniem wyszukiwań, a wartość ta jest konfigurowalna przez zmienną środowiskową.
    • Limit 200 spawnów podagentów zapobiega niekontrolowanemu mnożeniu się agentów w długich sesjach deweloperskich.
    • Poprawki dla Windows, git worktree i MCP zwiększają niezawodność w profesjonalnych środowiskach.

    Dwie komendy zamiast jednego bałaganu

    Do tej pory /fork pełniło dwie różne funkcje w zależności od wersji. W wydaniach 2.1.161–2.1.211 oznaczało podagenta działającego wewnątrz sesji. Teraz ten chaos znika, a odpowiedzialności są jasno podzielone.

    Gdy chcesz, aby cała konwersacja kontynuowała się jako niezależna sesja (na przykład oddzielny wątek testów integracyjnych), używasz /fork. Nowa sesja pojawia się jako osobny wpis w interfejsie agentów. Natomiast /subtask sprawdza się przy węższych zadaniach, takich jak analiza zależności, generowanie dokumentacji czy inspekcja infrastruktury. Podagent dostaje pełny kontekst rozmowy, wykonuje swoje zadanie i zgłasza się z wynikiem.

    Dla zespołów pracujących w trybie vibe coding to znaczne ułatwienie. Znikają wątpliwości, czy odłączona sesja wróci z odpowiedzią, czy już działa niezależnie.

    Zabezpieczenia przed niekontrolowaną automatyzacją

    Zabezpieczenia przed niekontrolowaną automatyzacją

    Anthropic wprowadziło dwa limity, które mogą pomóc w zarządzaniu kosztami i stresem podczas sesji z agentami. Standardowo Claude Code 2.1.212 nie wykona więcej niż 200 wywołań WebSearch i nie zespawnuje więcej niż 200 podagentów w ramach jednej sesji.

    Deweloperzy mogą dostosować te wartości przez CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION oraz CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION. Limit podagentów resetuje się po wykonaniu /clear.

    Te limity mają na celu kontrolowanie scenariuszy, które mogą wymknąć się spod kontroli, takich jak rekurencyjna delegacja zadań czy zapętlone wyszukiwania, które mogą szybko zjeść limit API. Teraz jest bezpieczniej, choć warto pamiętać, że w późniejszych wersjach (około 2.1.224) górny pułap 200 podagentów został całkowicie zniesiony dla długo działających sesji.

    Stabilność dla wymagających środowisk

    Stabilność dla wymagających środowisk

    Aktualizacja przynosi także mniej widoczne, ale równie istotne poprawki. Długotrwałe wywołania narzędzi MCP (Model Context Protocol) zyskały na niezawodności, co jest kluczowe przy złożonych operacjach, które mogą trwać długo.

    Wznowienia sesji działają lepiej. Każdy, kto stracił postęp przez zerwane połączenie terminala lub awarię procesu, doceni tę zmianę. Dodatkowo zespół Anthropica naprawił krytyczne błędy w wykonywaniu komend Bash, poprawił kompatybilność z Windowsem oraz obsługę git worktree, co jest korzystne dla deweloperów używających równoległych gałęzi z izolowanymi katalogami roboczymi.

    Co to znaczy na co dzień

    Nowy podział /fork i /subtask oraz limity bezpieczeństwa wskazują, w jakim kierunku zmierza Claude Code 2.1.212 – w stronę bardziej dojrzałego narzędzia do pracy zespołowej, a nie tylko asystenta dla pojedynczego dewelopera. Rozdzielenie niezależnych sesji od delegowanych podzadań to krok w stronę przejrzystości, której brakowało we wcześniejszych wersjach. To dopiero początek tego, co Anthropic planuje w kolejnych aktualizacjach.

    Źródła

  • Qwen-Code v0.19.11 z przebudowaną powłoką webową i pętlą walidacji recenzji kodu

    Qwen-Code v0.19.11 z przebudowaną powłoką webową i pętlą walidacji recenzji kodu

    Zespół Qwen-Code wypuścił wersję v0.19.11, kończąc intensywny tydzień rozwojowy, w którym zrealizowano ponad 160 scalonych pull requestów. Aktualizacja koncentruje się na trzech głównych obszarach: nowej powłoce webowej, ulepszonym interfejsie CLI oraz bardziej rygorystycznym, wieloetapowym procesie automatycznej recenzji kodu.

    Kluczowe zmiany w skrócie

    • Powłoka webowa zyskała blokadę ścieżki workspace, panel przeglądu artefaktów oraz interaktywne sterowanie diagramami Mermaid.
    • Polecenie /learn umożliwia zapisanie wiedzy z katalogu, URL-a lub rozmowy jako plik SKILL.md do późniejszego wykorzystania.
    • System recenzji rozszerza weryfikację zgłoszeń przed publikacją oraz wprowadza audyt wsteczny, który identyfikuje pominięte problemy.
    • Wydajność recenzji poprawiono przez ograniczenie buildów i testów tylko do zmienionych workspace’ów oraz skompresowane prompty.
    • Wielo-workspace’owe sesje z kolorowymi wskaźnikami i heartbeatami shellowymi zwiększają bezpieczeństwo długotrwałej pracy.

    Powłoka webowa jako centrum zarządzania pracą

    Przebudowa Web Shella to nie tylko kosmetyka. Interfejs zyskał nową bibliotekę komponentów (shadcn) i został wzbogacony o funkcje, które wcześniej wymagały przełączania się między terminalem a konfiguracją. Kluczową nowością jest blokada ścieżki workspace, co eliminuje ryzyko przypadkowej zmiany kontekstu katalogu roboczego podczas sesji. Dla zespołów pracujących nad wieloma projektami jednocześnie oznacza to koniec zgadywania, w którym repozytorium aktualnie wykonywane są polecenia.

    Wprowadzono również dedykowany panel zarządzania rozszerzeniami, który wcześniej kontrolowano głównie przez pliki konfiguracyjne lub CLI – teraz wystarczy kilka kliknięć w interfejsie. Pojawił się także panel przeglądu artefaktów, który organizuje wygenerowane pliki i wyniki pracy agenta.

    Dla wizualizacji architektury i przepływów pracy Qwen-Code dodał możliwość interaktywnego sterowania diagramami Mermaid: można je teraz przybliżać, przesuwać i przeciągać. Wsparcie dla wielu workspace’ów z podziałem ekranu i kolorowymi wskaźnikami kontekstu sprawia, że powłoka przestaje być jedynie terminalem w przeglądarce – staje się centrum zarządzania całym środowiskiem deweloperskim. Dodatkowo, przebudowa objęła maksymalizowanie paneli split-pane oraz wyświetlanie sesji oczekujących na działanie użytkownika.

    CLI, które pamięta i uczy się projektu

    Nowe polecenie /learn to jeden z ciekawszych dodatków tej wersji. Użytkownik wskazuje katalog, URL, treść rozmowy lub własny tekst, a Qwen-Code przetwarza ten materiał w plik SKILL.md. To więcej niż notatka – zapisana wiedza staje się częścią kontekstu i może być przywoływana w kolejnych sesjach.

    CLI zyskało także polecenie /update, które umożliwia aktualizację jednym kliknięciem, poprawione tryby zatwierdzania oraz lepsze zarządzanie sesjami, aby nie mieszać kontekstu między projektami. W tle działa Voice Bridge – mechanizm, który integruje audio z workflow Agent Communication Protocol: modele tekstowe otrzymują transkrypcję, a natywnie obsługujące dźwięk – oryginalne wejście audio.

    Recenzja kodu z pętlą weryfikacji

    To najważniejsza zmiana procesowa w tym wydaniu. Automatyczna recenzja kodu w Qwen-Code przestała być prostym „znajdź i zgłoś”. Teraz działa w pięciu krokach, z czego dwa zostały dodane lub rozszerzone.

    Po wykryciu problemów system uruchamia krok czwarty – weryfikator, który sprawdza każde zgłoszenie pod kątem faktycznej poprawności. Dopiero zwalidowane uwagi trafiają dalej. Krok piąty to audyt wsteczny, który szuka problemów pominiętych w pierwszym przeglądzie. To pełny, otwarty ponowny przegląd diffu, który może przebiegać w wielu rundach – od 2 do 10, w zależności od topologii i ustawień.

    Recenzje z kategorii „sugestie” trafiają teraz bezpośrednio jako komentarze inline w pull requeście – nie trzeba ręcznie kopiować rekomendacji z outputu. System zyskał także konfigurowalny poziom wysiłku recenzji, testy poprawności proceduralnej oraz mapowanie linii diffa do konkretnych recenzentów. Timeout recenzji podniesiono do 180 minut z możliwością przedłużenia do 240, co ma zapobiec przerywaniu analizy dużych pull requestów.

    Co istotne, Agent 7, odpowiedzialny za build i testy, ogranicza teraz swoje działanie wyłącznie do workspace’ów dotkniętych zmianą. Dla monorepozytoriów to znacząca różnica – zamiast przebudowywać całe repozytorium, Qwen-Code sprawdza tylko to, co faktycznie się zmieniło. Warto również wspomnieć o automatycznym fallbacku PDF-to-image, który rozszerza możliwości przetwarzania dokumentów.

    Dlaczego to ma znaczenie

    Wersja v0.19.11 scala wcześniej rozproszone elementy workflow: Web Shell zarządza środowiskiem, CLI tworzy reusable wiedzę projektową, a system recenzji weryfikuje przed publikacją i audytuje po fakcie. Dla zespołów web developerskich i devopsowych oznacza to mniej niespodzianek – agent nie wykona polecenia w złym katalogu, recenzja nie opublikuje fałszywego alertu, a build nie przeliczy połowy repo bez potrzeby.

    To wydanie koncentruje się na tym, aby Qwen-Code stał się bezpieczniejszym i bardziej praktycznym narzędziem do długotrwałej, wieloprojektowej pracy z AI.

    Ź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

  • Cline SDK v0.0.62 naprawia trasowanie API Ollamy i ogranicza dane telemetryczne

    Cline SDK v0.0.62 naprawia trasowanie API Ollamy i ogranicza dane telemetryczne

    Najnowsza wersja Cline SDK v0.0.62 wprowadza dwie ważne poprawki: przywraca poprawne działanie ustawień okna kontekstowego i timeoutu dla natywnego API Ollamy oraz usuwa kontekst organizacyjny z metadanych narzędzi hub. To aktualizacja, która ma znaczenie dla deweloperów pracujących z lokalnymi modelami AI.

    Co się zmieniło

    • Trasowanie Ollamy – natywne żądania do Ollamy znów respektują skonfigurowane wartości context-window i timeout, które wcześniej były ignorowane.
    • Timeouty – poprawka jest istotna zwłaszcza przy dłuższym ładowaniu dużych modeli, zanim wygenerują pierwszy token.
    • Prywatność – z kontekstów narzędzi hub usunięto dane organizacyjne, co ogranicza ilość metadanych przypisanych do tych interakcji.
    • Zakres zmian – aktualizacja dotyczy natywnego providera Ollamy, nie endpointów kompatybilnych z OpenAI.
    • Docelowi użytkownicy – zmiany są szczególnie ważne przy projektach używających SDK do budowy agentów kodowania i lokalnych przepływów pracy.

    Dlaczego trasowanie API ma znaczenie

    Cline korzysta z dwóch ścieżek komunikacji z Ollamą – natywnego API oraz endpointów zgodnych z OpenAI. Każda z nich inaczej obsługuje konfigurację żądań. W wersji v0.0.62 poprawiono błąd, przez który natywna ścieżka przestała honorować ustawienia okna kontekstowego i timeoutu. W praktyce oznaczało to, że lokalne modele otrzymywały zbyt krótki kontekst lub zbyt restrykcyjne limity czasowe, niezależnie od konfiguracji.

    Okno kontekstowe w narzędziach AI do kodowania kontroluje, ile historii promptów, zawartości plików i wyników narzędzi może trafić do modelu. Ignorowanie tej wartości prowadziło do utraty istotnego kontekstu w dłuższych sesjach kodowania, co skutkowało niespójnymi odpowiedziami. Dokumentacja integracji Ollamy z Cline zaleca minimum 32K tokenów dla obciążeń programistycznych – bez poprawnego trasowania ta sugestia nie miała sensu.

    Timeouty również mają znaczenie. Duże modele lokalne potrzebują czasu na załadowanie do pamięci, szczególnie na sprzęcie z ograniczoną pamięcią GPU lub gdy obliczenia są realizowane na CPU. Wersja SDK v0.0.62 zwiększyła limit czasu oczekiwania na odpowiedź Ollamy z 30 sekund do pięciu minut, co potwierdza, że problem z cold-startem modeli lokalnych był rzeczywisty, a v0.0.62 to krok w kierunku jego rozwiązania.

    Telemetria: mniej znaczy lepiej

    Telemetria: mniej znaczy lepiej

    Drugą zmianą jest ograniczenie danych telemetrycznych. Z kontekstów narzędzi hub usunięto informacje organizacyjne, co oznacza, że operacje hub-tool nie otrzymują już metadanych na poziomie organizacji. To klasyczna minimalizacja danych – węższy zakres informacji przypisywany do aktywności narzędzi, bez wpływu na działanie Ollamy.

    Informacje o wydaniu nie precyzują, czy dane organizacyjne były logowane, transmitowane, czy tylko przechowywane wewnętrznie. Nie wiadomo też, ilu użytkowników zmiana dotknęła ani czy wcześniej zapisane dane zostały usunięte. Niemniej jednak kierunek jest jasny: Cline zmierza w stronę mniejszej ilości metadanych przy interakcjach narzędziowych.

    Dla kogo ta aktualizacja

    Dla kogo ta aktualizacja

    Cline SDK to programistyczne API agenta napisane w Node.js, a Ollama jest na liście wspieranych providerów. Wersja v0.0.62 dotyczy więc nie tylko użytkowników rozszerzenia IDE, ale także deweloperów osadzających runtime agenta Cline w swoich aplikacjach. Każdy projekt korzystający z Ollamy przez SDK powinien po aktualizacji zauważyć, że modele zachowują się zgodnie z zadaną konfiguracją.

    Co dalej

    Aktualizacja jest niewielka, ale usuwa błąd, który mógł poważnie zaburzać działanie lokalnych agentów AI. Dla zespołów pracujących z modelami lokalnymi – szczególnie na ograniczonym sprzęcie – przywrócenie kontroli nad timeoutem i oknem kontekstowym to poprawa stabilności. W połączeniu z późniejszymi zmianami, takimi jak pięciominutowe timeouty w v0.0.62, widać, że Cline systematycznie poprawia integrację z Ollamą.

    Ź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

  • Projekt Gemini CLI otrzymuje krytyczną łatkę stabilności dla anulowanych wywołań narzędzi

    Projekt Gemini CLI otrzymuje krytyczną łatkę stabilności dla anulowanych wywołań narzędzi

    Najnowszy "nightly build" Projekt Gemini CLI (wersja v0.53.0) wprowadza poprawkę w warstwie komunikacji z modelem, która dotyczy grupowania anulowanych odpowiedzi narzędzi oraz scalania sąsiadujących ról w konwersacji. Zmiana, wprowadzona przez kontrybutora @luisfelipe-alt w "pull requeście" #28407, eliminuje błędy 400 Bad Request, które mogły przerywać sesję w nieoczekiwanych momentach.

    Każdy, kto spędził czas z agentem Projekt Gemini CLI w trybie vibe coding, zna ten problem. Uruchamiasz kilka narzędzi — edycja pliku, polecenie shella, szybki test. Część operacji wykonuje się, a inne anulujesz, ponieważ zmieniasz koncepcję. W efekcie klient dostaje błąd od API. Ta poprawka ma to zmienić.

    Kluczowe informacje

    • Poprawka grupuje anulowane odpowiedzi narzędzi i scala sąsiadujące wiadomości o tej samej roli przed wysłaniem zapytania do API.
    • Pull request #28407 autorstwa @luisfelipe-alt jest oznaczony etykietą core,a2a, co wskazuje na zmiany w głównej logice przetwarzania i komunikacji agent-agent.
    • Wersja v0.53.0 (nie v0.52.0, jak początkowo sądzono) zawiera tę poprawkę w kanale "nightly".
    • Praktyczny efekt: mniej błędów żądań po anulowaniu narzędzi i stabilniejsza kontynuacja rozmów z modelem.

    Na czym polega problem techniczny

    Rozmowy z użyciem narzędzi w Projekt Gemini CLI są reprezentowane jako uporządkowana sekwencja wiadomości z przypisanymi rolami — model, wywołanie narzędzia, odpowiedź narzędzia. Anulowanie operacji może pozostawić fragmenty odpowiedzi, które nie pasują do oczekiwanego przez API formatu. Czasami powstają dwie sąsiadujące wiadomości od użytkownika, a czasami odpowiedź narzędzia ląduje w niewłaściwym miejscu.

    W efekcie API Projekt Gemini odrzuca zapytanie z kodem HTTP 400, co może przerwać całą sesję, szczególnie w złożonych, wieloetapowych "workflow".

    Mechanizm naprawczy działa w warstwie normalizacji wiadomości. Po pierwsze, anulowane odpowiedzi narzędzi są grupowane — zamiast emitować je jako pofragmentowane wpisy, Projekt Gemini CLI łączy je w spójną całość. Po drugie, sąsiadujące wiadomości z tą samą rolą (np. dwie kolejne od modelu) są scalane. Dopiero tak przygotowana konwersacja trafia do API.

    Dlaczego to ma znaczenie dla DevOps i vibe codingu

    Dlaczego to ma znaczenie dla DevOps i vibe codingu

    Wyobraź sobie typową sesję: agent Projekt Gemini CLI wykonuje serię operacji — klonuje repozytorium, modyfikuje konfigurację, uruchamia testy jednostkowe, sprawdza pokrycie kodu. W połowie orientujesz się, że obrałeś złą ścieżkę. Przerywasz. Agent anuluje pending tool calls, ale w tle pozostają fragmenty odpowiedzi.

    Bez tej poprawki ryzykujesz, że następne zapytanie do modelu — nawet zupełnie niezwiązane z anulowaną operacją — zostanie odrzucone. Z poprawką warstwa komunikacji jest odporna na takie artefakty.

    Co ciekawe, zmiana dotyczy nie tylko głównej ścieżki core, ale też komunikacji a2a (agent-to-agent). W środowiskach, gdzie wiele agentów wymienia się kontekstem, ryzyko zduplikowanych ról rośnie. Ta łatka zabezpiecza oba scenariusze.

    Kontynuacja prac nad stabilnością

    Kontynuacja prac nad stabilnością

    Linia rozwojowa v0.52.0 już wcześniej otrzymała poprawkę, która zapewnia, że anulowanie zadania przerywa pętlę wykonawczą agent-agent. Teraz v0.53.0 idzie krok dalej — nie tylko przerywa wykonanie, ale też sprząta po anulowaniu.

    Warto pamiętać, że "nightly build" Projekt Gemini CLI jest publikowany codziennie z głównej gałęzi o 00:00 UTC. Nie jest przeznaczony do produkcji — może zawierać nieprzetestowane zmiany. Jeśli jednak testujesz najnowsze możliwości agentów Projekt Gemini CLI w "workflow" developerskich, ta wersja jest dla ciebie.

    Czego nie ma w tej łatce

    Nie ma nowych narzędzi, szybszego modelu ani zmian w interfejsie użytkownika. To czysto inżynieryjna poprawka, która realnie zmniejsza tarcie w codziennej pracy z Projekt Gemini CLI. Nie ma statystyk latency ani wykresów error rate przed/po. To solidna robota pod maską.

    Następnym razem, gdy anulujesz agentowi część pracy i wszystko działa dalej bez restartu sesji, będziesz wiedział, komu za to podziękować.

    Ź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