Aktualizację pulpitu łatwo ocenić, gdy aplikacja jest edytorem notatek: zamykasz okno, instalujesz nową wersję i ponownie otwierasz plik. Oprogramowanie agentowe ma trudniejsze zobowiązania. Uruchomiona sesja może w danej chwili przesyłać dane wyjściowe, posiadać worktree, czekać na zatwierdzenie, rejestrować wywołania narzędzi albo koordynować inną sesję, gdy powłoka pulpitu musi zostać zrestartowana.

Stanowisko programisty, na którym sesja agenta na komputerze trwa podczas aktualizacji oprogramowania.

Dlatego CompozyOS 0.4.4 jest ciekawszy, niż sugerowałby jego krótki changelog. Oficjalny changelog wydań wymienia jedną główną zmianę na 28 października 2026 roku: zachowanie aktywnych sesji podczas aktualizacji pulpitu. Projekt jest lokalnym środowiskiem uruchomieniowym dla trwałych sesji agentów, pętli, automatyzacji, uprawnień i wielu interfejsów sterowania. W tym kontekście sposób aktualizowania nie jest kwestią kosmetyczną. Stanowi część modelu niezawodności środowiska uruchomieniowego.

Praktyczna rada jest prosta: uruchom 0.4.4 w przeznaczonym do testów lub zabezpieczonym kopią zapasową katalogu domowym CompozyOS, a następnie celowo wykonaj aktualizację, gdy sesja będzie aktywna. Nie uznawaj zachowanego okna za dowód, że zachowana została również praca. Osobno sprawdź daemon, transkrypt, stan tury, dane wejściowe oczekujące w kolejce, załączniki, worktree i połączenie z dostawcą.

Co zmieniło się w 0.4.4

Strona wydania opisuje tę zmianę zwięźle, zamiast przedstawiać długi esej o funkcjach: aktywne sesje powinny przetrwać aktualizację pulpitu. Historia wcześniejszych wydań pokazuje, dlaczego jest to istotna granica. CompozyOS 0.4.0 było pierwszym stabilnym wydaniem, 0.4.1 naprawiło kilka problemów związanych z pulpitem i odzyskiwaniem działania środowiska, 0.4.2 zajęło się odczytami użycia Claude’a w tle, które mogły wywoływać monit o dostęp do pęku kluczy, a 0.4.4 skupia się teraz na zachowaniu ciągłości podczas samej aktualizacji pulpitu.

Ta kolejność ma znaczenie, ponieważ CompozyOS składa się z dwóch blisko powiązanych elementów: aplikacji pulpitu i lokalnego daemona. Dokumentacja pulpitu wyjaśnia, że zarówno aplikacja, jak i polecenie compozy korzystają z tego samego lokalnego daemona, konfiguracji, obszarów roboczych i historii sesji. Aplikacja może podłączyć się do już działającego daemona, uruchomić środowisko zainstalowane w katalogu domowym CompozyOS albo w razie potrzeby zainstalować i uruchomić środowisko dołączone do aplikacji. Zamknięcie aplikacji nie powinno zatrzymywać daemona.

Aktualizacja pulpitu może więc oznaczać co najmniej dwie rzeczy:

  • wymianę powłoki graficznej przy pozostawieniu dostępnego daemona i jego stanu;
  • wymianę pakietu zawierającego zarówno aplikację, jak i środowisko uruchomieniowe, a następnie ponowne uruchomienie nowej pary bez utraty trwałego stanu.

Najważniejsze słowo to „aktywne”. Przywrócenie po uruchomieniu listy starych sesji jest znacznie słabszą gwarancją niż zachowanie spójności trwającej tury. Dobra implementacja musi zachować wystarczająco dużo informacji o własności i zdarzeniach, aby sesja mogła być kontynuowana, ponownie połączona albo jasno poinformować o przerwaniu. Sam nagłówek wydania nie mówi, jak zachowa się każdy dostawca, system operacyjny, ścieżka instalatora czy tryb awarii. To właśnie należy przetestować.

Dlaczego ciągłość pulpitu jest problemem środowiska uruchomieniowego

