{"schema_version":"1.0","service":"Publicasta","type":"article","id":994,"slug":"compozyos_044_desktop_updates_session_continuity_test","title":"CompozyOS 0.4.4 fait des mises à jour du bureau un test de la durabilité des sessions d’agents","excerpt":"CompozyOS 0.4.4 cherche à préserver les sessions actives pendant les mises à jour du bureau. Un détail en apparence, mais qui pose la vraie question des runtimes d’agents locaux : une mise à jour peut-elle remplacer l’interface sans interrompre le travail ni masquer ce qui s’est passé ?","language":"fr","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=fr","image":{"url":"https://publicasta.com/storage/projects/10/pages/994/2026/10/3545d05d-8eb1-4b5e-a527-2f6888d08fd3.webp","alt":"Espace de travail de développeur où une session d’agent de bureau se poursuit pendant une mise à jour logicielle."},"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:35+00:00","updated_at":"2026-10-28T13:38:35+00:00","content_markdown":"Une mise à jour du bureau est facile à évaluer quand l’application est un éditeur de notes : on ferme la fenêtre, on installe la nouvelle version, puis on rouvre le fichier. Les logiciels d’agents obéissent à un contrat plus exigeant. Une session en cours peut diffuser une sortie, détenir un worktree, attendre une validation, enregistrer des appels d’outils ou coordonner une autre session au moment où l’interface de bureau doit redémarrer.\n\n ![Espace de travail de développeur où une session d’agent de bureau se poursuit pendant une mise à jour logicielle.](https://publicasta.com/storage/projects/10/pages/994/2026/10/3545d05d-8eb1-4b5e-a527-2f6888d08fd3.webp)\n\n C’est ce qui rend CompozyOS 0.4.4 plus intéressant que ne le laisse penser son court changelog. Le [changelog officiel de la version](https://www.compozy.com/changelog/) indique un changement phare pour le 28 octobre 2026 : préserver les sessions actives pendant les mises à jour du bureau. Le projet est un runtime local par défaut pour les sessions d’agents durables, les boucles, l’automatisation, les permissions et plusieurs interfaces de contrôle. Dans ce contexte, le comportement lors d’une mise à jour n’est pas cosmétique. Il fait partie du modèle de fiabilité du runtime.\n\n Le conseil pratique est simple : essayez la version 0.4.4 dans un répertoire CompozyOS jetable ou sauvegardé, puis lancez volontairement une mise à jour pendant qu’une session est active. Ne prenez pas une fenêtre restaurée comme preuve que le travail l’a été aussi. Vérifiez séparément le daemon, la transcription, l’état du tour, les entrées en attente, les pièces jointes, le worktree et la connexion au fournisseur.\n\n ## Ce qui change dans la version 0.4.4\n\n La page de la version décrit actuellement ce changement de manière concise, sans long article consacré à la fonctionnalité : les sessions actives doivent survivre à une mise à jour du bureau. L’historique voisin des versions explique pourquoi cette limite est importante. CompozyOS 0.4.0 était la première version stable, la 0.4.1 corrigeait plusieurs cas liés au bureau et à la récupération du runtime, la 0.4.2 traitait des lectures en arrière-plan de l’utilisation de Claude qui pouvaient demander l’accès au trousseau, et la 0.4.4 vise désormais la continuité pendant la mise à jour du bureau elle-même.\n\n Cette progression compte, car CompozyOS repose sur deux éléments étroitement liés : une application de bureau et un daemon local. La [documentation du bureau](https://www.compozy.com/docs/getting-started/desktop-app/) précise que l’application de bureau et la commande `compozy` utilisent le même daemon local, la même configuration, les mêmes espaces de travail et le même historique de sessions. L’application peut se connecter à un daemon déjà opérationnel, démarrer le runtime installé dans le répertoire personnel de CompozyOS, ou installer et démarrer le runtime fourni avec l’application si nécessaire. Quitter l’application n’est pas censé arrêter le daemon.\n\n Une mise à jour du bureau peut donc recouvrir au moins deux réalités :\n\n - remplacer l’interface graphique tout en laissant le daemon et son état disponibles ;\n- remplacer un paquet qui contient à la fois l’application et le runtime, puis redémarrer le nouvel ensemble sans perdre l’état durable.\n\n Le mot important est « active ». Restaurer une liste d’anciennes sessions au lancement constitue une garantie bien plus faible que maintenir la cohérence d’un tour en cours. Une implémentation utile doit préserver suffisamment d’informations sur la propriété et les événements pour qu’une session puisse continuer, se reconnecter ou signaler clairement une interruption. Le titre de la version ne nous indique pas, à lui seul, comment se comportent chaque fournisseur, système d’exploitation, chemin d’installation ou mode de défaillance. C’est ce que les utilisateurs doivent tester.\n\n ## Pourquoi la continuité du bureau relève du runtime\n\n De nombreux outils d’agents commencent sous la forme d’un processus de terminal. Le processus possède l’invite, l’entrée standard, le flux de sortie et souvent le processus enfant qui exécute le client du modèle. Fermer le terminal peut tout arrêter. Un runtime durable modifie cette organisation : le daemon prend en charge le travail, tandis que le terminal, le navigateur, l’interface de bureau ou un autre client l’observe et le contrôle.\n\n Cette conception crée une séparation utile. L’interface peut disparaître sans nécessairement annuler le travail. Elle rend aussi le parcours de mise à niveau plus exigeant. Le redémarrage d’un client n’est sûr que si le daemon sait ce qui s’est passé avant le redémarrage et peut ensuite rejouer ou reconstituer l’état.\n\n Une mise à jour de session peut franchir plusieurs limites :\n\n 1. Le processus de bureau peut se fermer ou céder le contrôle à un programme d’installation natif.\n2. Le runtime empaqueté peut être remplacé ou redémarré.\n3. Le daemon peut continuer à fonctionner, être invité à s’arrêter ou être découvert après le lancement.\n4. Le processus du fournisseur peut continuer, se reconnecter, échouer ou refuser l’environnement restauré.\n5. L’interface doit décider s’il faut afficher une sortie en direct, une transcription de rattrapage, un avertissement ou un tour réellement arrêté.\n\n La [documentation de CompozyOS](https://www.compozy.com/docs/) décrit le modèle général comme des sessions gérées par le daemon, dont les événements restent consultables tandis que le travail se poursuit en arrière-plan. C’est la bonne abstraction pour une mise à jour, mais il ne faut pas la confondre avec la sauvegarde de chaque effet externe. Une transcription peut être persistante alors qu’une commande shell est encore en cours. Un worktree peut rester attaché alors qu’un fournisseur a perdu sa connexion. Un message en attente peut être stocké alors qu’un agent ne l’a pas encore reçu.\n\n Pour cette raison, « la session a survécu » doit signifier davantage que « la ligne est toujours visible ». Cela doit signifier que le runtime peut indiquer quelle partie a survécu et laquelle nécessite l’intervention d’une personne.\n\n ## Premier test : mettre à jour pendant une session inactive\n\n Commencez par le cas le moins destructif. Créez un espace de travail de test, démarrez une session, envoyez une invite qui produit une réponse persistante, puis laissez la session inactive. Notez l’identifiant de session, l’espace de travail, le profil sélectionné et l’emplacement du répertoire personnel de CompozyOS. Effectuez ensuite la mise à jour du bureau en suivant la procédure documentée.\n\n Le guide du bureau présente trois commandes utiles :\n\n ```text\ncompozy update --check -o json\ncompozy update -o json\ncompozy update --cancel -o json\n```\n\n La documentation indique que l’action de la barre de menus ou des Réglages peut télécharger, installer et redémarrer l’application. Elle précise également que l’application reste ouverte pendant que son programme d’installation natif prépare le paquet vérifié, tandis qu’une application fermée peut préparer la mise à jour pour le prochain lancement. Sous Linux, l’installation automatique du canal de l’application est limitée à la voie AppImage.\n\n Après la mise à jour, vérifiez tous les points suivants au lieu de vous fier au premier écran :\n\n - l’application indique la version attendue ;\n- le même répertoire personnel de CompozyOS est utilisé ;\n- les identifiants de l’espace de travail et de la session sont inchangés ;\n- la transcription précédente est complète et dans le bon ordre ;\n- l’agent et le profil sélectionnés sont toujours associés à la session ;\n- aucun tour en double n’est apparu lors de la reconnexion ;\n- le daemon est sain et l’application y est attachée ;\n- la session peut accepter une nouvelle invite.\n\n Ce test permet de vérifier que l’état persistant ordinaire résiste à la mise à jour. Il ne dit pas encore si le produit sait gérer une mise à jour pendant l’exécution du travail.\n\n ## Deuxième test : mettre à jour pendant l’exécution d’un tour\n\n Le test le plus instructif utilise une invite qui reste active assez longtemps pour être observée. Une commande locale longue, une suite de tests limitée ou une tâche contrôlée produisant plusieurs événements d’outils est préférable à une pause artificielle. Utilisez un dépôt créé pour le test et retirez les identifiants sensibles de son environnement.\n\n Commencez le tour, attendez un événement clair lié à un outil ou à la progression, puis lancez la mise à jour depuis l’interface de bureau. N’envoyez pas d’invites supplémentaires avant d’avoir compris le résultat. Plusieurs issues peuvent être acceptables, selon l’implémentation :\n\n - le daemon et le fournisseur poursuivent leur travail, et le bureau se reconnecte au même tour actif ;\n- le tour s’achève pendant le redémarrage du bureau, puis apparaît avec une transcription complète ;\n- le runtime met le tour en pause ou l’annule, mais enregistre précisément ce fait et permet la reprise ;\n- le programme d’installation refuse de continuer tant que le travail actif n’a pas été traité explicitement.\n\n Le résultat dangereux est une session d’apparence plausible qui perd silencieusement le résultat d’un outil, répète un effet de bord ou affiche une réponse finale sans l’historique des événements qui l’a produite. Un runtime d’agent persistant a besoin d’éléments plus probants qu’un simple redémarrage réussi de la fenêtre.\n\n Utilisez une tâche dont l’effet de bord peut être vérifié deux fois. Par exemple, demandez à l’agent de test d’écrire un fichier au nom unique contenant un nonce, puis de signaler le contenu du fichier. Après la mise à jour, comparez le fichier, la transcription, le résultat de l’outil et la réponse finale. Si l’action a été exécutée deux fois, le test doit le rendre visible. N’utilisez jamais pour cette expérience un déploiement de production, une migration destructive, une action de paiement ou une rotation réelle d’identifiants.\n\n ## Troisième test : entrées et pièces jointes en attente\n\n Une session active ne se résume pas à un tour du modèle. Les opérateurs peuvent saisir un complément pendant que l’agent travaille, mettre un message en file d’attente, orienter un tour ou joindre des fichiers. C’est dans ces entrées qu’une reconnexion peut révéler un état en split-brain.\n\n Créez une petite pièce jointe de test et envoyez une invite qui maintient la session occupée. Préparez un complément, mais n’appuyez pas sur Envoyer tant que le comportement prévu de la file d’attente n’est pas clair. Pendant la mise à jour, observez si le brouillon reste un brouillon, si le message en attente reste en attente et si une action d’orientation est livrée une seule fois plutôt que deux.\n\n L’historique public des versions du projet a régulièrement mentionné la continuité des transcriptions, les entrées en file d’attente, la messagerie des sessions, les pièces jointes et la récupération après une déconnexion du fournisseur. Ces entrées montrent que les mainteneurs considèrent l’état d’une session comme davantage qu’un simple journal de conversation. Elles expliquent aussi pourquoi il vaut mieux tester une version actuelle que déduire tous les comportements d’un seul titre.\n\n Voici une liste de vérification utile :\n\n - le texte non envoyé reste non envoyé ;\n- l’entrée mise en file d’attente possède un seul statut de livraison ;\n- une pièce jointe conserve une identité enregistrée unique et reste lisible ;\n- un message de pilotage ne devient pas un doublon de prompt ordinaire ;\n- une erreur du fournisseur reste visible au lieu d’être remplacée par un indicateur générique de reconnexion ;\n- le profil de la session et les limites de l’espace de travail restent intacts.\n\n Si la mise à jour modifie la position de la session dans la file d’attente, consignez-le comme un comportement du produit. Cela peut être acceptable, mais le changement doit être observable et documenté.\n\n ## Ce que la version 0.4.4 ne prouve pas\n\n Une mise à jour de bureau stable n’équivaut pas à une frontière d’exécution sécurisée. Le dépôt décrit CompozyOS comme un système privilégiant l’exécution locale : un binaire Go et des stockages reposant sur SQLite conservent l’état du runtime sur la machine de l’opérateur, sauf lorsqu’un fournisseur externe ou une extension prend en charge une partie de cette frontière. C’est utile pour le contrôle et l’inspection, mais cela signifie aussi que la machine, le compte utilisateur, les identifiants du fournisseur, les fichiers de l’espace de travail et les extensions installées restent inclus dans le modèle de confiance.\n\n Le dépôt est indiqué comme [sous licence MIT](https://github.com/compozy/compozy), et le README précise que les contributions sont les bienvenues. L’ouverture de la licence permet de savoir si le code peut être inspecté, modifié et redistribué conformément à cette licence. Elle ne garantit ni la maturité de chaque version, ni l’équivalence des propriétés de sécurité de toutes les intégrations, ni l’absence de problème de migration lors d’une mise à jour.\n\n La documentation de migration du projet est particulièrement pertinente. Le [guide de migration](https://github.com/compozy/compozy/blob/main/MIGRATION_GUIDE.md) décrit une correction précédente : les métadonnées de distribution estampillaient par erreur les artefacts comme étant sous licence BSL-1.1, alors que le projet restait sous licence MIT. Le guide documente également les limites de compatibilité entre les anciennes et les nouvelles lignes du produit. C’est une bonne raison de lire les notes de migration lors d’un passage entre grandes versions, plutôt que de supposer qu’une mise à jour sur place est toujours réversible.\n\n Le guide des opérations de bureau ajoute un autre avertissement pratique : après le remplacement d’un binaire du runtime, un redémarrage ou un contrôle de santé échoué peut laisser en place un nouveau binaire qui a déjà migré les bases de données. Les recommandations documentées sont de conserver la sauvegarde pour établir un diagnostic, d’éviter de restaurer un ancien binaire sur un répertoire personnel potentiellement migré, puis, si nécessaire, de réinstaller la version cible ou une version plus récente compatible dans ce même répertoire. Ce sont ces détails qui comptent davantage qu’une animation de mise à jour soignée.\n\n ## Qui devrait l’essayer maintenant\n\n CompozyOS 0.4.4 mérite d’être testé par les développeurs qui ont déjà besoin que le travail d’un agent survive à un terminal et qui peuvent utiliser un répertoire personnel de test distinct. La version concerne également les mainteneurs qui construisent des automatisations autour de sessions d’agents locales, car le parcours de mise à jour fait partie de la disponibilité de l’automatisation. Si l’application sert d’interface de bureau à un démon de longue durée, la version cible directement une interruption que les utilisateurs finissent autrement par redouter.\n\n C’est un choix moins évident pour les équipes qui recherchent un plan de contrôle entièrement géré, une isolation stricte entre les agents et l’hôte, ou un processus mature de gestion des changements en entreprise. La valeur du projet repose sur son modèle de runtime local : sessions, tâches, boucles, permissions, approbations et automatisations partagent un modèle d’état géré par le démon. Cela peut supprimer beaucoup de code de liaison, mais concentre aussi la responsabilité dans l’installation locale et sa configuration.\n\n Un essai raisonnable réunit trois conditions :\n\n - un espace de travail jetable ou une sauvegarde vérifiée ;\n- aucun identifiant de production dans l’environnement du fournisseur utilisé pour le test ;\n- une observabilité suffisante pour comparer la transcription, le système de fichiers, l’état des processus et les journaux de mise à jour.\n\n Conservez l’ancienne version pour comparaison, mais ne rétrogradez pas à la légère un répertoire personnel qui a été migré. Effectuez une sauvegarde complète avant de tester un parcours qui modifie l’état du runtime ou des bases de données.\n\n ## Une brève comparaison avec d’autres approches\n\n Si le besoin consiste simplement à « laisser une commande s’exécuter après avoir fermé le terminal », un multiplexeur de terminal, un service système ou une file de tâches classique sera peut-être plus facile à comprendre. Ces outils n’offrent pas le modèle de session orienté agents de CompozyOS, mais leur comportement opérationnel est familier et souvent assez limité pour être audité.\n\n Si le besoin est une interface web pour le développement à distance, une plateforme de développement hébergée ou autogérée peut proposer des intégrations plus poussées avec l’identité, les espaces de travail et les audits. Elle peut aussi imposer une dépendance au cloud et une autre frontière de confiance. CompozyOS privilégie au contraire un daemon local doté de surfaces de passerelle explicites : le compromis oppose donc le contrôle de la machine au travail opérationnel nécessaire pour la maintenir.\n\n Si le besoin est un exécuteur d’agents indépendant des modèles, une bibliothèque d’orchestration peut exposer des primitives plus bas niveau et laisser à l’application la persistance, les validations et la politique de mise à jour. C’est parfois le bon choix lorsqu’une équipe dispose déjà d’une couche de plateforme fiable. CompozyOS s’attaque au problème inverse : éviter à l’équipe de reconstruire cette couche pour chaque CLI d’agent.\n\n La comparaison doit donc porter sur la gestion des pannes, pas sur le nombre de fonctionnalités. Il faut demander comment chaque solution réagit lorsque l’interface redémarre, que le fournisseur se déconnecte, que l’hôte redémarre, qu’un message est en attente, qu’une migration de base de données a été exécutée ou qu’un processus enfant s’arrête au milieu d’un appel d’outil.\n\n ## Le verdict utile\n\n CompozyOS 0.4.4 est une petite version qui implique un test de grande portée. Préserver les sessions actives pendant une mise à jour du bureau est exactement le genre de fonction de fiabilité que les utilisateurs ne remarquent que lorsqu’elle échoue. Elle a de la valeur parce que CompozyOS se présente comme un runtime local durable, et non comme une simple fenêtre autour d’une invite ponctuelle.\n\n La version est prête à être essayée, mais elle ne justifie pas de confier un travail de production sans surveillance à un système d’agents fraîchement mis à jour. Commencez dans un environnement isolé. Testez les sessions inactives, les tours en cours, les entrées en file, les pièces jointes, les worktrees, les reconnexions au fournisseur et la récupération après une mise à jour interrompue. Conservez les transcriptions et les preuves présentes sur le système de fichiers, puis vérifiez ce que le daemon a réellement fait.\n\n Si ces tests réussissent, la version 0.4.4 réduit le rôle du shell de bureau comme point d’interruption unique. Dans le cas contraire, l’échec restera instructif : il montrera si le problème vient de la coordination de l’installateur, de la gestion du daemon, de la récupération du fournisseur, de la migration de la base de données ou simplement d’un état trompeur de l’interface. C’est cette distinction qui mesure réellement la qualité d’un runtime d’agents open source.","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=fr","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/compozyos_044_desktop_updates_session_continuity_test?lang=fr","html":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=fr","canonical":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test?lang=fr","markdown":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.md?lang=fr","json":"https://publicasta.com/open_source_radar/compozyos_044_desktop_updates_session_continuity_test.json?lang=fr","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"}}