Autor: nidas

  • 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 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

  • Zed 1.10.2 z obsługą GPT-5.6 Sol i Terra – Luna jeszcze poza zasięgiem

    Zed 1.10.2 z obsługą GPT-5.6 Sol i Terra – Luna jeszcze poza zasięgiem

    Zed wprowadził aktualizację 1.10.2, która udostępnia modele GPT-5.6 Sol oraz Terra dla subskrybentów ChatGPT bezpośrednio w edytorze. To jest kontynuacja wersji 1.10.0. Trzeci model z nowej rodziny OpenAI – GPT-5.6 Luna – jest już dostępny w ChatGPT i API, zgodnie z informacjami od OpenAI.

    Co warto wiedzieć o nowej aktualizacji

    • GPT-5.6 Sol i Terra są dostępne w Zedzie jako modele hostowane, dostępne dla posiadaczy subskrypcji ChatGPT.
    • GPT-5.6 Luna jest częścią rodziny GPT-5.6 i według OpenAI jest dostępna w planach Plus, Pro, Business i Enterprise oraz w API.
    • 1.10.2 wprowadza integrację llama.cpp, konfigurowalne git blame oraz przeniesienie ustawień AI do panelu konfiguracji.
    • Rodzina GPT-5.6 obejmuje trzy modele – Sol, Terra i Luna – wszystkie są już dostępne przez OpenAI.

    Kontekst: co zmieniło się wcześniej w 1.10.0

    Wersja 1.10.0, która ukazała się 8 lipca 2026 roku, wprowadziła kilka istotnych usprawnień. Zed zyskał wsparcie dla llama.cpp jako nowego dostawcy modeli językowych, co pozwala użytkownikom uruchamiać lokalne modele bezpośrednio w edytorze, bez korzystania z zewnętrznych serwerów.

    Kolejna zmiana dotyczyła git blame. Deweloperzy dodali ustawienie git.inline_blame.location, które umożliwia kontrolowanie, czy informacje o autorze konkretnej linii kodu są wyświetlane obok niej, czy w pasku statusu. Można również opóźnić wyświetlanie tych danych, co zmniejsza wizualny szum podczas przeglądania kodu.

    Trzecim elementem 1.10.0 było uporządkowanie ustawień związanych ze sztuczną inteligencją. Konfiguracja dostawców LLM, zewnętrznych agentów oraz serwerów MCP została przeniesiona do dedykowanego panelu w edytorze ustawień, co ułatwiło zarządzanie tymi opcjami.

    GPT-5.6 w Zed – co działa, a na co trzeba poczekać

    Aktualizacja 1.10.2, wydana 10 lipca 2026 roku, koncentruje się na integracji z nową rodziną modeli OpenAI. W notatkach do wydania znajduje się informacja: „agent: Added GPT 5.6 Sol & Terra for ChatGPT subscription”. Oznacza to, że subskrybenci ChatGPT – w planach Plus, Pro, Business oraz Enterprise – mogą wybierać te modele z poziomu Zeda i korzystać z nich podczas pracy z kodem.

    OpenAI ogłosiło GPT-5.6 jako serię trzech wariantów, które są dostępne w API oraz w ChatGPT w zależności od planu. Sol, Terra i Luna są już dostępne przez OpenAI – również dla zastosowań zewnętrznych. W Zedzie Luna jest wymieniona w dokumentacji i tabelach cenowych, a jej dostępność w edytorze zależy od dalszych integracji po stronie Zeda.

    Dla użytkowników Zeda oznacza to prostą ścieżkę: jeśli masz aktywną subskrypcję ChatGPT, po aktualizacji do 1.10.2 od razu zobaczysz Sol i Terra na liście dostępnych modeli. Nie trzeba nic dodatkowo konfigurować – integracja działa przez wbudowanego agenta Zeda.

    Praktyczne znaczenie dla deweloperów

    Możliwość wyboru między Sol a Terra daje większą elastyczność w doborze modelu do konkretnego zadania. Sol sprawdza się tam, gdzie potrzebna jest szybka odpowiedź i zwięzłość, podczas gdy Terra lepiej radzi sobie z bardziej złożonymi zapytaniami wymagającymi głębszej analizy kontekstu. To szczególnie przydatne przy generowaniu kodu, refaktoryzacji czy debugowaniu.

    Warto również zwrócić uwagę na dokumentację hostowanych modeli Zeda – znajduje się tam pełna tabela cenowa uwzględniająca wszystkie trzy warianty GPT-5.6. Sugeruje to, że zespół Zeda przygotował już techniczną infrastrukturę pod Lunę i może udostępnić ją w edytorze w miarę postępu integracji.

    Co dalej z ekosystemem AI w Zed

    Zed systematycznie rozwija możliwości sztucznej inteligencji w edytorze. Integracja llama.cpp otworzyła drzwi do lokalnych modeli, a wsparcie dla GPT-5.6 umacnia pozycję Zeda jako środowiska przyjaznego programistom korzystającym z AI. Widać wyraźny kierunek: dać użytkownikom wybór między szybkimi modelami chmurowymi a prywatnymi, lokalnymi instancjami – wszystko w ramach jednego narzędzia.

    Aktualizacja 1.10.2, choć niewielka objętościowo, jest istotna funkcjonalnie. Pokazuje, że zespół Zeda szybko reaguje na zmiany w branży AI. OpenAI ogłosiło GPT-5.6, a Zed już wkrótce potem dostarcza integrację dla dwóch z trzech wariantów. Tempo rozwoju jest imponujące i dobrze wróży przyszłym aktualizacjom – zwłaszcza że pełna integracja Luny również jest na horyzoncie.

    Ź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

  • Factory v0.167.0: lepsza łączność z droidami i zauważalnie szybsze uruchamianie

    Factory v0.167.0: lepsza łączność z droidami i zauważalnie szybsze uruchamianie

    2 września 2026 roku Factory wydało aktualizację v0.167.0, która rozwiązuje dwa istotne problemy użytkowników pracujących ze zdalnymi maszynami: brak wygodnego przekierowania portów oraz wolne uruchamianie aplikacji. Nowa wersja wprowadza komendę droid computer port-forward oraz przyspiesza fazy startowe, co sprawia, że okno robocze pojawia się szybciej niż wcześniej.

    Co konkretnie się zmieniło

    • Nowa komenda droid computer port-forward umożliwia przekierowanie portów z komputera-droida na lokalną maszynę przez tunel przekaźnikowy.
    • Równoległe fazy startowe skracają czas od kliknięcia ikony do gotowego okna aplikacji — Factory informuje o „szybszym uruchamianiu”.
    • Pełnoekranowa nakładka pomocy oraz usprawniona nawigacja w menu slash ułatwiają odnajdywanie komend bez odrywania rąk od klawiatury.
    • Wyszukiwanie sesji również przyspieszono, chociaż twórcy nie podają konkretnych wartości procentowych.
    • Poprawki błędów — między innymi naprawiono wklejanie obrazków w systemie Windows oraz zawieszanie się sesji podczas inicjalizacji.

    Przekierowanie portów: jak to działa i dlaczego ma znaczenie

    Nowa komenda to nie tylko kolejna opcja w CLI. Oferuje składnię, która obsługuje mapowania w stylu LOKALNY:ZDALNY, sam ZDALNY lub :ZDALNY, a także umożliwia przekierowanie wielu portów w jednym wywołaniu. Komputery-droidy są automatycznie budzone przed nawiązaniem połączenia, więc nie trzeba osobno sprawdzać, czy maszyna zdalna jest aktywna.

    Ruch przechodzi przez istniejący tunel przekaźnikowy, ten sam, który obsługuje droid computer ssh. Nie ma potrzeby otwierania dodatkowych portów ani eksponowania ich na zewnątrz. Dla zespołów devopsowych i web developerów testujących serwisy na zdalnych środowiskach to znaczna oszczędność czasu i nerwów. Obsługiwany jest tylko TCP, więc na UDP trzeba będzie jeszcze poczekać.

    Brak przekierowania portów w pracy z droidami oznaczał konieczność korzystania z reverse proxy lub SSH z ręcznymi tunelami — wszystko było wykonalne, ale każda minuta spędzona na konfiguracji to czas stracony na właściwe kodowanie.

    Szybszy start i sprawniejsze szukanie sesji

    Uruchamianie aplikacji w poprzednich wersjach mogło być frustrujące. Proces startowy przebiegał w fazach, a zanim okno stało się interaktywne, mijało wystarczająco dużo czasu, aby zdążyć nalać sobie kawy. Teraz fazy startowe działają równolegle — to nie jest rewolucja architektoniczna, ale solidna decyzja inżynieryjna. Efekt jest odczuwalny od pierwszego kliknięcia.

    Wyszukiwanie sesji również zyskało na szybkości. Factory nie podaje konkretnych liczb, ale przy rosnącej liczbie zapisanych sesji nawet drobna optymalizacja zapytań czy indeksowania ma znaczenie, szczególnie gdy próbujesz szybko wrócić do wczorajszego kontekstu.

    Te zmiany mają na celu zmniejszenie tarcia przy przełączaniu się między zadaniami. W pracy z AI-asystentem, gdzie sesje mogą trwać godzinami, każda sekunda opóźnienia przy starcie czy wyszukiwaniu może wybić z rytmu.

    Interfejs i garść poprawek

    Oprócz wydajności i łączności, v0.167.0 wprowadza pełnoekranową nakładkę z pomocą — szczególnie przydatną dla nowych użytkowników, którzy nie znają jeszcze wszystkich skrótów i komend. Usprawniono również nawigację w menu slash, co sprawia, że wybieranie akcji podczas pisania promptów działa płynniej.

    Jeśli chodzi o błędy, zespół Factory rozwiązał problem z wklejaniem obrazków na Windowsie — użytkownicy tego systemu mogą teraz normalnie dodawać zrzuty ekranu do sesji. Naprawiono również zawieszanie się inicjalizacji sesji oraz poprawiono ogólną stabilność. Choć te poprawki nie przyciągają uwagi, to właśnie takie detale decydują o codziennej użyteczności narzędzia.

    Co z tego wynika

    Aktualizacja nie wprowadza przełomowych zmian w sposobie pracy, ale odpowiada na potrzeby użytkowników Factory. Przekierowanie portów eliminuje problem pracy ze zdalnymi droidami, a przyspieszenie startu i wyszukiwania to inwestycja w płynność codziennych procesów. Jeśli twoja praca polega na szybkim testowaniu serwisów na zdalnych maszynach lub zarządzaniu wieloma sesjami AI, warto zainstalować v0.167.0 bez zwłoki.

    Źródła

  • Zed 1.10.0 wprowadza wsparcie dla llama.cpp i porządkuje zarządzanie ustawieniami

    Zed 1.10.0 wprowadza wsparcie dla llama.cpp i porządkuje zarządzanie ustawieniami

    Zed wydał wersję 1.10.0 8 lipca 2026 roku, a główną nowością jest dodanie llama.cpp jako oficjalnego dostawcy modeli językowych. Dzięki temu funkcje AI w edytorze, takie jak agent i asystent inline, mogą teraz działać na modelach lokalnych, eliminując potrzebę łączenia się z zewnętrznymi API. Aktualizacja zmienia także sposób zarządzania konfiguracją, przenosząc dostawców LLM, zewnętrznych agentów i serwery MCP bezpośrednio do edytora ustawień.

    Kluczowe fakty

    • llama.cpp stał się oficjalnym dostawcą modeli językowych, co umożliwia lokalną inferencję w agencie i asystencie inline.
    • Formatowanie przy zapisie zostało domyślnie wyłączone, co daje użytkownikowi możliwość wyboru automatycznej korekty kodu.
    • Nowe ustawienie git.inline_blame.location pozwala na wyświetlanie informacji o autorze kodu w pasku statusu zamiast bezpośrednio w edytorze.
    • Konsolidacja ustawień AI – dostawcy LLM, zewnętrzni agenci i serwery MCP zostały przeniesione do głównego edytora konfiguracji.

    Lokalne modele bez chmury

    Integracja llama.cpp to krok, na który wielu użytkowników Zed czekało od dawna. Do tej pory lokalne modele wymagały konfiguracji przez niestandardowe endpointy, co było obejściem, a nie rozwiązaniem pierwszoklasowym. Teraz wystarczy wskazać instancję llama.cpp w ustawieniach, a Zed automatycznie wykryje dostępne modele i udostępni je w panelu agenta.

    To istotna zmiana dla zespołów, które z powodów regulacyjnych lub bezpieczeństwa nie mogą wysyłać kodu na zewnętrzne serwery. Dokumentacja Zed potwierdza, że użytkownicy mogą konfigurować nie tylko endpoint, ale także długość kontekstu i klucze API dla serwerów zdalnych, co zapewnia dużą elastyczność.

    Społeczność już dyskutuje o rozszerzeniu tej funkcjonalności. Na GitHubie pojawił się wątek z propozycją wsparcia dla wielu instancji llama.cpp jednocześnie, co pozwoliłoby na korzystanie z jednej maszyny z dużą ilością VRAM do ciężkich modeli, a z innej – lżejszej – do szybkich zadań pomocniczych.

    Konfiguracja AI w jednym miejscu

    Kolejna zmiana, która ucieszy osoby zarządzające środowiskami deweloperskimi, to konsolidacja ustawień. Dostawcy LLM, zewnętrzni agenci i konfiguracja serwerów MCP zostały przeniesione do głównego edytora ustawień. Użytkownicy nie muszą już przeszukiwać osobnych plików ani pamiętać, gdzie co się konfiguruje – wszystko jest w jednym miejscu, razem z innymi opcjami edytora.

    To może wydawać się drobiazgiem, ale w praktyce oszczędza sporo frustracji. Kiedy dołączasz do nowego projektu i musisz szybko skonfigurować środowisko, scentralizowane ustawienia robią różnicę między "działam od razu" a "gdzie ja to ustawiałem ostatnim razem".

    Formatowanie na własnych zasadach

    Zed 1.10.0 domyślnie wyłącza formatowanie przy zapisie. Wyjątkiem są języki z oficjalnymi formaterami, takimi jak Prettier dla JS/TS, gofmt dla Go i podobne, gdzie automatyczne formatowanie nadal działa. Dla wszystkich innych języków trzeba teraz jawnie włączyć editor.format_on_save: true.

    To przemyślana decyzja. W repozytoriach mieszanych, gdzie różne pliki formatują się różnymi narzędziami, automatyczne formatowanie może wprowadzać zamieszanie. Zed daje użytkownikom pełną kontrolę – chcąc formatować, można to włączyć. Jeśli nie, edytor nie zmienia kodu bez pytania.

    Git bez zagracania ekranu

    Nowe ustawienie git.inline_blame.location rozwiązuje problem z zajmowaniem przestrzeni w edytorze. Zamiast wyświetlać informacje o autorze bezpośrednio w kodzie, co może zaburzać wizualną strukturę pliku, można je przenieść do paska statusu. Podczas przeglądania kodu czy debugowania to naprawdę wygodne – widzisz, kto ostatnio zmieniał linię, ale nie tracisz kontekstu edytowanego kodu.

    Wydanie zawiera również wiele poprawek – od wycieku deskryptorów plików na Linuksie, przez usprawnienia w trybie Helix, po lepsze podświetlanie składni dla Go i Pythona. Zed wyraźnie nie zwalnia tempa, a dziesiąta wersja w tym roku pokazuje, że edytor rozwija się w przemyślanym kierunku.

    Źródła

  • Codex 0.143.0 wchodzi z domyślnymi wtyczkami zdalnymi i wsparciem dla proxy systemowego

    Codex 0.143.0 wchodzi z domyślnymi wtyczkami zdalnymi i wsparciem dla proxy systemowego

    OpenAI wypuściło wersję 0.143.0 swojego agenta kodowania Codex, wprowadzając trzy kluczowe zmiany: domyślnie włączone wtyczki zdalne, rozszerzoną obsługę proxy systemowego na macOS i Windows oraz integrację z modelami Codex 0.143.0 przez Amazon Bedrock. Aktualizacja zawiera również poprawki dla terminala Windows, lepsze odzyskiwanie serwerów wykonawczych oraz zaktualizowane zależności bezpieczeństwa.

    Najważniejsze zmiany

    • Wtyczki zdalne są teraz domyślnie aktywne, z ulepszonym interfejsem marketplace i źródłami npm.
    • Proxy systemowe obsługuje ruch uwierzytelniający i API przez konfiguracje PAC oraz WPAD na macOS i Windows.
    • Amazon Bedrock zyskał routing dla wariantów Codex 0.143.0, w tym modeli Sol, Terra i Luna.
    • Wyszukiwanie narzędzi MCP zostało rozbudowane z myślą o dużych katalogach narzędziowych.
    • Poprawki stabilności objęły obsługę terminala Windows i odzyskiwanie po awarii serwerów wykonawczych.

    Domyślne wtyczki i nowy marketplace

    Do tej pory zdalne rozszerzenia w Codex wymagały ręcznego włączania. Teraz są aktywne od razu po instalacji. Marketplace zyskał czytelniejsze karty katalogowe, które jasno rozróżniają wersje zdalne od lokalnych. To ułatwienie oszczędza czas przy zarządzaniu wtyczkami.

    Dla zespołów DevOps dodano źródła npm jako kanał dystrybucji wtyczek. Oznacza to, że można teraz pobierać rozszerzenia bezpośrednio z rejestru npm, co upraszcza proces. W przypadku pipeline'ów CI i współdzielonych workspace'ów wystarczy wskazać pakiet, a Codex sam zajmie się resztą.

    Proxy systemowe dla środowisk korporacyjnych

    Wersja 0.143.0 odpowiada na problem restrykcji sieciowych w środowiskach korporacyjnych, wspierając proxy systemowe na macOS i Windows, w tym konfiguracje PAC (Proxy Auto-Configuration) i WPAD (Web Proxy Auto-Discovery). Codex potrafi teraz prowadzić ruch uwierzytelniający i zapytania do API przez firmowe proxy, bez potrzeby ręcznego ustawiania zmiennych środowiskowych.

    To zmiana, która może nie być zauważona w release notes, ale ma kluczowe znaczenie dla funkcjonalności narzędzia w zamkniętych sieciach korporacyjnych. Zespoły pracujące w takich środowiskach mogą być spokojne.

    Amazon Bedrock i modele Codex 0.143.0

    Codex 0.143.0 rozszerza integrację z Amazon Bedrock o konkretne warianty Codex 0.143.0. Dokumentacja OpenAI wymienia trzy identyfikatory modeli: openai.codex-0.143.0-sol (zalecany jako domyślny), openai.codex-0.143.0-terra oraz openai.codex-0.143.0-luna. Każdy z nich oferuje maksymalne możliwości wnioskowania, a routing przez Bedrock oznacza, że cały ruch pozostaje w infrastrukturze kontrolowanej przez AWS.

    To ważne rozróżnienie: zamiast wysyłać zapytania bezpośrednio do endpointów OpenAI, zespoły mogą przechowywać dane w swoim VPC. Dla firm z wymogami compliance i suwerenności danych to rozwiązanie, które nie wymaga kompromisów w zakresie bezpieczeństwa.

    Narzędzia MCP i poprawki techniczne

    Narzędzia MCP i poprawki techniczne

    Wyszukiwanie narzędzi MCP (Model Context Protocol) zostało usprawnione, co ułatwia pracę z rozbudowanymi katalogami. Gdy agent ma do dyspozycji wiele narzędzi, szybkie odnalezienie właściwego staje się kluczowe — nowa wersja radzi sobie z tym lepiej, szczególnie w dużych workspace'ach.

    W kwestii stabilności poprawiono obsługę terminala na Windows, a serwery wykonawcze zyskały mechanizm odzyskiwania po awarii. Dodatkowo zaktualizowano zależności bezpieczeństwa, co jest standardem przy każdym wydaniu, ale wciąż istotnym elementem.

    Co to oznacza w praktyce

    Codex 0.143.0 to wydanie, które odpowiada na potrzeby pracy zespołowej i środowisk z restrykcjami. Domyślne wtyczki zdalne ułatwiają korzystanie z narzędzia dla nowych użytkowników, proxy systemowe rozwiązują problemy administratorów, a Bedrock zapewnia kontrolę nad miejscem, w którym przetwarzane są zapytania. Choć zmiany te mogą nie być od razu widoczne w interfejsie, mają kluczowe znaczenie dla funkcjonowania Codex w firmowej sieci oraz dla akceptacji przez zespół bezpieczeństwa.

    Źródła

  • OpenCode łata błędy z.ai i odświeża interfejs – mniej frustracji przy długich promptach

    OpenCode łata błędy z.ai i odświeża interfejs – mniej frustracji przy długich promptach

    Najnowsza aktualizacja OpenCode została udostępniona użytkownikom w połowie września 2026 roku. Skupia się na dwóch głównych obszarach: poprawie raportowania błędów związanych z przekroczeniem okna kontekstowego z.ai oraz wprowadzeniu poprawek wizualnych w aplikacji desktopowej. Zmiany te nie są rewolucyjne, ale znacząco zmniejszają liczbę mylących komunikatów i poprawiają komfort codziennej pracy.

    Co nowego w tej aktualizacji

    • Klasyfikacja błędów z.ai – przepełnienie okna kontekstowego jest teraz rozpoznawane i komunikowane jako konkretny tryb awarii, a nie ogólny błąd.
    • Przywrócone etykiety modeli – tooltipy z nazwami modeli wróciły do interfejsu po wcześniejszym usunięciu.
    • Odświeżona paleta poleceń v2 – przeprojektowany wygląd i lepsza responsywność przy wywoływaniu komend.
    • Poprawki dla macOS Sequoia – belka tytułowa i kontrolki okna wyświetlają się teraz prawidłowo.
    • Bezpieczniejszy fallback konfiguracji – brakujące katalogi config/cache nie powodują już awarii aplikacji.

    Lepsza diagnostyka, czyli koniec z enigmatycznymi błędami

    Przekroczenie okna kontekstowego to błąd, który potrafi zirytować nawet doświadczonego developera. Wysyłając prompt, model zaczyna przetwarzać, a po chwili otrzymujesz komunikat, który niewiele mówi o przyczynie. W przypadku z.ai, dostawcy modeli językowych używanego przez OpenCode, problem był szczególnie uciążliwy, ponieważ zbyt duże zapytania kończyły się mało precyzyjnym feedbackiem.

    Nowa wersja OpenCode wprowadza lepszą klasyfikację tych sytuacji. System rozpoznaje, że przyczyna leży w rozmiarze żądania względem limitu okna kontekstowego i komunikuje to w sposób zrozumiały. Nie musisz już zgadywać, czy problem dotyczy autoryzacji, timeoutu po stronie serwera, czy czegoś innego. Dla osób pracujących z długimi promptami, co jest normą przy debugowaniu złożonych baz kodowych, to oszczędność nerwów i czasu.

    Zmiana ta wpisuje się w szerszy trend w rozwoju OpenCode: zespół koncentruje się na poprawie niezawodności integracji z konkretnymi dostawcami, zamiast dodawać nowe funkcje. Poprzednie aktualizacje również zawierały poprawki dotyczące Bedrocka, Together AI czy GitHub Copilot, co pokazuje podobną filozofię.

    Desktop w końcu dopieszczony

    Desktop w końcu dopieszczony

    Równolegle z poprawkami błędów wprowadzono zmiany w interfejsie. Użytkownicy macOS Sequoia skarżyli się na wygląd belki tytułowej – kontrolki zamykania i minimalizacji okna były źle wyrównane lub stylowane niezgodnie z resztą systemu. Aktualizacja to naprawia, więc okno OpenCode nie odstaje już wizualnie od innych aplikacji.

    Wróciły także tooltipy modeli. Po wcześniejszym usunięciu, teraz znów pojawiają się przy najechaniu na nazwę modelu, co ułatwia szybką orientację bez konieczności klikania w ustawienia. Paleta poleceń v2 zyskała nowy wygląd, a skróty terminalowe mają teraz wyższy priorytet – terminal przechwytuje je jako pierwszy, co eliminuje konflikty z akcjami w interfejsie.

    Co z tymi katalogami konfiguracyjnymi?

    Co z tymi katalogami konfiguracyjnymi?

    Mniej widoczna, ale równie ważna zmiana dotyczy obsługi brakujących lub uszkodzonych katalogów konfiguracyjnych. Zdarza się to częściej, niż mogłoby się wydawać: reinstalacja, migracja na inny system, agresywne czyszczenie dysku przez narzędzia takie jak CleanMyMac. W takich sytuacjach OpenCode potrafił zachowywać się nieprzewidywalnie.

    Nowa wersja radzi sobie z tym znacznie lepiej. Zamiast crashować lub wyświetlać pusty interfejs, aplikacja stosuje bezpieczny fallback. Dokumentacja dotycząca rozwiązywania problemów została również rozszerzona o konkretne ścieżki czyszczenia cache i resetowania stanu na macOS, Linuxie i Windowsie. Jeśli coś pójdzie nie tak, masz jasno opisaną procedurę naprawczą bez potrzeby szukania pomocy na forach.

    Warto zaktualizować

    Choć to wydanie nie przynosi spektakularnych nowości, jest jednym z tych, które realnie wpływają na codzienną pracę. Mniej mylących błędów, lepiej wyglądający interfejs i bezpieczniejsza obsługa plików konfiguracyjnych – to wszystko składa się na narzędzie, które po prostu mniej przeszkadza. Jeśli używasz z.ai jako dostawcy i pracujesz na macOS, aktualizacja jest praktycznie obowiązkowa. Dla pozostałych użytkowników to solidny zestaw poprawek bez ryzyka regresji.

    Źródła

  • Claude Code 2.1.202: dynamiczne workflow i lepsza zdalna kontrola agentów

    Claude Code 2.1.202: dynamiczne workflow i lepsza zdalna kontrola agentów

    Anthropic udostępniło 6 lipca 2026 wersję 2.1.202 Claude Code — aktualizację, która wprowadza konfigurowalny rozmiar dynamicznych workflow, rozszerza śledzenie agentów przez OpenTelemetry i naprawia kilkanaście uciążliwych błędów. W tej wersji wprowadzono cztery nowe funkcje oraz trzynaście poprawek stabilizujących.

    Zespół Anthropica zajął się poprawą Remote Control, co jest istotne, ponieważ wcześniejsze problemy z łącznością były uciążliwe dla zespołów pracujących zdalnie. Zmiana w komendzie /review przyspiesza proces przeglądania zwykłych pull requestów, a bardziej złożone analizy przeniesiono do osobnego polecenia.

    Kluczowe zmiany w pigułce

    • Dynamiczny rozmiar workflow — użytkownicy mogą teraz wybrać small, medium lub large jako wytyczną, co przekłada się na mniej niż 5, 10 lub 50 agentów w zadaniu.
    • OpenTelemetry dla agentów — workflowowe agenty raportują teraz atrybuty workflow.run_id i workflow.name, co umożliwia odtworzenie ich aktywności z danych telemetrycznych.
    • Szybsze /review — standardowe sprawdzenie PR działa teraz jako szybki jednoprzebiegowy przegląd; wieloagentowe recenzje trafiły do /code-review.
    • Poprawki Remote Control — naprawiono błąd "Unknown command", problem z cichym porzucaniem obrazków bez podpisów oraz nieprawidłowe wyświetlanie trybu uprawnień w aplikacjach mobilnych.

    Dynamiczny rozmiar — elastyczność zamiast sztywnych limitów

    Do tej pory Claude Code uruchamiał dynamiczne workflow w dość nieprzewidywalny sposób — użytkownik nie miał dużej kontroli nad tym, ile agentów zostanie zaangażowanych w zadanie. Wersja 2.1.202 wprowadza nowe ustawienie w /config.

    Opcje small, medium i large działają jako doradcza wytyczna — nie są twardym limitem, więc środowisko wykonawcze może je przekroczyć, jeśli zadanie tego wymaga. W praktyce small oznacza mniej niż 5 agentów, medium poniżej 10, a large poniżej 50. Dla zespołów zajmujących się agentic coding to sensowna kontrola: małe zadania nie będą niepotrzebnie rozdymane, a przy dużych repozytoriach można zwiększyć skalę.

    Dokumentacja podkreśla, że funkcja wymaga minimum wersji 2.1.202 — starsze instalacje jej nie obsłużą.

    OpenTelemetry: widać, co robią agenty

    Dla zespołów DevOps i osób zajmujących się obserwowalnością, wprowadzenie atrybutów workflow.run_id i workflow.name w danych OpenTelemetry to znaczący postęp. Do tej pory śledzenie, co dokładnie wydarzyło się wewnątrz złożonych workflow agentowych, wymagało ręcznego przeszukiwania logów. Teraz można to zrekonstruować bezpośrednio z pipeline'ów OTel.

    Oznacza to, że narzędzia monitorujące zyskują kontekst — widać, który konkretnie workflow wygenerował daną aktywność i jakie agenty brały w nim udział. Dla zespołów zarządzających wieloma równoległymi procesami to oszczędność czasu przy debugowaniu.

    Remote Control bez frustracji

    Remote Control otrzymał szereg poprawek, które były potrzebne. Najważniejsze: komendy wysyłane do interaktywnej sesji nie zwracają już błędu "Unknown command". Pliki i obrazki wysyłane bez podpisów nie są już odrzucane bez wyjaśnienia, co wcześniej prowadziło do dezorientacji.

    Dodatkowo aplikacje mobilne i webowe wyświetlają teraz poprawny tryb uprawnień na ekranie /remote-control. Wcześniej zdarzało się, że pokazywały nieaktualne informacje, co utrudniało stwierdzenie, czy sesja ma odpowiednie dostępy.

    Sesje, dyktowanie i MCP — mniejsze, ale istotne poprawki

    Wydanie naprawia również błąd z przemianowywaniem sesji — wcześniej zmiana nazwy nie zawsze była poprawnie propagowana, co prowadziło do niespójności. Poprawiono stabilność dyktowania głosowego i niezawodność sesji działających w tle, co jest istotne, gdy Claude Code pracuje jako długo żyjący proces na serwerze.

    MCP (Model Context Protocol) doczekał się czytelniejszych komunikatów błędów — to detal, ale przy integracji zewnętrznych narzędzi potrafi znacznie skrócić czas namierzania problemu. Zamiast generycznych kodów dostajemy teraz sensowny opis, co poszło nie tak.

    Podsumowanie

    Claude Code 2.1.202 nie jest przełomowym wydaniem, ale skutecznie poprawia funkcjonalność poprzednich wersji. Dynamiczne rozmiary workflow dają kontrolę nad skalą zadań agentowych, OpenTelemetry poprawia przejrzystość, a poprawki Remote Control eliminują kilka frustrujących błędów. Dla zespołów korzystających z Claude'a w codziennej pracy to aktualizacja, którą warto wdrożyć od razu — zwłaszcza jeśli polegacie na zdalnym nadzorowaniu sesji.

    Źródła

  • Factory v0.164.0: uporządkowane komendy slash i nowa kontrola synchronizacji z chmurą

    Factory v0.164.0: uporządkowane komendy slash i nowa kontrola synchronizacji z chmurą

    Najnowsza aktualizacja Factory, oznaczona jako v0.164.0, wprowadza uporządkowanie komend slash oraz umożliwia zespołom kontrolę nad synchronizacją sesji z chmurą. To nie jest rewolucja, lecz znaczący krok w kierunku bardziej przewidywalnego środowiska dla deweloperów pracujących z AI. W paczce znalazły się również istotne poprawki stabilności, które powinny zadowolić zespoły zmagające się z autoryzacją MCP oraz logowaniem między organizacjami.

    Kluczowe zmiany w pigułce

    • Komendy slash zostały pogrupowane według kategorii, co kończy erę płaskiej, przytłaczającej listy.
    • Synchronizacja sesji z chmurą może być teraz wyłączona, co jest przydatne w środowiskach z restrykcyjnymi politykami bezpieczeństwa.
    • Selektor modeli przeszedł kosmetyczne odświeżenie i jest teraz bardziej czytelny.
    • Autoryzacja MCP otrzymała poprawkę eliminującą problemy z tokenami OAuth i ich przechowywaniem.
    • Logowanie między organizacjami oraz procesy w tle droid exec działają stabilniej.

    Porządki w komendach — mniej scrollowania, więcej sensu

    Każdy, kto spędził czas z Factory, zna ten moment: otwierasz listę komend slash i widzisz ścianę tekstu bez ładu. v0.164.0 kończy z tym bałaganem. Komendy są teraz pogrupowane w kategorie, co drastycznie skraca czas potrzebny na znalezienie właściwej opcji. Nowy selektor modeli idzie w tym samym kierunku — mniej elementów na ekranie, szybsze decyzje.

    Takie zmiany mogą być łatwe do przeoczenia w changelogu, ale dla kogoś, kto używa Factory codziennie, różnica między płaską listą a sensownie posegregowanymi opcjami to oszczędność kilkunastu sekund za każdym razem. W skali tygodnia daje to realny zysk.

    Cloud Sync — teraz to Ty decydujesz

    Cloud Sync — teraz to Ty decydujesz

    Nowa kontrolka synchronizacji sesji to ciekawsza zmiana. Factory od dawna synchronizuje dane sesji z chmurą, co dla wielu zespołów jest zaletą, ale nie dla wszystkich. W środowiskach enterprise każdy bajt opuszczający firmową sieć podlega audytowi, więc automatyczne synchronizacje mogą być problematyczne.

    Teraz organizacje mogą po prostu wyłączyć Cloud Sync w ustawieniach. Gdy opcja cloudSessionSync jest wyłączona, CLI pomija synchronizację z chmurą. To niewielka zmiana konfiguracyjna, ale dla zespołów w regulowanych branżach ma ogromne znaczenie.

    Factory buduje swoją pozycję jako narzędzie klasy enterprise, a bez granularnej kontroli nad danymi trudno konkurować na poważnym rynku. Ta funkcja pokazuje, że rozumieją potrzeby dużych klientów.

    MCP, autoryzacja i procesy w tle — co naprawiono

    MCP, autoryzacja i procesy w tle — co naprawiono

    Druga część aktualizacji to zestaw poprawek, które mogą nie być atrakcyjne marketingowo, ale są kluczowe dla codziennej pracy. Na pierwszy ogień idzie autoryzacja MCP — OAuth teraz poprawnie przechowuje tokeny globalnie w systemowym keyringu, co oznacza, że serwer skonfigurowany w jednym projekcie uwierzytelnia się wszędzie, gdzie jest używany. Koniec z sytuacjami, w których Droid prosi o ponowną autoryzację przy każdym restarcie.

    Jest też poprawka dla droid exec. To polecenie działa jako bezinteraktywny runner, a jego procesy są teraz stabilniejsze w ramach fabrycznego workflow. Dla zespołów automatyzujących zadania devopsowe to kluczowa sprawa.

    Na koniec — logowanie między organizacjami. Wcześniej przełączanie się między organizacjami mogło kończyć się błędami autoryzacji, szczególnie gdy polityki organizacji różniły się między sobą. v0.164.0 rozwiązuje ten problem, co docenią konsultanci i deweloperzy pracujący dla wielu klientów jednocześnie.

    Co to oznacza dla ekosystemu Factory

    Patrząc szerzej, ten release wpisuje się w trend dojrzewania narzędzi agent-native. Factory nie jest już eksperymentem — to produkcyjne środowisko, które musi działać przewidywalnie w złożonych setupach enterprise. Grupowanie komend i kontrola synchronizacji to nie są funkcje, które sprzedają dema, ale to detale, które decydują o tym, czy zespół zostaje z narzędziem na lata, czy szuka alternatyw po pierwszym audycie bezpieczeństwa.

    Warto również zwrócić uwagę na kontekst MCP — Factory dokumentuje trzy poziomy konfiguracji (user, folder, project) i pozwala organizacjom centralnie zarządzać dostępem do serwerów MCP przez mcpPolicy. To architektura, która skaluje się razem z zespołem i nie wymaga przepisywania polityk bezpieczeństwa przy każdym nowym wdrożeniu.

    Źródła