Wiele narzędzi agentowych zaczyna jako proces terminala. Proces posiada monit, standardowe wejście, strumień wyjściowy i często proces potomny uruchamiający klienta modelu. Zamknięcie terminala może zakończyć wszystko. Trwałe środowisko uruchomieniowe zmienia ten układ: daemon przejmuje odpowiedzialność za pracę, a terminal, przeglądarka, powłoka pulpitu lub inny klient obserwuje ją i steruje nią.

Taki projekt zapewnia użyteczne rozdzielenie. Interfejs może zniknąć bez konieczności anulowania pracy. Jednocześnie aktualizacja staje się bardziej wymagająca. Restart klienta jest bezpieczny tylko wtedy, gdy daemon wie, co wydarzyło się przed restartem, i potrafi później odtworzyć albo zrekonstruować stan.

Aktualizacja sesji może przekraczać kilka granic:

  1. Proces pulpitu może się zamknąć albo przekazać sterowanie natywnemu instalatorowi.
  2. Pakietowe środowisko uruchomieniowe może zostać wymienione lub zrestartowane.
  3. Daemon może nadal działać, może otrzymać polecenie zatrzymania albo zostać wykryty po uruchomieniu.
  4. Proces dostawcy może działać dalej, ponownie się połączyć, zakończyć działanie albo odrzucić przywrócone środowisko.
  5. Interfejs musi zdecydować, czy wyświetlić dane na żywo, uzupełniający transkrypt, ostrzeżenie czy rzeczywiście zatrzymaną turę.

Dokumentacja CompozyOS opisuje szerszy model jako sesje zarządzane przez demona, których zdarzenia pozostają możliwe do sprawdzenia, gdy praca trwa w tle. To właściwa abstrakcja na czas aktualizacji, ale nie należy jej mylić z tworzeniem punktów kontrolnych dla każdego zewnętrznego efektu ubocznego. Transkrypt może być trwały, nawet gdy polecenie powłoki nadal się wykonuje. Worktree może pozostać podłączony, mimo że dostawca utracił połączenie. Wiadomość w kolejce może być zapisana, choć agent jeszcze jej nie otrzymał.

Z tego powodu „sesja przetrwała” powinno znaczyć więcej niż „wiersz nadal jest widoczny”. Powinno oznaczać, że środowisko wykonawcze potrafi wskazać, która część przetrwała, a która wymaga uwagi człowieka.

Pierwszy test: aktualizacja podczas bezczynnej sesji

Zacznij od najmniej destrukcyjnego przypadku. Utwórz testowy obszar roboczy, uruchom sesję, wyślij polecenie generujące trwałą odpowiedź i pozostaw sesję bezczynnie. Zapisz identyfikator sesji, obszar roboczy, wybrany profil oraz lokalizację katalogu domowego CompozyOS. Następnie wykonaj aktualizację aplikacji desktopowej zgodnie z opisaną ścieżką aktualizacji.

Przewodnik desktopowy udostępnia trzy przydatne polecenia:

compozy update --check -o json
compozy update -o json
compozy update --cancel -o json

Dokumentacja informuje, że akcja z paska menu lub Ustawień może pobrać, zainstalować i ponownie uruchomić aplikację. Wyjaśnia też, że aplikacja pozostaje otwarta, gdy jej natywny instalator przygotowuje zweryfikowany pakiet, natomiast zamknięta aplikacja może odłożyć aktualizację do następnego uruchomienia. W systemie Linux automatyczna instalacja kanału aplikacji jest ograniczona do ścieżki AppImage.

Po aktualizacji sprawdź wszystkie poniższe elementy, zamiast polegać na pierwszym ekranie:

  • aplikacja zgłasza oczekiwaną wersję;
  • używany jest ten sam katalog domowy CompozyOS;
  • identyfikatory obszaru roboczego i sesji się nie zmieniły;
  • poprzedni transkrypt jest kompletny i zachowuje właściwą kolejność;
  • wybrany agent i profil nadal są powiązane z sesją;
  • podczas ponownego łączenia nie pojawiła się zduplikowana tura;
  • demon działa poprawnie, a aplikacja jest do niego podłączona;
  • sesja przyjmuje nowe polecenie.

