{"schema_version":"1.0","service":"Publicasta","type":"article","id":994,"slug":"compozyos_044_desktop_updates_session_continuity_test","title":"CompozyOS 0.4.4 macht Desktop-Updates zum Test für langlebige Agentensitzungen","excerpt":"CompozyOS 0.4.4 soll aktive Sitzungen während Desktop-Updates erhalten. Das wirft eine zentrale Frage für lokale Agentenlaufzeiten auf: Kann die Oberfläche ersetzt werden, ohne Arbeit zu unterbrechen, Zustände zu beschädigen oder Ereignisse zu verschleiern?","language":"de","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=de","image":{"url":"https://publicasta.com/storage/projects/10/pages/994/2026/10/3545d05d-8eb1-4b5e-a527-2f6888d08fd3.webp","alt":"Arbeitsplatz eines Entwicklers, an dem eine Desktop-Agentensitzung während eines Softwareupdates fortgesetzt wird."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-28T13:38:38+00:00","updated_at":"2026-10-28T13:38:38+00:00","content_markdown":"Ein Desktop-Update lässt sich bei einer Notizen-App leicht beurteilen: Fenster schließen, neuen Build installieren und die Datei wieder öffnen. Agentensoftware hat einen anspruchsvolleren Vertrag. Eine laufende Sitzung kann gerade Ausgaben streamen, ein Worktree halten, auf eine Genehmigung warten, Tool-Aufrufe protokollieren oder eine andere Sitzung koordinieren, wenn die Desktop-Shell neu gestartet werden muss.\n\n ![Arbeitsplatz eines Entwicklers, an dem eine Desktop-Agentensitzung während eines Softwareupdates fortgesetzt wird.](https://publicasta.com/storage/projects/10/pages/994/2026/10/3545d05d-8eb1-4b5e-a527-2f6888d08fd3.webp)\n\n Deshalb ist CompozyOS 0.4.4 interessanter, als sein kurzer Changelog vermuten lässt. Der [offizielle Release-Changelog](https://www.compozy.com/changelog/) nennt für den 28. Oktober 2026 eine zentrale Änderung: Aktive Sitzungen sollen Desktop-Updates überstehen. Das Projekt ist eine Local-first-Laufzeit für langlebige Agentensitzungen, Schleifen, Automatisierung, Berechtigungen und mehrere Steuerungsoberflächen. In diesem Kontext ist das Update-Verhalten keine kosmetische Frage. Es gehört zum Zuverlässigkeitsmodell der Laufzeit.\n\n Der praktische Rat ist unkompliziert: Probiere 0.4.4 in einem entbehrlichen oder gesicherten CompozyOS-Home aus und führe dann bewusst ein Update durch, während eine Sitzung aktiv ist. Ein erhaltenes Fenster ist kein Beweis dafür, dass auch die Arbeit erhalten blieb. Prüfe Daemon, Transkript, Turn-Zustand, Warteschlangeneingaben, Anhänge, Worktree und Provider-Verbindung jeweils separat.\n\n ## Was sich in 0.4.4 geändert hat\n\n Die Release-Seite beschreibt die Änderung derzeit knapp statt in einem ausführlichen Feature-Text: Aktive Sitzungen sollen ein Desktop-Update überstehen. Die umgebende Release-Historie erklärt, warum diese Grenze relevant ist. CompozyOS 0.4.0 war die erste stabile Veröffentlichung, 0.4.1 behob mehrere Fälle rund um Desktop und Laufzeit-Wiederherstellung, 0.4.2 korrigierte Hintergrundabfragen zur Claude-Nutzung, die den Schlüsselbund aufrufen konnten, und 0.4.4 zielt nun auf Kontinuität während des Desktop-Updates selbst.\n\n Diese Abfolge ist wichtig, weil CompozyOS aus zwei eng verbundenen Komponenten besteht: einer Desktop-Anwendung und einem lokalen Daemon. Die [Desktop-Dokumentation](https://www.compozy.com/docs/getting-started/desktop-app/) erklärt, dass sowohl die Desktop-App als auch der Befehl `compozy` denselben lokalen Daemon, dieselbe Konfiguration, dieselben Workspaces und dieselbe Sitzungshistorie verwenden. Die App kann sich an einen bereits funktionierenden Daemon anhängen, die im CompozyOS-Home installierte Laufzeit starten oder bei Bedarf die mitgelieferte Laufzeit installieren und starten. Das Beenden der App soll den Daemon nicht stoppen.\n\n Ein Desktop-Update kann daher mindestens zweierlei bedeuten:\n\n - die grafische Shell ersetzen, während Daemon und Zustand weiterhin verfügbar bleiben;\n- ein Paket ersetzen, das App und Laufzeit gemeinsam enthält, und anschließend das neue Paar starten, ohne dauerhaften Zustand zu verlieren.\n\n Das entscheidende Wort ist „aktiv“. Nach dem Start eine Liste alter Sitzungen wiederherzustellen, ist eine deutlich schwächere Zusage, als einen laufenden Turn konsistent zu halten. Eine brauchbare Implementierung muss genügend Besitz- und Ereigniszustand bewahren, damit eine Sitzung fortgesetzt, die Verbindung wiederhergestellt oder eine klare Unterbrechung gemeldet werden kann. Die Überschrift des Releases sagt für sich genommen nicht, wie sich jeder Provider, jedes Betriebssystem, jeder Installationsweg oder jeder Fehlerfall verhält. Genau das sollten Nutzer testen.\n\n ## Warum Desktop-Kontinuität ein Laufzeitproblem ist\n\n Viele Agententools beginnen als Terminalprozess. Der Prozess besitzt die Eingabeaufforderung, die Standardeingabe, den Ausgabestrom und oft auch den untergeordneten Prozess, der den Modell-Client ausführt. Wird das Terminal geschlossen, kann alles beendet werden. Eine langlebige Laufzeit verändert diese Anordnung: Der Daemon übernimmt die Arbeit, während Terminal, Browser, Desktop-Shell oder ein anderer Client sie beobachtet und steuert.\n\n Diese Architektur schafft eine nützliche Trennung. Die Oberfläche kann verschwinden, ohne dass die Arbeit zwangsläufig abgebrochen wird. Sie führt aber auch zu einem anspruchsvolleren Upgrade-Pfad. Ein Neustart des Clients ist nur dann sicher, wenn der Daemon weiß, was vor dem Neustart passiert ist, und den Zustand danach wiedergeben oder rekonstruieren kann.\n\n Ein Sitzungs-Update kann mehrere Grenzen überschreiten:\n\n 1. Der Desktop-Prozess kann sich schließen oder die Kontrolle an ein natives Installationsprogramm übergeben.\n2. Die paketierte Laufzeit kann ersetzt oder neu gestartet werden.\n3. Der Daemon kann weiterlaufen, zum Beenden aufgefordert werden oder nach dem Start entdeckt werden.\n4. Der Provider-Prozess kann fortfahren, die Verbindung wiederherstellen, fehlschlagen oder die wiederhergestellte Umgebung ablehnen.\n5. Die Benutzeroberfläche muss entscheiden, ob sie Live-Ausgaben, ein nachgeholtes Transkript, eine Warnung oder einen tatsächlich gestoppten Turn anzeigen soll.\n\n Die [CompozyOS-Dokumentation](https://www.compozy.com/docs/) beschreibt das übergeordnete Modell als Sitzungen, die dem Daemon gehören und deren Ereignisse einsehbar bleiben, während die Arbeit im Hintergrund weiterläuft. Das ist die richtige Abstraktion für ein Update, sollte aber nicht mit dem Speichern jedes externen Seiteneffekts verwechselt werden. Ein Transkript kann dauerhaft erhalten bleiben, während ein Shell-Befehl noch läuft. Ein Worktree kann verbunden bleiben, obwohl ein Provider seine Verbindung verloren hat. Eine eingereihte Nachricht kann gespeichert sein, ohne dass der Agent sie bereits empfangen hat.\n\n Deshalb sollte „die Sitzung hat überlebt“ mehr bedeuten als „der Eintrag ist noch sichtbar“. Es sollte bedeuten, dass die Laufzeitumgebung sagen kann, welcher Teil erhalten blieb und wo menschliche Aufmerksamkeit erforderlich ist.\n\n ## Der erste Test: Update während einer inaktiven Sitzung\n\n Beginne mit dem am wenigsten riskanten Fall. Erstelle einen Test-Workspace, starte eine Sitzung, sende einen Prompt, der eine dauerhaft gespeicherte Antwort erzeugt, und lasse die Sitzung anschließend untätig. Notiere die Sitzungs-ID, den Workspace, das ausgewählte Profil und den Speicherort des CompozyOS-Home-Verzeichnisses. Führe dann das Desktop-Update über den dokumentierten Aktualisierungspfad aus.\n\n Die Desktop-Anleitung stellt drei nützliche Befehle bereit:\n\n ```text\ncompozy update --check -o json\ncompozy update -o json\ncompozy update --cancel -o json\n```\n\n Laut Dokumentation kann die Aktion über die Menüleiste oder die Einstellungen die Anwendung herunterladen, installieren und neu starten. Außerdem bleibt die App geöffnet, während ihr nativer Installer das verifizierte Paket vorbereitet; bei geschlossener App kann das Update für den nächsten Start vorgemerkt werden. Unter Linux ist die automatische Installation eines App-Tracks auf den AppImage-Pfad beschränkt.\n\n Prüfe nach dem Update alle folgenden Punkte, statt dich auf den ersten Bildschirm zu verlassen:\n\n - Die Anwendung meldet die erwartete Version.\n- Dasselbe CompozyOS-Home-Verzeichnis wird verwendet.\n- Workspace- und Sitzungs-IDs sind unverändert.\n- Das vorherige Transkript ist vollständig und in der richtigen Reihenfolge.\n- Der ausgewählte Agent und das Profil sind weiterhin der Sitzung zugeordnet.\n- Beim Wiederverbinden ist kein doppelter Turn aufgetaucht.\n- Der Daemon ist gesund, und die App ist mit ihm verbunden.\n- Die Sitzung kann einen neuen Prompt annehmen.\n\n Dieser Test beantwortet die Frage, ob gewöhnliche persistierte Zustände erhalten bleiben. Er zeigt noch nicht, ob das Produkt ein Update während laufender Arbeit bewältigen kann.\n\n ## Der zweite Test: Update während eines laufenden Turns\n\n Der aussagekräftigere Test verwendet einen Prompt, der lange genug aktiv bleibt, um ihn beobachten zu können. Ein länger laufender lokaler Befehl, eine begrenzte Testsuite oder eine kontrollierte Aufgabe mit mehreren Tool-Ereignissen eignet sich besser als ein künstliches Warten. Verwende ein eigens für den Test erstelltes Repository und entferne vertrauliche Zugangsdaten aus seiner Umgebung.\n\n Starte den Turn, warte auf ein eindeutiges Tool- oder Fortschrittsereignis und beginne das Update über die Desktop-Shell. Sende keine weiteren Prompts, bevor das Ergebnis verstanden ist. Je nach Implementierung sind mehrere Ausgänge akzeptabel:\n\n - Daemon und Provider laufen weiter, und der Desktop verbindet sich wieder mit demselben laufenden Turn.\n- Der Turn wird während des Neustarts des Desktops abgeschlossen und erscheint anschließend mit einem vollständigen Transkript.\n- Die Laufzeitumgebung pausiert oder bricht den Turn ab, zeichnet diese Tatsache aber präzise auf und ermöglicht eine Wiederherstellung.\n- Der Installer verweigert die Fortsetzung, bis die aktive Arbeit ausdrücklich behandelt wurde.\n\n Gefährlich ist ein plausibel aussehender Zustand, in dem stillschweigend ein Tool-Ergebnis verloren geht, ein Seiteneffekt wiederholt wird oder eine abschließende Antwort ohne die zugehörige Ereignishistorie angezeigt wird. Eine dauerhafte Agenten-Laufzeitumgebung braucht stärkere Belege als einen erfolgreichen Neustart des Fensters.\n\n Verwende eine Aufgabe, deren Seiteneffekt sich zweimal überprüfen lässt. Lass den Testagenten beispielsweise eine Datei mit einem eindeutig benannten Pfad und einer Nonce schreiben und anschließend deren Inhalt melden. Vergleiche nach dem Update die Datei, das Transkript, das Tool-Ergebnis und die abschließende Antwort. Falls die Aktion zweimal ausgeführt wurde, sollte der Test das sichtbar machen. Verwende für dieses Experiment niemals ein Produktions-Deployment, eine destruktive Migration, eine Zahlungsaktion oder eine echte Rotation von Zugangsdaten.\n\n ## Der dritte Test: Eingaben und Anhänge in der Warteschlange\n\n Eine aktive Sitzung besteht nicht nur aus einem Model-Turn. Bediener können eine Folgefrage eingeben, während der Agent beschäftigt ist, eine Nachricht einreihen, einen Turn steuern oder Dateien anhängen. Gerade diese Eingaben können beim Wiederverbinden einen Split-Brain-Zustand sichtbar machen.\n\n Erstelle einen kleinen Testanhang und sende einen Prompt, der die Sitzung beschäftigt hält. Bereite eine Folgefrage vor, klicke aber erst dann auf „Senden“, wenn das vorgesehene Verhalten der Warteschlange klar ist. Beobachte während des Updates, ob der Entwurf ein Entwurf bleibt, ob eine eingereihte Nachricht eingereiht bleibt und ob eine Steuerungsaktion genau einmal statt zweimal zugestellt wird.\n\n In der öffentlichen Versionshistorie des Projekts wurden wiederholt die Kontinuität von Transkripten, Eingaben in der Warteschlange, Sitzungsnachrichten, Anhänge und die Wiederherstellung nach Verbindungsabbrüchen bei Providern erwähnt. Diese Einträge zeigen, dass die Maintainer den Sitzungszustand als mehr betrachten als ein Chatprotokoll. Sie zeigen auch, warum Leser eine aktuelle Version testen sollten, statt das gesamte Verhalten aus einer einzelnen Schlagzeile abzuleiten.\n\n Eine hilfreiche Checkliste:\n\n - Nicht gesendeter Text bleibt nicht gesendet;\n- Eingaben in der Warteschlange haben genau einen Zustellstatus;\n- ein Anhang besitzt genau eine aufgezeichnete Identität und bleibt lesbar;\n- eine Steuerungsnachricht wird nicht zu einer doppelten gewöhnlichen Eingabe;\n- ein Provider-Fehler bleibt sichtbar, statt durch einen allgemeinen Wiederverbindungs-Spinner ersetzt zu werden;\n- das Profil und die Workspace-Grenzen der Sitzung bleiben intakt.\n\n Wenn das Update die Position der Sitzung in der Warteschlange verändert, sollte dieses Verhalten als Produktverhalten dokumentiert werden. Es mag akzeptabel sein, muss aber beobachtbar und nachvollziehbar bleiben.\n\n ## Was 0.4.4 nicht beweist\n\n Ein stabiles Desktop-Update ist nicht dasselbe wie eine sichere Ausführungsgrenze. Das Repository beschreibt CompozyOS als local-first. Eine Go-Binärdatei und SQLite-basierte Speicher halten den Laufzeitstatus auf dem Rechner des Betreibers, sofern nicht ein externer Provider oder eine Erweiterung einen Teil dieser Grenze übernimmt. Das erleichtert Kontrolle und Überprüfung, bedeutet aber auch, dass Rechner, Benutzerkonto, Zugangsdaten der Provider, Workspace-Dateien und installierte Erweiterungen weiterhin zum Vertrauensmodell gehören.\n\n Das Repository ist [MIT-lizenziert](https://github.com/compozy/compozy), und laut README sind Beiträge willkommen. Eine offene Lizenz beantwortet die Frage, ob der Code gemäß den Lizenzbedingungen geprüft, verändert und weiterverbreitet werden darf. Sie garantiert weder, dass jede Version ausgereift ist, noch dass jede Integration dieselben Sicherheitseigenschaften besitzt oder ein Update kein Migrationsproblem verursachen kann.\n\n Besonders relevant ist das eigene Migrationsmaterial des Projekts. Der [Migrationsleitfaden](https://github.com/compozy/compozy/blob/main/MIGRATION_GUIDE.md) beschreibt eine frühere Korrektur, bei der Distributionsmetadaten Artefakte fälschlich als BSL-1.1 kennzeichneten, obwohl das Projekt weiterhin MIT-lizenziert war. Außerdem dokumentiert er Kompatibilitätsgrenzen zwischen älteren und neueren Produktlinien. Das ist eine Erinnerung daran, beim Wechsel über größere Produktgrenzen hinweg die Migrationshinweise zu lesen, statt davon auszugehen, dass ein In-Place-Update immer umkehrbar ist.\n\n Der Leitfaden für Desktop-Betrieb enthält eine weitere wichtige Warnung: Nach dem Austausch einer Laufzeit-Binärdatei können ein fehlgeschlagener Neustart oder ein nicht bestandener Health-Check eine Ersatzinstallation hinterlassen, die Datenbanken bereits migriert hat. Die dokumentierte Empfehlung lautet, das Backup zur Diagnose aufzubewahren, eine ältere Binärdatei nicht über ein möglicherweise bereits migriertes Home zurückzuspielen und bei Bedarf die Zielversion oder eine neuere kompatible Version in dasselbe Home zu installieren. Solche Details sind wichtiger als eine ausgefeilte Update-Animation.\n\n ## Wer es jetzt ausprobieren sollte\n\n CompozyOS 0.4.4 ist für Entwickler einen Test wert, die bereits Agentenarbeit benötigen, die ein Terminal überdauert, und die ein separates Test-Home bereitstellen können. Relevant ist die Version auch für Maintainer, die Automatisierung rund um lokale Agentensitzungen entwickeln, denn der Updatepfad gehört zur Verfügbarkeitsgeschichte dieser Automatisierung. Wird die Anwendung als Desktop-Oberfläche für einen langlebigen Daemon eingesetzt, zielt die Version direkt auf eine Unterbrechung, vor der Nutzer andernfalls mit der Zeit Respekt bekommen.\n\n Weniger naheliegend ist sie für Teams, die eine vollständig verwaltete Steuerungsebene, eine strikte Isolation zwischen Agenten und Host oder einen ausgereiften Change-Management-Prozess für Unternehmen suchen. Der Wert des Projekts liegt in seinem lokalen Laufzeitmodell: Sitzungen, Aufgaben, Schleifen, Berechtigungen, Freigaben und Automatisierung teilen sich ein vom Daemon verwaltetes Zustandsmodell. Das kann viel Klebecode überflüssig machen, konzentriert aber zugleich Verantwortung in der lokalen Installation und ihrer Konfiguration.\n\n Ein sinnvoller Test hat drei Eigenschaften:\n\n - einen wegwerfbaren Workspace oder ein verifiziertes Backup;\n- keine Produktionszugangsdaten in der Testumgebung des Providers;\n- genügend Beobachtbarkeit, um Transkript, Dateisystem, Prozessstatus und Update-Logs miteinander zu vergleichen.\n\n Die vorherige Version sollte zum Vergleich verfügbar bleiben. Ein migriertes Home sollte jedoch nicht beiläufig zurückgestuft werden. Erstelle ein vollständiges Backup, bevor du einen Pfad testest, der den Laufzeit- oder Datenbankzustand verändert.\n\n ## Ein kleiner Vergleich mit anderen Ansätzen\n\n Wenn es lediglich darum geht, „einen Befehl nach dem Schließen des Terminals weiterlaufen zu lassen“, ist ein Terminal-Multiplexer, ein Systemdienst oder eine gewöhnliche Job-Warteschlange möglicherweise leichter zu verstehen. Diese Werkzeuge bieten zwar nicht das agentenorientierte Sitzungsmodell von CompozyOS, aber ihr Betriebsverhalten ist vertraut und oft eng genug gefasst, um es zu prüfen.\n\n Geht es um eine Browseroberfläche für die entfernte Entwicklung, kann eine gehostete oder selbst verwaltete Entwicklungsplattform bessere Integrationen für Identität, Arbeitsbereiche und Audits bieten. Sie kann allerdings auch eine Cloud-Abhängigkeit und eine andere Vertrauensgrenze mit sich bringen. CompozyOS setzt stattdessen auf einen lokalen Daemon mit klar definierten Gateway-Schnittstellen. Der Kompromiss lautet daher: Kontrolle über die eigene Maschine gegen den betrieblichen Aufwand, diese Maschine zu warten.\n\n Wenn ein modellunabhängiger Agent-Runner gefragt ist, kann eine Orchestrierungsbibliothek elementarere Bausteine bereitstellen und Persistenz, Freigaben sowie die Update-Strategie der Anwendung überlassen. Das kann die richtige Wahl sein, wenn ein Team bereits über eine zuverlässige Plattformschicht verfügt. CompozyOS zielt auf das umgekehrte Problem: Die Plattformschicht ist genau das, was ein Team nicht für jede Agent-CLI neu bauen möchte.\n\n Der Vergleich sollte sich deshalb auf die Fehlerbehandlung konzentrieren, nicht auf die Anzahl der Funktionen. Entscheidend ist, wie sich die jeweilige Lösung verhält, wenn die Oberfläche neu startet, die Verbindung zum Anbieter abbricht, der Host neu bootet, eine Nachricht in der Warteschlange liegt, eine Datenbankmigration gelaufen ist oder ein Kindprozess mitten in einem Tool-Aufruf beendet wird.\n\n ## Das entscheidende Fazit\n\n CompozyOS 0.4.4 ist ein kleines Release mit einem großen Test, der darin mitschwingt. Aktive Sitzungen über ein Desktop-Update hinweg zu erhalten, gehört genau zu den Zuverlässigkeitsfunktionen, die Nutzer erst bemerken, wenn sie versagen. Wertvoll ist die Funktion, weil CompozyOS sich als dauerhafter lokaler Runtime versteht und nicht als dünne Oberfläche für einen einmaligen Prompt.\n\n Das Release kann man ausprobieren, ist aber kein Grund, frisch aktualisierten Agentensystemen unbeaufsichtigte Produktionsarbeit anzuvertrauen. Beginne mit einem isolierten Home-Verzeichnis. Teste ruhende Sitzungen, laufende Interaktionen, Eingaben in der Warteschlange, Anhänge, Worktrees, die Wiederverbindung zu Anbietern und die Wiederherstellung nach einem unterbrochenen Update. Bewahre Transkript und Dateisystemnachweise auf und prüfe, was der Daemon tatsächlich getan hat.\n\n Bestehen diese Tests, macht 0.4.4 die Desktop-Shell weniger zu einem einzigen Unterbrechungspunkt. Scheitern sie, ist auch dieses Ergebnis nützlich: Es zeigt, ob die fehlende Komponente in der Koordination des Installers, der Zuständigkeit des Daemons, der Wiederherstellung beim Anbieter, der Datenbankmigration oder schlicht in einem irreführenden UI-Zustand liegt. Diese Unterscheidung ist das eigentliche Maß für eine Open-Source-Agent-Runtime.","available_translations":[{"language":"ar","title":"CompozyOS 0.4.4 يجعل تحديثات سطح المكتب اختبارًا لجلسات الوكلاء المستمرة","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=ar"},{"language":"de","title":"CompozyOS 0.4.4 macht Desktop-Updates zum Test für langlebige Agentensitzungen","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=de","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=de","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=de"},{"language":"en","title":"CompozyOS 0.4.4 makes desktop updates a test of durable agent sessions","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=en","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=en","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=en"},{"language":"es","title":"CompozyOS 0.4.4 convierte las actualizaciones de escritorio en una prueba para las sesiones persistentes de agentes","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=es","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=es","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=es"},{"language":"fr","title":"CompozyOS 0.4.4 fait des mises à jour du bureau un test de la durabilité des sessions d’agents","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=fr"},{"language":"pl","title":"CompozyOS 0.4.4 sprawia, że aktualizacje pulpitu stają się testem trwałości sesji agentów","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=pl"},{"language":"ru","title":"CompozyOS 0.4.4 превращает обновление рабочего стола в проверку устойчивости сессий агентов","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=ru"},{"language":"zh","title":"CompozyOS 0.4.4 让桌面更新成为持久代理会话的考验","html_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=de","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=de","html":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=de","canonical":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=de","markdown":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=de","json":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=de","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}