Tag: automatyzacja

  • Claude Code 2.1.207: automatyczny tryb dostępny dla wszystkich i koniec z zawieszaniem terminala

    Claude Code 2.1.207: automatyczny tryb dostępny dla wszystkich i koniec z zawieszaniem terminala

    Anthropic wydało 11 lipca 2026 roku aktualizację Claude Code 2.1.207, która wprowadza automatyczny tryb dla użytkowników Bedrock, Vertex AI i Foundry, eliminując potrzebę ręcznego włączania go przez zmienne środowiskowe. W tej wersji wprowadzono 24 zmiany, w tym poprawki wydajnościowe, które eliminują opóźnienia w terminalu oraz błędy, które mogły prowadzić do zawieszania sesji.

    • Auto mode działa teraz domyślnie na platformach Bedrock, Vertex AI i Foundry — wcześniej wymagał flagi CLAUDE_CODE_ENABLE_AUTO_MODE
    • Claude Opus 4.8 stał się domyślnym modelem dla tych środowisk, zastępując Opus 4.7
    • Naprawiono zawieszanie terminala i opóźnienia klawiszy przy streamowaniu długich list, tabel, akapitów i bloków kodu
    • Ustawienia automatycznego trybu nie są już odczytywane z plików lokalnych repozytorium — teraz liczy się tylko konfiguracja użytkownika
    • Rozwiązano problem z AWS credential resolution na Windowsie, gdzie proces potrafił wisieć w nieskończoność

    Co konkretnie zmienia się w auto mode

    Tryb automatyczny w Claude Code pozwala asystentowi na samodzielne wykonywanie poleceń i edytowanie plików bez konieczności pytania o zgodę przy każdej operacji. Dotychczas na platformach chmurowych Bedrock, Vertex AI i Foundry trzeba było włączyć tę funkcję przez zmienną środowiskową, co było problematyczne w środowiskach CI/CD oraz przy automatyzacji z poziomu SDK.

    Teraz auto mode jest dostępny od razu. Aby go wyłączyć, wystarczy dodać disableAutoMode w pliku ~/.claude/settings.json. Zmieniono również sposób odczytu konfiguracji — autoMode nie jest już brane z pliku .claude/settings.local.json w repozytorium. Podobnie pluginConfigs przestały być honorowane z poziomu projektu. To zmiana mająca na celu uproszczenie konfiguracji, która teraz zależy od ustawień użytkownika, a nie od tego, co ktoś wrzucił do repo.

    Domyślnym modelem dla Bedrock, Vertex i Claude Platform na AWS został Claude Opus 4.8 — następca Opus 4.7, który oferuje lepszą wydajność przy tej samej cenie.

    Terminal przestał się zacinać — i to naprawdę odczuwalna zmiana

    Jednym z bardziej frustrujących problemów w poprzednich wersjach było zawieszanie się terminala podczas streamowania dłuższych odpowiedzi. Gdy Claude generował rozbudowane tabele, długie akapity czy bloki kodu, interfejs mógł przestać reagować — klawisze nie działały, przewijanie nie funkcjonowało, a cała sesja wydawała się zawieszona. Wersja 2.1.207 eliminuje ten problem.

    Dla użytkowników Windowsa istotna jest poprawka dotycząca AWS credential resolution. Wcześniej, gdy proces uwierzytelniania — na przykład przez credential_process — utknął, Claude Code mógł wisieć w nieskończoność. Teraz mechanizm radzi sobie z tym poprawnie, co jest szczególnie ważne w środowiskach developerskich korzystających z lokalnych profili AWS.

    Mniej błędów, lepszy podgląd sesji

    Poprawiono również kilka mniej widocznych, ale uciążliwych błędów. Ustawienia zarządzane zdalnie (managed settings) z nieinteraktywnych wywołań — jak claude -p czy wywołania SDK — nie będą już przypadkowo oznaczane jako zaakceptowane bez pokazania okna zgody. Wcześniej mogło to prowadzić do sytuacji, w których zgoda na przetwarzanie danych była rejestrowana bez wiedzy użytkownika.

    Widok agenta zyskał lepsze zachowanie przy wklejanym tekście oraz wyraźniejszy podgląd sesji. Interfejs lepiej radzi sobie z powtarzanym tekstem z clipboarda, a funkcja „session peek” pokazuje czytelniejsze informacje o stanie sesji.

    Dla zespołów pracujących z repozytoriami korzystającymi z git worktree poprawiono błędy konfiguracyjne, które wcześniej mogły powodować niespójności w działaniu narzędzi.

    Dlaczego to ważne dla web dev i DevOps

    Zmiany w tej wersji odpowiadają na konkretne problemy, z jakimi borykają się użytkownicy Claude Code. Automatyczny tryb bez konieczności opt-in przyspiesza pracę w środowiskach chmurowych, gdzie każda ręczna akceptacja to strata czasu. Poprawki wydajności terminala zapewniają płynniejszą pracę z długimi odpowiedziami AI, co jest istotne przy generowaniu kodu czy analizie logów. Stabilność przy rozwiązywaniu credentiali na Windowsie przekłada się na mniej przerw w pracy, zwłaszcza w zespołach korzystających z AWS.

    Przeniesienie konfiguracji z plików lokalnych repozytorium na poziom użytkownika to również sygnał dla liderów zespołów: warto przejrzeć, gdzie trzymane są ustawienia Claude Code w waszych projektach, ponieważ po tej aktualizacji część z nich może przestać działać tak jak wcześniej.

    Źródła

  • Cursor dostaje rozbudowane wyzwalacze i własny pulpit — /automate zmienia agentów w asystentów CI/CD

    Cursor dostaje rozbudowane wyzwalacze i własny pulpit — /automate zmienia agentów w asystentów CI/CD

    Nowa aktualizacja Cursora wprowadza komendę /automate, która umożliwia opisanie przepływu pracy w prostym języku i natychmiastowe uruchomienie go jako automatycznej akcji. Wprowadzone zostały także nowe wyzwalacze dla Slacka i GitHuba oraz funkcja computer use, która pozwala agentom w chmurze na samodzielne klikanie w interfejsach i generowanie wersji demonstracyjnych bez potrzeby interwencji człowieka. W rezultacie Cursor przekształca się z edytora z AI w autonomicznego współpracownika, który obsługuje kod, recenzje, testy i prezentuje końcowy wynik.

    Co nowego w automatyzacjach

    • /automate tworzy złożone workflow z opisu słownego — użytkownik podaje zadanie, a Cursor sam dobiera wyzwalacze, narzędzia i instrukcje.
    • Wyzwalacze obejmują teraz reakcje emoji w Slacku, zdarzenia z pull requestów (komentarze do przeglądów PR, zatwierdzenie przeglądu PR, aktualizacja wątku przeglądu) oraz zakończone przebiegi GitHub Actions.
    • Computer use jest domyślnie włączone dla agentów chmurowych — mogą sterować myszą i klawiaturą w izolowanym środowisku wirtualnym.
    • Automatyzacje można tworzyć z poziomu okna agenta, panelu cursor.com/automations, sesji lokalnego agenta lub szablonów z marketplace.
    • Agenci uruchamiani ze Slacka czy GitHuba potrafią teraz samodzielnie przygotować artefakty i demo, a użytkownik może przejąć kontrolę nad ich pulpitem.

    Jak działa /automate i gdzie go użyć

    Do tej pory skonfigurowanie automatyzacji w Cursorze wymagało zrozumienia wyzwalaczy, dostępnych narzędzi i sposobu ich połączenia. Komenda /automate znacznie to upraszcza — wystarczy opisać zadanie, na przykład "sprawdzaj każdy nowy PR pod kątem błędów bezpieczeństwa i pisz komentarz z wynikami", a Cursor przekształca to w gotową konfigurację.

    Tworzenie automatyzacji nie jest już ograniczone do jednego miejsca. Można to zrobić z poziomu okna agenta podczas sesji, odwiedzić stronę cursor.com/automations i ręcznie skonfigurować workflow, lub skorzystać z gotowych rozwiązań z marketplace. Jeśli korzystasz z lokalnego agenta i wpiszesz /automate, Cursor zaproponuje strukturę na podstawie opisu.

    Nowe wyzwalacze nie ograniczają się do zdarzeń w repozytorium. Reakcja emoji pod wiadomością na Slacku może teraz uruchomić agenta. Kiedy ktoś wrzuca link do PR-a na kanał, wystarczy dodać emoji, aby automatycznie rozpocząć przegląd kodu lub testy integracyjne. To pozwala na efektywniejsze zarządzanie zadaniami z poziomu komunikatora.

    Agent z własnym pulpitem — computer use w chmurze

    Agent z własnym pulpitem — computer use w chmurze

    To jedna z najciekawszych nowości aktualizacji. Do tej pory agenci chmurowi Cursora operowali głównie na kodzie i terminalu. Teraz każdy agent uruchomiony przez automatyzację działa w izolowanej maszynie wirtualnej z pełnym środowiskiem graficznym. Ma dostęp do myszy i klawiatury, może otwierać przeglądarkę, klikać w interfejsach aplikacji, robić zrzuty ekranu i nagrywać demo działania.

    Funkcja computer use jest domyślnie włączona dla każdej automatyzacji. Agent nie musi już prosić użytkownika o uruchomienie lokalnego środowiska, aby pokazać efekt pracy. Samodzielnie uruchamia aplikację, przechodzi przez proces i nagrywa z tego artefakt. Dla zespołów zajmujących się web developmentem oznacza to mniej ręcznego testowania UI i szybsze pętle feedbacku podczas przeglądów.

    Użytkownik może w każdej chwili przejąć kontrolę nad pulpitem agenta. Jeśli coś idzie nie tak lub chcesz sprawdzić stan aplikacji na żywo, wystarczy otworzyć podgląd i działać jak na zdalnym pulpicie.

    Co to zmienia w praktyce DevOps i code review

    Nowe wyzwalacze GitHuba są skierowane bezpośrednio na proces przeglądów. Komentarze do przeglądów PR, zatwierdzenia przeglądów PR oraz aktualizacje wątków przeglądów to zdarzenia, które wcześniej wymagały ręcznej obsługi. Teraz można podpiąć agenta, który automatycznie odpowiada na uwagi recenzenta, poprawia kod i pcha commity — wszystko w ramach jednego workflow.

    Dodatkowo, wyzwalacz Workflow run completed pozwala agentowi czekać na zakończenie pipeline'u CI/CD i w zależności od wyniku podjąć akcję: zgłosić błąd, utworzyć issue, a nawet spróbować naprawić testy. To sprawia, że Cursor staje się nie tylko asystentem kodowania, ale także integralną częścią pipeline'u, który reaguje na zdarzenia i podejmuje decyzje.

    Zespoły korzystające ze Slacka jako warstwy operacyjnej zyskują dodatkowy kanał sterowania. Komendy Slack i emoji jako wyzwalacze zmniejszają tarcie między komunikacją a wykonaniem. Zamiast wymieniać się linkami i prośbami o przegląd, można uruchomić agenta jednym kliknięciem reakcji.

    Nowe funkcje są już dostępne dla użytkowników Cursora. Automatyzacje i computer use działają w środowisku chmurowym; część wyzwalaczy wymaga połączenia konta GitHub i Slack.

    Źródła

  • Claude Code 2.1.204: koniec z cichym usuwaniem workerów w sesjach headless

    Claude Code 2.1.204: koniec z cichym usuwaniem workerów w sesjach headless

    Anthropic wydało 8 lipca 2026 roku wersję 2.1.204 Claude Code, która rozwiązuje problem z sesjami bez interfejsu graficznego. Błąd polegał na tym, że zdarzenia hooków nie były prawidłowo strumieniowane podczas fazy SessionStart, co prowadziło do przedwczesnego usuwania zdalnych workerów przez mechanizmy idle timeout. W praktyce oznaczało to, że worker znikał, zanim zdążył się w pełni zainicjalizować.

    Co warto wiedzieć o tej aktualizacji

    • Sesje headless nie strumieniowały zdarzeń hooków w fazie SessionStart, przez co workery wyglądały na nieaktywne.
    • Mechanizm idle timeout usuwał zdalne workery w trakcie wykonywania hooków inicjalizacyjnych.
    • Aktualizacja 2.1.204 przywraca prawidłowe strumieniowanie zdarzeń i zapobiega przedwczesnemu usuwaniu workerów.
    • Problem dotykał głównie środowisk CI/CD, zdalnych agentów i zautomatyzowanych przepływów pracy.
    • Równolegle w cyklu wydawniczym poprawiono też backend grep, przechodząc na ripgrep.

    Dlaczego to ma znaczenie dla automatyzacji

    Hook SessionStart w Claude Code jest kluczowy do ładowania kontekstu deweloperskiego, ustawiania zmiennych środowiskowych oraz przygotowywania narzędzi przed właściwą pracą. W środowiskach headless, gdzie nie ma interakcji ze strony użytkownika, ten etap jest szczególnie istotny. Jeśli system orkiestracji uzna, że worker milczy za długo, może go usunąć.

    W praktyce hook startowy działał normalnie, ale nie wysyłał żadnych widocznych zdarzeń na zewnątrz. Dla nadzorującego proces worker wydawał się martwy, co prowadziło do tego, że sesja kończyła się w połowie inicjalizacji, a zadanie przepadało.

    Poprawka w 2.1.204 eliminuje ten problem. Hooki SessionStart znów strumieniują zdarzenia, informując system, że proces trwa. Worker nie zostanie uznany za bezczynny, dopóki nie zakończy pracy.

    Hooki startowe pod lupą

    Z dokumentacji Claude Code wynika, że SessionStart uruchamia się przy każdym rozpoczęciu lub wznowieniu sesji. Obsługuje kilka trybów dopasowania: startup, resume, clear, compact i fork. Elastyczność tych wyzwalaczy sprawia, że hook jest szeroko stosowany w pipeline'ach DevOps.

    Szczególnie narażone na opisywany błąd były scenariusze z resume, gdzie sesja wznawiana w trybie headless mogła wyglądać na kompletną, ale w rzeczywistości nadal przetwarzała hooki startowe. Mechanizm idle timeout nie dostrzegał różnicy między „nic się nie dzieje” a „hook jeszcze działa, tylko nie melduje”.

    Co to oznacza dla zespołów DevOps i web dev

    Jeśli używasz Claude Code w CI/CD, na zdalnych agentach lub w jakimkolwiek przepływie bez interfejsu, ta łatka jest istotna. Zmniejsza ryzyko losowych awarii podczas inicjalizacji sesji. Nie zmienia nic w API i nie wymaga migracji konfiguracji — wystarczy zaktualizować.

    Warto również zwrócić uwagę na drugą poprawkę w tym cyklu wydawniczym: przesiadkę z grep na ripgrep. To oddzielna kwestia, ale również wpływa na wydajność w zautomatyzowanych środowiskach, gdzie przeszukiwanie kodu jest codziennością.

    Aktualizacja 2.1.204 to klasyczna poprawka konserwacyjna — nie zawiera spektakularnych zmian w changelogu, ale dla osób debugujących znikające workery w nocy może być bardzo pomocna.

    Źródła

  • OpenCode zyskuje lepszą integrację MCP i odświeżone doświadczenie desktopowe

    OpenCode zyskuje lepszą integrację MCP i odświeżone doświadczenie desktopowe

    Aktualizacja OpenCode z 6 lipca 2026 roku (v1.17.14) wprowadza nowy adapter MCP dla trybu kodowego, który umożliwia uruchamianie skryptów orkiestracyjnych w kontrolowanym środowisku. Zmiany obejmują również aplikację desktopową, która teraz pozwala na lepsze zarządzanie kartami oraz łatwiejszy powrót do przerwanej pracy. Zespół wprowadził także poprawki stabilności sesji i routingu modeli.

    To wydanie wskazuje na dążenie OpenCode do tego, aby MCP stało się integralną częścią workflow, a nie tylko dodatkiem. Adapter w trybie kodowym odpowiada na potrzeby zespołów automatyzujących zadania za pomocą skryptów podłączonych do serwerów MCP. Aplikacja desktopowa została dostosowana, aby nie przeszkadzała w codziennej pracy.

    Kluczowe zmiany w aktualizacji

    • Adapter MCP w trybie kodowym umożliwia bezpieczne uruchamianie skryptów orkiestracyjnych z dostępem do narzędzi MCP.
    • Narzędzie execute jest teraz ukryte, dopóki tryb kodowy nie zostanie włączony, co zmniejsza liczbę przypadkowych wywołań.
    • Karty w aplikacji desktopowej można ponownie otwierać po zamknięciu, otwierać w tle i zachowywać ich układ po restarcie.
    • Poprawki routingu dla modeli OpenCode eliminują błędne kierowanie zapytań do niewłaściwych endpointów.
    • Stabilność sesji wzrosła dzięki naprawom ładowania, wznawiania i obsługi stanu.

    Tryb kodowy pod kontrolą

    Nowy adapter MCP w trybie kodowym to kluczowa zmiana dla osób pracujących ze skryptami. Wcześniej narzędzie execute było dostępne przez cały czas, co mogło prowadzić do przypadkowych uruchomień w niewłaściwym kontekście. Teraz jest schowane, dopóki nie włączysz trybu kodowego.

    Adapter działa w izolowanym środowisku, co oznacza, że skrypty orkiestracyjne mają dostęp do podłączonych narzędzi MCP, ale w ograniczonym zakresie. To podejście pozwala na kontrolę nad tym, co agent może zrobić, minimalizując ryzyko niepożądanych działań. Dla zespołów devopsowych i osób piszących zautomatyzowane workflow to znaczący postęp.

    OpenCode od dłuższego czasu rozwija wsparcie dla MCP, a dokumentacja pokazuje, że serwery MCP są traktowane jako integralna część ekosystemu, z dostępem do narzędzi, promptów i zasobów. Ta aktualizacja jest częścią szerszego planu, w którym MCP staje się fundamentem.

    Desktop bez frustracji

    Zmiany w aplikacji desktopowej mogą wydawać się drobne, ale w sumie wprowadzają zauważalne różnice. Karty, które wcześniej znikały po zamknięciu, teraz można przywrócić. Otwieranie w tle nie przerywa pracy, a po restarcie aplikacji układ kart pozostaje zachowany, co ułatwia korzystanie z workspace’u.

    Dodatkowo, poprawiono przepływy łączenia z providerami oraz integrację terminala. Praca z wieloma sesjami jednocześnie jest teraz bardziej płynna. Dla osób spędzających w OpenCode wiele godzin dziennie, te zmiany to realna oszczędność czasu i nerwów.

    Wskaźniki ładowania w TUI również zostały poprawione. Spinner nie będzie się już zawieszał, co sprawia, że informacja zwrotna o działaniu aplikacji jest bardziej przewidywalna. To drobny, ale istotny detal, który może irytować podczas dłuższych sesji.

    Routing i katalogi — ciche, ale ważne poprawki

    OpenCode otrzymał poprawki routingu modeli, co oznacza, że zapytania są teraz kierowane tam, gdzie powinny, zgodnie z reklamowanymi funkcjami modelu. Dla użytkowników korzystających z różnych endpointów (chat vs. responses) to koniec z zagadką „dlaczego to nie działa”.

    Katalogi narzędzi MCP z paginacją przestały gubić metadane i walidację schematu. Dla większych zestawów narzędzi to istotne, ponieważ brakujące opisy mogą skutecznie utrudnić zrozumienie dostępnych zasobów.

    Sesje stały się stabilniejsze dzięki poprawkom w dopasowywaniu katalogów sesji, ładowaniu i wznawianiu, co eliminuje irytujące przypadki utraty stanu. Mniej niespodzianek przy przełączaniu między zadaniami to zawsze pozytywna zmiana.

    Podsumowanie

    Lipcowa aktualizacja OpenCode pokazuje dojrzałe podejście do rozwoju narzędzia. Zespół skupił się na rozwiązaniu kilku istotnych problemów, zamiast wprowadzać nowe, spektakularne funkcje. MCP staje się bardziej przewidywalne i bezpieczne, a aplikacja desktopowa wygodniejsza w codziennym użytkowaniu. Poprawki w działaniu środowiska sprawiają, że rzadziej występują problemy techniczne. Dla osób budujących zautomatyzowane workflow i korzystających z serwerów MCP, to wydanie jest warte uwagi, zwłaszcza w kontekście kontroli nad trybem kodowym.

    Źródła

  • Devin Desktop v3.4.22 wprowadza kontrolę sesji i trwałość agenta na nowym poziomie

    Devin Desktop v3.4.22 wprowadza kontrolę sesji i trwałość agenta na nowym poziomie

    Czwartego lipca 2026 roku zespół Cognition wprowadził wersję v3.4.22 Devin Desktop, narzędzia znanego wcześniej jako Windsurf, które po rebrandingu pełni rolę centrum dowodzenia dla agentów kodujących. Aktualizacja nie zmienia wizualnie interfejsu, ale wprowadza kilka usprawnień, które realnie zmniejszają tarcie w codziennej pracy z agentami AI. Wśród nowości znalazły się lepsza organizacja sesji, automatyczne ponowne łączenie z chmurą oraz poprawne sprzątanie po procesach, które wcześniej mogły wisieć w tle.

    Co nowego — w skrócie

    • Nowa opcja „New session in space” umożliwia rozpoczęcie sesji bezpośrednio w istniejącej Przestrzeni, dziedzicząc pełny kontekst projektu.
    • Automatyczne ponowne łączenie sesji Devin Cloud po utracie sieci eliminuje konieczność ręcznego klikania „Reconnect”.
    • Kopiowanie obrazów z czatu przez menu kontekstowe — funkcja, która przyspiesza dokumentowanie i zgłaszanie błędów.
    • Panel boczny agenta pozostaje widoczny podczas akcji Cascade, takich jak „explain-and-fix” czy wysyłanie problemów.
    • Poprawki stabilności obejmują branch checkout, cache sesji oraz czyszczenie osieroconych procesów agenta.

    Nowa sesja w Przestrzeni — kontekst bez powtórek

    Najciekawszą zmianą dla osób zarządzających większymi projektami jest opcja „New session in space”, dostępna z menu kebab przy sesji. Przestrzenie (Spaces) w ekosystemie Devin grupują agentów, pull requesty, pliki oraz cały kontekst zadania w jednym widoku. Gdy tworzysz nową sesję wewnątrz Przestrzeni, automatycznie przejmuje ona wszystko, co Przestrzeń już wie o projekcie — nie musisz ponownie tłumaczyć agentowi, nad czym pracuje. To szczególnie przydatne, gdy jeden projekt wymaga równoległych wątków, takich jak lokalne edycje, agenci w chmurze oraz przegląd PR-ów.

    Cloud bez manualnego reconnectu

    Sesje Devin Cloud działają w synchronizacji z aplikacją webową, ale wcześniej każde zerwanie połączenia kończyło się banerem „Remote ACP is disconnected” oraz koniecznością ręcznego kliknięcia przycisku. W wersji v3.4.22 wprowadzono automatyczne ponowne łączenie — gdy tylko sieć wraca, agent sam podejmuje przerwaną pracę. Dla zespołów DevOps, które uruchamiają długotrwałe zadania deployu czy testów w chmurze, oznacza to mniej nerwowego sprawdzania statusu po chwilowej niestabilności łącza.

    Agent, który zostaje na widoku

    Agent, który zostaje na widoku
    Źródło: exafunction.github.io

    Optymalizacja panelu bocznego agenta odpowiada na frustrację użytkowników Cascade. Przy akcjach takich jak wysyłanie problemów do agenta czy wywoływanie „explain-and-fix”, panel wcześniej znikał, zmuszając do przełączania widoków w najmniej wygodnym momencie. Teraz pozostaje na swoim miejscu, więc podglądanie, co agent właśnie robi z kodem, nie wymaga dodatkowych kliknięć. Dla web developerów recenzujących automatyczne zmiany to oszczędność kilku sekund przy każdej interakcji — a tych w ciągu dnia potrafi być kilkadziesiąt.

    Sprzątanie po procesach i stabilność branchy

    Poza widocznymi funkcjami, wersja v3.4.22 zamyka kilka technicznych luk. Naprawiono problem z checkoutem branchy, który w określonych warunkach mógł pozostawiać repozytorium w niespójnym stanie. Ustabilizowano cache sesji, co jest istotne, gdy zespół uruchamia wiele równoległych agentów i przełącza się między kontekstami. Dodano również czyszczenie osieroconych procesów agenta: gdy sesja kończy się nieczysto, Devin Desktop sam sprząta pozostałości, zamiast zostawiać je w tle aż do restartu aplikacji.

    Co to oznacza w praktyce

    Omawiane poprawki nie są rewolucyjne, co można uznać za pozytyw. Devin Desktop dojrzewa jako narzędzie, które ma być predykcyjne i niewidoczne w momentach, gdy nie potrzebujesz go kontrolować. Automatyczny reconnect, dziedziczenie kontekstu Przestrzeni oraz sprzątanie procesów to zmiany, które odczuwasz przez ich brak — gdy coś nie działa. Wersja v3.4.22 eliminuje kilka drobnych, ale irytujących niedociągnięć. Dla web developerów i zespołów DevOps oznacza to mniej czasu na administrowanie agentem, a więcej na kodowanie i weryfikację wyników jego pracy.

    Źródła

  • Factory ulepsza zarządzanie hookami i dodaje przeszukiwanie czatów w wersji v0.161.0

    Factory ulepsza zarządzanie hookami i dodaje przeszukiwanie czatów w wersji v0.161.0

    Nowa aktualizacja Factory wprowadza przeprojektowany menedżer hooków, wsparcie dla terminala WezTerm oraz możliwość wyszukiwania bezpośrednio w transkryptach czatów. Dodatkowo, zoptymalizowano wydajność wyszukiwania, co redukuje zbędne przebudowy cache.

    Co nowego w skrócie

    • Menedżer hooków przeszedł redesign, co ułatwia przeglądanie i konfigurację hooków w projektach.
    • WezTerm zyskał oficjalne wsparcie w konfiguracji terminala, poszerzając dostępne opcje dla deweloperów.
    • Przeszukiwanie transkryptów czatów umożliwia szybkie odnalezienie wcześniejszych instrukcji i decyzji bez ręcznego scrollowania.
    • Optymalizacja cache przyspiesza działanie wyszukiwarki, eliminując niepotrzebne przebudowy po aktualizacjach.

    Co konkretnie zmieniło się w hookach

    System hooków w Factory to mechanizm uruchamiający skrypty powłoki w określonych momentach sesji Droida. Deweloperzy używają go do walidacji kodu, formatowania, logowania czy egzekwowania polityk bezpieczeństwa.

    Zarządzanie tymi skryptami bywało uciążliwe, szczególnie gdy hooki działały na różnych poziomach: użytkownika, projektu i organizacji. Przeprojektowany menedżer rozwiązuje ten problem. Teraz wszystkie hooki są widoczne w jednym widoku, a ich konfiguracja jest bardziej przejrzysta.

    Dla zespołów, które polegają na hookach przy automatyzacji, ta zmiana oznacza mniej czasu spędzonego na debugowaniu konfiguracji. W praktyce szybciej można zidentyfikować, który hook zawodzi i dlaczego.

    WezTerm dołącza do obsługiwanych terminali

    Do tej pory Factory oferowało integrację z popularnymi emulatorami terminala, ale WezTerm, często wybierany przez zwolenników szybkich narzędzi, nie miał oficjalnego wsparcia. Od wersji v0.161.0 konfiguracja terminala obejmuje również to środowisko.

    WezTerm zyskuje popularność dzięki akceleracji GPU i możliwości działania na Windows, macOS i Linuksie bez zmian w konfiguracji. Dla deweloperów przyzwyczajonych do tego emulatora to oznacza, że Factory traktuje niszowe, ale wydajne narzędzia poważnie.

    Przeszukiwanie czatu zmienia workflow

    Funkcja przeszukiwania czatów ma istotny wpływ na codzienną pracę. Transkrypty czatów w Factory mogą zawierać setki wiadomości, szczególnie przy dłuższych sesjach vibe codingu, gdzie kontekst z wcześniejszych promptów często zawiera kluczowe decyzje implementacyjne.

    Możliwość wyszukania konkretnej frazy w historii czatu oszczędza frustracji. Zamiast przewijać całą konwersację, wystarczy wpisać fragment instrukcji czy nazwę pliku, aby trafić od razu do właściwego momentu sesji.

    Co z wydajnością

    Optymalizacja cache to zmiana, która może być niewidoczna na pierwszy rzut oka, ale odczuwalna przy intensywnym korzystaniu z wyszukiwarki. Factory zmniejszyło liczbę zbędnych przebudów cache po aktualizacjach i zmianach konfiguracji.

    W większych projektach, gdzie wyszukiwanie dotyczy zarówno kodu, jak i metadanych sesji, każda sekunda ma znaczenie. Mniej rebuildów oznacza również mniejsze zużycie zasobów, co jest istotne przy pracy na lokalnych maszynach z ograniczoną pamięcią.

    Dlaczego te zmiany mają znaczenie

    Te trzy usprawnienia — hooki, WezTerm i przeszukiwanie czatów — mają wspólny cel: skracają dystans między intencją dewelopera a wykonaniem zadania. Hooki stają się łatwiejsze do ogarnięcia, terminal działa tam, gdzie deweloper chce pracować, a historia rozmów przestaje być trudna do przeszukiwania.

    Wersja v0.161.0 nie wprowadza rewolucji, ale jest to zestaw przemyślanych poprawek, które docenią ci, którzy spędzają w Factory długie godziny, szczególnie przy projektach opartych o AI, gdzie szybki dostęp do kontekstu i sprawne automatyzacje mają kluczowe znaczenie dla tempa pracy.

    Źródła

  • Claude Code 2.1.195: Precyzyjna kontrola myszy w trybie pełnoekranowym i poprawki dyktowania

    Claude Code 2.1.195: Precyzyjna kontrola myszy w trybie pełnoekranowym i poprawki dyktowania

    Anthropic wypuściło 26 czerwca 2026 roku aktualizację Claude Code 2.1.195, która wprowadza nową zmienną środowiskową do zarządzania interakcjami myszy w terminalu oraz naprawia kilka błędów związanych z dyktowaniem głosowym i zarządzaniem wtyczkami. To wydanie koncentruje się na poprawie stabilności, co jest istotne zarówno w codziennej pracy programisty, jak i w sesjach zdalnych.

    Kluczowe zmiany w skrócie

    • CLAUDE_CODE_DISABLE_MOUSE_CLICKS – nowa zmienna środowiskowa blokująca kliknięcia, przeciąganie i najeżdżanie myszą w trybie pełnoekranowym, przy zachowaniu przewijania kółkiem
    • Dokładne dopasowanie hooków – naprawiono błąd, przez który identyfikatory z myślnikami (np. code-reviewer) uruchamiały się przy częściowym dopasowaniu nazwy
    • Poprawki dyktowania – macOS przestał gubić słowa w środku zdań, a języki bez spacji (japoński, chiński, koreański, tajski) działają teraz poprawnie
    • Bezpieczniejsza instalacja wtyczek – zewnętrzne pluginy nie omijają już ekranu zgody przy niektórych ścieżkach ładowania

    Dlaczego kontrola myszy w terminalu ma znaczenie

    Tryb pełnoekranowy w Claude Code to środowisko, w którym programiści spędzają długie godziny. Przypadkowe kliknięcie może przerwać zaznaczenie tekstu, przesunąć kursor w nieoczekiwane miejsce albo wywołać nieplanowaną akcję. Zmienna CLAUDE_CODE_DISABLE_MOUSE_CLICKS rozwiązuje ten problem, wyłączając kliknięcia, przeciąganie i hover, ale pozostawiając możliwość przewijania kółkiem. Dzięki temu można przeglądać długie logi czy output komend bez ryzyka przypadkowej interakcji.

    To szczególnie przydatne w środowiskach DevOps, gdzie sesje terminalowe często działają na zdalnych serwerach przez wiele godzin. Każde niechciane kliknięcie mogło wcześniej prowadzić do utraty kontekstu lub konieczności cofania zmian.

    Hooki przestały się mylić – dokładne dopasowanie identyfikatorów

    W ekosystemie wtyczek i serwerów MCP nazwy z myślnikami są powszechne. Identyfikatory takie jak code-reviewer, mcp__brave-search to standard w automatyzacji. Problem polegał na tym, że hooki dopasowywały się przez substring, co prowadziło do nieoczekiwanych akcji pobocznych.

    W wersji 2.1.195 mechanizm hooków przeszedł na dokładne dopasowanie. Każdy identyfikator jest teraz sprawdzany w całości, co eliminuje niespodzianki przy złożonych pipeline'ach automatyzacji. Dla zespołów utrzymujących rozbudowane zestawy narzędzi to oszczędność czasu na debugowaniu.

    Dyktowanie głosowe – języki bez spacji w końcu działają

    Dyktowanie głosowe – języki bez spacji w końcu działają

    Użytkownicy macOS zgłaszali problemy z gubieniem słów podczas dyktowania. Claude Code gubił wyrazy w środku zdań, co przy kodowaniu głosowym prowadziło do frustracji. Aktualizacja naprawia ten błąd.

    Dodatkowo, wprowadzono wsparcie dla języków, które nie używają spacji między słowami – japońskiego, chińskiego, koreańskiego i tajskiego. Wcześniej automatyczne zatwierdzanie tekstu w tych językach nie działało poprawnie. Teraz mechanizm auto-submit rozpoznaje granice poprawnie, co ułatwia dyktowanie promptów w tych językach.

    Wtyczki i procesy w tle – mniej niespodzianek

    Wtyczki i procesy w tle – mniej niespodzianek

    W kontekście bezpieczeństwa, zewnętrzne pluginy przy niektórych ścieżkach ładowania omijały ekran zgody na instalację. Claude Code 2.1.195 zamyka tę lukę – każda instalacja przechodzi przez standardowy proces akceptacji. To istotna zmiana w środowiskach korporacyjnych, gdzie audyt narzędzi jest wymagany.

    Poprawiono również obsługę demonów agentów w tle. Sesje zdalne i długotrwałe procesy, które wcześniej mogły się zawiesić, działają teraz stabilniej. Zaktualizowano checklistę provisioningu dla sesji Remote, co sprawia, że start środowisk zdalnych jest bardziej przewidywalny.

    Co to oznacza dla web developerów i DevOps

    Wydanie 2.1.195 nie wprowadza spektakularnych nowości wizualnych, ale poprawia codzienną pracę. Kontrola myszy w terminalu to istotna zmiana, która doceni każdy, kto doświadczył problemów z przypadkowymi kliknięciami w trybie pełnoekranowym. Dokładne dopasowanie hooków eliminuje ciche błędy w pipeline'ach automatyzacji, a poprawki dyktowania ułatwiają pracę zespołom spoza kręgu anglojęzycznego.

    Wszystkie zmiany wchodzą automatycznie przy aktualizacji – wystarczy standardowe claude update i restart sesji. Jeśli używasz trybu pełnoekranowego, warto rozważyć ustawienie nowej zmiennej środowiskowej.

    Źródła

  • Gemini CLI z poprawkami w pipeline wydawniczym – nowy nightly build v0.51.0

    Gemini CLI z poprawkami w pipeline wydawniczym – nowy nightly build v0.51.0

    26 czerwca 2026 roku ukazał się kolejny nightly build narzędzia Gemini CLI – wersja v0.51.0-nightly.20260626.gb14416447. To wydanie koncentruje się głównie na stabilności procesu publikacji paczek npm oraz infrastrukturze CI/CD, a nie na nowych funkcjach dla końcowego użytkownika. Dla zespołów korzystających z automatycznych wdrożeń to ważny krok naprzód.

    Co przynosi nowa wersja

    • Zabezpieczenie przed błędnymi publikacjami – poprawka zapobiega wypuszczaniu niekompletnych paczek npm oraz awariom zadania promote-job w pipeline.
    • Usprawnione odkrywanie rejestru narzędzi – wersja testuje mechanizmy enhanced tool registry discovery, które mają ułatwić integrację z zewnętrznymi zestawami narzędzi.
    • Raportowanie inwentaryzacji ewaluacji – nowa funkcjonalność inventory reporting pozwala lepiej śledzić wykorzystanie zasobów podczas testów wydajnościowych.
    • Optymalizacje CI/CD – kilka poprawek w procesach ciągłej integracji zwiększa niezawodność nocnych wydań.
    • Poprawka głodzenia pętli zdarzeń – poprawka zapobiega sytuacjom, w których scheduler mógł blokować wykonywanie zadań asynchronicznych.

    Stabilność wydawania zamiast nowych funkcji

    Nightly build, oznaczony jako pre-release, powstaje automatycznie z gałęzi głównej i publikowany jest codziennie zgodnie z harmonogramem UTC. Nie przechodzi pełnej walidacji – zespoły Google'a ostrzegają, że może zawierać niedokończone zmiany. Mimo to dla wielu developerów to okazja do zapoznania się z najnowszymi poprawkami, zanim trafią do stabilnego wydania.

    W tej wersji zmiany między poprzednim nightly (v0.51.0 z 25 czerwca) a obecnym obejmują przede wszystkim commit bota wydawniczego Gemini CLI. Bot automatycznie podnosi wersję i uruchamia pipeline – tym razem z dodatkowym fixem, który eliminuje ryzyko wysłania do rejestru npm uszkodzonego artefaktu.

    Chociaż pełna lista scalonych zmian nie jest dostępna w publicznym changelogu, z kontekstu infrastrukturalnego wynika, że Google intensywnie pracuje nad tym, aby nocne wydania były bardziej przewidywalne.

    Co to oznacza dla zespołów DevOps

    Co to oznacza dla zespołów DevOps

    Dla ekip zajmujących się utrzymywaniem środowisk CI/CD to wydanie ma praktyczne znaczenie. Naprawienie crashy promote-job oznacza mniej ręcznej interwencji przy wdrożeniach. Jeśli wasz pipeline automatycznie pobiera nightly buildy, ryzyko napotkania uszkodzonej paczki właśnie spadło.

    Wersje nightly instalują się z tagiem nightly – to świadoma decyzja, ponieważ nie każdy build przechodzi testy integracyjne. Jednak dla projektów śledzących rozwój narzędzi AI, takich jak Gemini CLI, te codzienne snapshoty są nieocenione. Pokazują kierunek rozwoju szybciej niż oficjalne changelogi.

    Kontekst szerszego ekosystemu

    Kontekst szerszego ekosystemu

    Gemini CLI wpisuje się w trend narzędzi programistycznych opartych na dużych modelach językowych. W przeciwieństwie do Cursor czy Windsurf, które stawiają na interfejs graficzny, to rozwiązanie pozostaje w terminalu – tam, gdzie pracują zespoły DevOps i inżynierowie platform.

    Wydania nightly przypominają filozofię znaną z ekosystemu open source: szybkie iteracje, ciągła integracja, minimalna biurokracja przy wydawaniu. Dla Google'a to także poligon doświadczalny – błędy wyłapane w kanale nightly nie trafiają do stabilnych wydań, co chroni użytkowników produkcyjnych.

    Wnioski

    Wersja v0.51.0-nightly.20260626 nie wprowadza przełomowych funkcji, ale wzmacnia fundamenty. Dla kogoś, kto patrzy tylko na listę funkcji, to wydanie może wydawać się nieciekawe. Dla inżyniera odpowiedzialnego za pipeline CI/CD to konkretna oszczędność czasu – mniej nocnych alertów i mniej ręcznego czyszczenia po nieudanych release'ach. W świecie, gdzie narzędzia AI zmieniają się z dnia na dzień, stabilność procesu wydawniczego jest równie ważna jak nowe możliwości samego modelu.

    Źródła

  • Gemini CLI zyskuje automatyczne wykrywanie narzędzi – wersja v0.50.0-preview.1 już dostępna

    Gemini CLI zyskuje automatyczne wykrywanie narzędzi – wersja v0.50.0-preview.1 już dostępna

    Google wprowadziło 25 czerwca 2026 roku wersję preview Gemini CLI v0.50.0-preview.1, która wprowadza mechanizm automatycznego wykrywania narzędzi oraz poprawki stabilizujące proces wydania. To ostatni krok przed stabilnym wydaniem linii 0.50, które miało miejsce 8 lipca.

    Kluczowe zmiany w skrócie

    • Automatyczne wykrywanie narzędzi – CLI samodzielnie znajduje i rejestruje dostępne narzędzia, bez potrzeby ręcznej konfiguracji.
    • Zabezpieczenie przed shadowingiem binariów – mechanizm zapobiega przypadkowemu nadpisywaniu plików wykonywalnych w workspace.
    • Izolacja skryptów npm podczas weryfikacji – proces weryfikacji wydania ignoruje teraz skrypty z package.json, co eliminuje ryzyko ubocznych efektów.
    • Ochrona CI przed uszkodzonymi wydaniami NPM – dodatkowe zabezpieczenia zapobiegają awariom pipeline'u przy błędnych publikacjach.

    Automatyczny rejestr narzędzi – co to zmienia w praktyce

    Najważniejszą nowością jest mechanizm automatycznego wykrywania narzędzi. W poprzednich wersjach Gemini CLI użytkownik musiał jawnie definiować dostępne narzędzia, co wymagało wiedzy na temat tego, z czym agent może pracować. Teraz CLI skanuje środowisko, wykrywa dostępne narzędzia i rejestruje je bez ingerencji człowieka.

    Dla deweloperów korzystających z vibe codingu oznacza to krótszy czas konfiguracji oraz mniej błędów wynikających z niekompletnych definicji. Agent AI otrzymuje pełny obraz dostępnych narzędzi, w tym linterów, narzędzi do testowania oraz zewnętrznych API. Zmiana ta wpisuje się w szerszy trend w narzędziach wspomagających rozwój oprogramowania: im mniej konfiguracji, tym szybciej można przejść do pracy.

    Wdrożenie opiera się na czterech pull requestach: #28116, #28132, #28113 i #28147. Cały zakres zmian między poprzednią wersją preview a obecną obejmuje porównanie v0.49.0-preview.0…v0.50.0-preview.1.

    Stabilność CI i weryfikacja wydań – mniej niespodzianek w pipeline

    Drugim istotnym elementem aktualizacji są poprawki w procesie weryfikacji wydania. Zespół Google zidentyfikował kilka newralgicznych punktów, które mogły prowadzić do niestabilnych wydań.

    Po pierwsze, dodano flagę ignorowania skryptów npm podczas weryfikacji. Oznacza to, że etap sprawdzania poprawności builda nie uruchamia już potencjalnie niebezpiecznych lub długotrwałych skryptów zdefiniowanych w package.json. To może zaoszczędzić czas w dużych monorepo.

    Po drugie, mechanizm ochrony przed shadowingiem binariów zapobiega sytuacji, w której lokalne pliki wykonywalne w workspace przysłaniają te systemowe. Problem ten był szczególnie dokuczliwy w środowiskach z wieloma równoległymi procesami budowania.

    Dodatkowe zabezpieczenia przed uszkodzonymi wydaniami NPM sprawiają, że pipeline nie przestaje działać przy pierwszej napotkanej nieprawidłowości w rejestrze pakietów. Dla zespołów DevOps, które utrzymują własne instancje CI, to wymierna korzyść – mniej fałszywych alarmów i nieplanowanych przestojów.

    Co dalej z linią 0.50

    Wszystkie zmiany z preview trafiły w niezmienionej formie do stabilnego wydania v0.50.0 z 8 lipca. Changelog stabilnej wersji opisuje te same motywy przewodnie: automatyczne wykrywanie narzędzi i poprawioną weryfikację wydań. To sugeruje, że Google było zadowolone z rezultatów testów preview i nie wprowadzało poprawek przed finalną publikacją.

    Projekt Gemini CLI rozwija się w szybkim tempie – w momencie pisania tego tekstu dostępne są już nightly buildy wersji 0.61, a najnowsze stabilne wydanie to 0.59. Narzędzie zmierza w kierunku coraz głębszej integracji z ekosystemem developerskim, gdzie agent AI działa jako naturalne rozszerzenie warsztatu programisty.

    Dla osób pracujących w modelu vibe coding kluczowe jest, by narzędzia same rozumiały kontekst. Automatyczny rejestr narzędzi to krok w tę stronę – mniej konfiguracji, więcej działania.

    Ź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