Ten test pokazuje, czy zwykły utrwalony stan przetrwa. Nie odpowiada jeszcze na pytanie, czy produkt poradzi sobie z aktualizacją w trakcie wykonywania pracy.

Drugi test: aktualizacja podczas wykonywania tury

Bardziej wartościowy test wykorzystuje polecenie, które pozostaje aktywne wystarczająco długo, by można było je obserwować. Lepsze od sztucznego uśpienia będzie długotrwałe polecenie lokalne, ograniczony zestaw testów albo kontrolowane zadanie generujące kilka zdarzeń narzędziowych. Użyj repozytorium utworzonego na potrzeby testu i usuń z jego środowiska poufne dane uwierzytelniające.

Rozpocznij turę, poczekaj na wyraźne zdarzenie narzędzia lub postępu i uruchom aktualizację z powłoki aplikacji desktopowej. Nie wysyłaj kolejnych poleceń, dopóki nie będzie jasne, co się stało. W zależności od implementacji dopuszczalnych jest kilka rezultatów:

  • demon i dostawca kontynuują pracę, a aplikacja desktopowa ponownie łączy się z tą samą aktywną turą;
  • tura kończy się podczas ponownego uruchamiania aplikacji desktopowej, po czym pojawia się z kompletnym transkryptem;
  • środowisko wykonawcze wstrzymuje lub anuluje turę, dokładnie zapisuje ten fakt i umożliwia odzyskanie pracy;
  • instalator odmawia kontynuacji, dopóki aktywna praca nie zostanie jawnie obsłużona.

Niebezpieczny jest rezultat, w którym sesja wygląda wiarygodnie, ale po cichu gubi wynik narzędzia, powtarza efekt uboczny albo wyświetla końcową odpowiedź bez historii zdarzeń, które do niej doprowadziły. Trwałe środowisko uruchamiania agentów potrzebuje mocniejszych dowodów niż pomyślne ponowne uruchomienie okna.

Użyj zadania, którego efekt uboczny można sprawdzić dwukrotnie. Na przykład zleć agentowi testowemu zapisanie jednoznacznie nazwanej zawartości pliku zawierającej wartość nonce, a następnie poproś go o podanie tej zawartości. Po aktualizacji porównaj plik, transkrypt, wynik narzędzia i końcową odpowiedź. Jeśli działanie wykonało się dwa razy, test powinien to ujawnić. Do tego eksperymentu nigdy nie używaj wdrożenia produkcyjnego, destrukcyjnej migracji, operacji płatniczej ani rzeczywistej rotacji danych uwierzytelniających.

Trzeci test: dane wejściowe i załączniki w kolejce

Aktywna sesja to nie tylko tura modelu. Operator może wpisać dodatkowe polecenie, gdy agent jest zajęty, umieścić wiadomość w kolejce, sterować turą albo dołączyć pliki. Właśnie te dane wejściowe mogą podczas ponownego łączenia ujawnić stan rozdzielony między dwie gałęzie.

Utwórz mały załącznik testowy i wyślij polecenie, które utrzyma sesję w stanie zajętości. Przygotuj wiadomość uzupełniającą, ale nie klikaj przycisku wysyłania, dopóki zamierzone zachowanie kolejki nie będzie jasne. Podczas aktualizacji obserwuj, czy wersja robocza nadal pozostaje wersją roboczą, czy wiadomość w kolejce nadal jest w kolejce oraz czy akcja sterująca zostaje dostarczona dokładnie raz, a nie dwukrotnie.

Publiczna historia wydań projektu wielokrotnie wspominała o ciągłości transkrypcji, danych wejściowych oczekujących w kolejce, komunikatach sesji, załącznikach oraz odzyskiwaniu działania po rozłączeniu z dostawcą. Te wpisy pokazują, że opiekunowie projektu traktują stan sesji jako coś więcej niż zapis rozmowy. Pokazują też, dlaczego warto testować aktualne wydanie, zamiast wyciągać wnioski na podstawie jednego nagłówka.

Przydatna lista kontrolna obejmuje:

  • niewysłany tekst pozostaje niewysłany;
  • dane wejściowe w kolejce mają jeden status dostarczenia;
  • załącznik ma jedną zarejestrowaną tożsamość i nadal można go odczytać;
  • komunikat sterujący nie zamienia się w zduplikowany zwykły prompt;
  • błąd dostawcy jest widoczny, a nie zastępowany ogólnym wskaźnikiem ponownego łączenia;
  • profil sesji i granice obszaru roboczego pozostają nienaruszone.

Jeśli aktualizacja zmienia pozycję sesji w kolejce, należy odnotować to jako zachowanie produktu. Może być akceptowalne, ale powinno być możliwe do zaobserwowania i opisane w dokumentacji.

Czego nie dowodzi wersja 0.4.4

Stabilna aktualizacja pulpitu nie jest tym samym co bezpieczna granica wykonywania. Repozytorium opisuje CompozyOS jako projekt lokalny przede wszystkim, w którym binarka Go i magazyny danych oparte na SQLite przechowują stan środowiska na komputerze operatora, chyba że część tej granicy należy do zewnętrznego dostawcy lub rozszerzenia. Daje to kontrolę i ułatwia inspekcję, ale oznacza również, że komputer, konto użytkownika, dane uwierzytelniające dostawcy, pliki obszaru roboczego i zainstalowane rozszerzenia nadal należą do modelu zaufania.

Repozytorium jest oznaczone jako objęte licencją MIT, a README informuje, że mile widziane są kontrybucje. Otwartość licencji odpowiada na pytanie, czy można sprawdzać, modyfikować i redystrybuować kod zgodnie z jej warunkami. Nie gwarantuje jednak, że każde wydanie jest dojrzałe, każda integracja ma takie same właściwości bezpieczeństwa ani że aktualizacja nie ujawni problemu z migracją.

Szczególnie istotne są materiały migracyjne projektu. Przewodnik migracji opisuje wcześniejszą korektę, w ramach której metadane dystrybucji błędnie oznaczały artefakty jako BSL-1.1, mimo że projekt nadal był objęty licencją MIT. Dokumentuje też granice zgodności między starszymi i nowszymi liniami produktu. To przypomnienie, by podczas przechodzenia między głównymi wersjami produktu czytać informacje o migracji, zamiast zakładać, że aktualizacja w miejscu zawsze da się odwrócić.

Przewodnik operacji pulpitu zawiera kolejne ostrzeżenie: po podmianie binarki środowiska nieudany restart lub test kondycji może pozostawić nową wersję, która zdążyła już zmigrować bazy danych. Udokumentowana rada mówi, by zachować kopię zapasową na potrzeby diagnozy, nie przywracać starszej binarki na potencjalnie zmigrowany katalog domowy oraz — jeśli to konieczne — zainstalować docelowe wydanie lub nowszą zgodną wersję w tym samym katalogu domowym. Właśnie takie szczegóły mają większe znaczenie niż dopracowana animacja aktualizacji.

Kto powinien wypróbować je teraz

CompozyOS 0.4.4 warto przetestować, jeśli jesteś deweloperem, który już potrzebuje, by praca agenta trwała dłużej niż sesja terminala, i możesz udostępnić osobny katalog domowy do testów. Wydanie ma też znaczenie dla opiekunów tworzących automatyzację wokół lokalnych sesji agentów, ponieważ ścieżka aktualizacji jest częścią historii dostępności automatyzacji. Jeśli aplikacja służy jako pulpit dla długo działającego demona, wydanie bezpośrednio celuje w przerwę, której użytkownicy w przeciwnym razie zaczynają się obawiać.

To mniej oczywisty wybór dla zespołów szukających w pełni zarządzanej płaszczyzny sterowania, ścisłej izolacji agentów od hosta albo dojrzałego procesu zarządzania zmianami w przedsiębiorstwie. Wartością projektu jest lokalny model środowiska uruchomieniowego: sesje, zadania, pętle, uprawnienia, zatwierdzenia i automatyzacja współdzielą model stanu zarządzany przez demona. Może to usunąć sporą ilość kodu łączącego, ale jednocześnie skupia odpowiedzialność w lokalnej instalacji i jej konfiguracji.

Rozsądny test ma trzy cechy:

  • środowisko robocze przeznaczone do usunięcia albo zweryfikowana kopia zapasowa;
  • brak produkcyjnych danych uwierzytelniających w testowym środowisku dostawcy;
  • wystarczająca obserwowalność, by porównać transkrypcję, system plików, stan procesów i logi aktualizacji.

Zachowaj poprzednie wydanie do porównania, ale nie obniżaj wersji w zmigrowanym katalogu domowym bez namysłu. Przed testem ścieżki, która zmienia stan środowiska uruchomieniowego lub bazy danych, wykonaj pełną kopię zapasową.

Krótkie porównanie z innymi podejściami

Jeśli wymaganie sprowadza się do „utrzymania działającego polecenia po zamknięciu terminala”, łatwiejsze do zrozumienia mogą być multiplekser terminala, usługa systemowa albo zwykła kolejka zadań. Narzędzia te nie oferują zorientowanego na agentów modelu sesji CompozyOS, ale ich działanie operacyjne jest znane i często na tyle wąskie, że można je łatwo poddać audytowi.

Jeśli potrzebny jest interfejs przeglądarkowy do zdalnego programowania, hostowana lub samodzielnie zarządzana platforma deweloperska może zapewnić lepszą integrację z tożsamością, przestrzeniami roboczymi i audytem. Może też narzucać zależność od chmury oraz inną granicę zaufania. CompozyOS stawia natomiast na lokalnego demona z wyraźnie określonymi powierzchniami bramy, więc kompromis polega na wyborze między kontrolą nad maszyną a pracą operacyjną związaną z jej utrzymaniem.

Jeśli wymaganiem jest niezależny od modelu runner agentów, biblioteka orkiestracyjna może udostępniać prymitywy niższego poziomu, pozostawiając aplikacji trwałość, zatwierdzenia i politykę aktualizacji. To może być właściwy wybór, gdy zespół ma już niezawodną warstwę platformową. CompozyOS jest przeznaczony do przeciwnego problemu: warstwa platformowa jest właśnie tym, czego zespół nie chce odtwarzać dla każdego CLI agenta.

Porównanie powinno więc koncentrować się na obsłudze awarii, a nie na liczbie funkcji. Warto sprawdzić, jak każde rozwiązanie zachowuje się po ponownym uruchomieniu interfejsu, rozłączeniu dostawcy, restarcie hosta, pojawieniu się wiadomości w kolejce, wykonaniu migracji bazy danych albo zakończeniu procesu potomnego w połowie wywołania narzędzia.

Werdykt, który ma znaczenie

CompozyOS 0.4.4 to niewielkie wydanie z dużym, choć niewypowiedzianym testem. Zachowanie aktywnych sesji podczas aktualizacji pulpitu jest dokładnie takim rodzajem funkcji niezawodności, który użytkownicy zauważają dopiero wtedy, gdy zawiedzie. Funkcja ma wartość, ponieważ CompozyOS przedstawia się jako trwałe lokalne środowisko uruchomieniowe, a nie cienka nakładka okna na jednorazowy prompt.

Wydanie nadaje się do wypróbowania, ale nie jest powodem, by powierzać świeżo zaktualizowanemu systemowi agentowemu niepilnowaną pracę produkcyjną. Zacznij od odizolowanego środowiska domowego. Przetestuj bezczynne sesje, aktywne tury, dane wejściowe oczekujące w kolejce, załączniki, worktree, ponowne połączenia z dostawcami oraz odzyskiwanie po przerwanej aktualizacji. Zachowaj transkrypcję i dowody w systemie plików, a następnie sprawdź, co faktycznie zrobił demon.

Jeśli testy zakończą się powodzeniem, wersja 0.4.4 ograniczy rolę powłoki pulpitu jako pojedynczego punktu przerwania. Jeśli nie, awaria również okaże się użyteczna: pokaże, czy brakującym elementem jest koordynacja instalatora, własność demona, odzyskiwanie po awarii dostawcy, migracja bazy danych czy po prostu mylący stan interfejsu. To rozróżnienie jest prawdziwą miarą otwartego środowiska uruchomieniowego dla agentów.