OpenClaw 2.0 : sessions, plugins, clés — ce qui change vraiment

OpenClaw 2.0 — tag v2026.8.1, annoncé le 30 août 2026 et tagué sur GitHub tôt le 31 août — déplace les sessions dans SQLite, reconstruit l’app navigateur, et refond l’entrée des plugins et des credentials. Dans la même release qui ajoute les sessions d’équipe, la documentation sécurité a discrètement renommé son périmètre, loin de « personal assistant ».

Si vous faites déjà tourner OpenClaw, voici ce que 2.0 change pour votre install : sessions et transcripts passent en SQLite — et les sessions créées après la migration n’apparaîtront pas dans les anciennes versions — les installs de plugins depuis une source hors ClawHub / catalogue officiel avertissent avant que le code n’arrive, et les credentials gagnent un Secret Store scoped équipe qui sépare valeurs protégées et valeurs lisibles par l’agent. Le tag est v2026.8.1 : l’annonce vendeur est datée 12:00 UTC le 30 août 2026, la release GitHub à 03:30 UTC le 31 août.

L’éditeur parle de la plus grosse mise à jour de l’histoire du projet — et pour une fois, les preuves structurelles tiennent. Mais le changement le plus révélateur n’a mené aucun titre : entre v2026.7.1 et v2026.8.1, la doc sécurité a renommé son en-tête de périmètre, de « personal assistant security model » à « one trust boundary per gateway » — dans la même release qui apprend aux sessions à tourner sur d’autres machines et à être partagées avec des coéquipiers.

Indicateur	Valeur	Détail
Pause de shipping	48 jours	v2026.7.1 → v2026.8.1 (GitHub Releases API)
Startup (lab vendeur)	575 ms	Gateway mocké, 50 ms de latence simulée
Cadence reproduite	106	Releases stables en 230 jours (API GitHub)
Nouvelles pages sécu	5	Absentes en v2026.7.1, présentes en v2026.8.1

Points clés

1. La migration des sessions est à sens unique en pratique. Sessions et transcripts passent en SQLite ; celles créées après n’apparaissent pas dans les anciennes releases. Conseil vendeur : backup vérifié avant upgrade, et revue du chemin de rollback.
2. Le périmètre sécurité a été renommé, discrètement. En v2026.7.1 : « Scope: personal assistant security model ». En v2026.8.1 : « Scope: one trust boundary per gateway ». Aucune couverture revue n’a signalé le rename.
3. Les 575 ms sont un chiffre de labo. Test simulé default-chat, Gateway mocké, 50 ms de latence artificielle — un scénario, pas de taille d’échantillon. Plus étroit que les titres qui ont omis la clause.
4. Les installs de plugins interrogent désormais leur source. ClawHub GitHub exige un SHA de commit complet (plus une branche/tag mutable), et les sources arbitraires nouvelles avertissent avant install. Inchangé : les plugins tournent toujours in-process avec le Gateway.

01 — La release : ce qui a shippé, et quand

D’abord le nom. Il n’y a pas de semver 2.0.0 : le projet utilise un schéma type CalVer (YYYY.M.N), et les notes de release titrent « v2026.8.1 (AKA OpenClaw 2.0) ». Les dates se partagent en deux artefacts : le blog d’annonce à 12:00 UTC le 30 août, la release GitHub à 03:30 UTC le 31 août — environ quinze heures d’avance pour l’annonce. Note housekeeping des release notes : un package publié comme 2026.9.1-beta.1 était mal versionné et est en réalité 2026.8.1-beta.4 — il n’est pas plus récent que le stable 2026.8.1.

Quatre zones portent la release. Une cinquième, non titrée, est structurelle : quatorze intégrations nommées — BytePlus, ComfyUI, Mistral, NovitaAI, OpenCode, Synthetic, Volcengine, Vydra et Xiaomi d’un côté ; Cohere, Meta providers, recherche DuckDuckGo, embeddings Voyage et iMessage de l’autre — sont sorties du core pour devenir des packages officiels installés séparément. L’install par défaut a rétréci ; plus de surface est devenue plugin opt-in.

Zone	Changement	Lecture
Storage	Sessions → SQLite	Breaking · à sens unique en pratique. Outil openclaw backup sqlite. Backup avant upgrade.
Browser app	Control UI reconstruit	Startup Chat ~1,6 s → 575 ms (lab Gateway mocké + 50 ms latence).
Onboarding	Setup guidé de modèles	Réutilise CLI déjà connectés, clés API, Ollama / LM Studio locaux.
Trust & keys	Plugins et clés refondus	Tiers de sources, pins SHA, Secret Store.

Un terme revient : le Gateway est le process long-running d’OpenClaw — les plugins tournent in-process avec lui, les credentials provider restent derrière. Sur les chiffres de perf, le vendeur a été plus prudent que beaucoup de reprises. Les notes donnent les deux nombres avec leur méthodologie. Voici la phrase telle qu’écrite :

« In a simulated default-chat test with a mocked Gateway and 50 millisecond HTTP/1.1 latency, JavaScript requests fell from 140 to 45 and startup fell from about 1.6 seconds to 575 milliseconds. » — notes de release OpenClaw, v2026.8.1

À lire précisément : 140 → 45 est un nombre de requêtes HTTP JavaScript, pas des kilo-octets ; 1,6 s → 575 ms est le cold startup vers Chat dans un seul scénario, contre un Gateway mocké, avec 50 ms de latence simulée — pas de taille d’échantillon, pas de variance, pas de hardware déclaré. « Environ 2,8× plus rapide dans le test mocké du vendeur » est défendable. « 2,8× plus rapide » sans qualificatif, non — et c’est la version que la plupart des titres ont shippée.

02 — Breaking change : les sessions quittent le filesystem

La warning box des release notes est nette : cette release change le stockage des sessions et transcripts vers SQLite. Avant de downgrader vers une ancienne release file-backed, utilisez le CLI courant pour restaurer les artefacts de transcripts legacy archivés ; les sessions créées après la migration n’apparaîtront pas dans les anciennes releases. En pratique, la migration est à sens unique : le rollback, c’est « restaurer les artefacts legacy archivés », pas « réinstaller l’ancienne version ». La même box demande un backup vérifié avant upgrade, et la release livre l’outil openclaw backup sqlite (create, list, verify, restore). Note : le nouveau credential store (section 05) est aussi SQLite — le titre « sessions » sous-estime le scope du changement de stockage.

Les sessions ne sont plus mono-machine. Trois placements possibles : hôte Gateway, device pairé, ou cloud worker — décrit par la nouvelle doc Cloud Sessions comme « a throwaway machine leased through Crabbox », jetable par design, sans credentials permanents dessus. La phrase credentials qui change la proposition :

« In all remote placements, model inference stays proxied through the Gateway — provider credentials never reach the remote machine. » — documentation Cloud Sessions OpenClaw, tag v2026.8.1

L’éditeur pose aussi une limite explicite sur le partage de sessions : les contrôles de collaboration « are not tenant isolation or a security boundary, and revoked access can briefly look available until the UI refreshes or the Gateway rejects the action ». Le body GitHub condense : « these are collaboration controls, not hostile-tenant isolation ». Les sessions multiplayer sont pour des gens qui se font déjà confiance — exactement le cadrage formalisé par le périmètre sécurité renommé.

Un tag, deux réponses. Incohérence documentaire à connaître : au même tag v2026.8.1, les release notes disent que sessions et transcripts sont en SQLite, tandis que la doc sécurité affirme encore qu’OpenClaw stocke les transcripts sur disque sous ~/.openclaw/agents/…/sessions/*.jsonl. Sans avoir exécuté 2.0, on ne peut dire quelle phrase décrit le comportement réel — seulement que deux documents shippés au même tag se contredisent.

03 — Le rename : le périmètre sécurité a changé discrètement

Chaque write-up cité « one trust boundary per gateway » comme slogan 2.0. Aucun n’a noté que la phrase est nouvelle — ni où elle vit. Ce n’est pas du langage de release notes : ça vient de la doc sécurité docs/gateway/security/index.md. La phrase apparaît trois fois en v2026.8.1 et zéro fois en v2026.7.1 comme en v2026.6.11. Et l’en-tête de section a été renommé : en v2026.7.1 « Scope: personal assistant security model » ; en v2026.8.1 « Scope: one trust boundary per gateway ». Une release qui a ajouté les sessions d’équipe a renommé son scope loin de « personal assistant ».

Le nouveau wording est soigneux. Une trust boundary — le périmètre où chaque utilisateur et process est supposé faire confiance aux autres — était « one user/trust boundary per gateway ». Le texte 2.0 élargit : « Supported: one trust boundary per gateway – a single operator or a mutually trusting team (prefer one OS user/host/VPS per boundary). Not supported: one shared gateway/agent used by mutually untrusted or adversarial users. » La frontière grandit d’une personne à une équipe qui se fait confiance, tandis que le langage « not supported » se durcit. Cinq pages sécurité / credentials existent en v2026.8.1 qui n’existaient pas en v2026.7.1 :

Diff d’existence documentaire entre les tags OpenClaw v2026.7.1 et v2026.8.1 (statut HTTP sur raw.githubusercontent.com).

L’inventaire transforme « 2.0 a retravaillé la sécu » d’une claim en une liste. Caution : la présence est un statut HTTP, pas une preuve de nouvelle fonctionnalité — le contenu peut avoir bougé de chemin. Mais cinq nouvelles pages (cloud placement, credential brokering, dependency locking, séparation tenant) dans la même release que les sessions d’équipe forment une histoire cohérente : le projet a cessé de se décrire comme personal assistant et a commencé à documenter où une trust boundary s’arrête et où commence la suivante.

04 — Supply chain : plugins réorientés autour de la provenance

Le contexte de cette section, c’est février : l’incident ClawHavoc, où des skills ClawHub malveillants déguisés en wallets / bots de trading livraient du malware voleur de credentials. Les règles d’install 2.0 se lisent comme la réponse directe. Nouveau en v2026.8.1, sans équivalent en v2026.7.1 : les packages ClawHub et le catalogue officiel/bundled sont des sources de confiance. Une nouvelle source arbitraire npm, npm-pack:, git, chemin/archive local ou marketplace avertit avant install ; les installs non-interactives exigent --force après revue et confiance.

La mécanique s’empile. Un résultat de policy warn s’arrête avant commit ; les commandes interactives font retaper le nom du plugin/skill. Une revue rendue de plus de 4 000 caractères échoue fermée avant prompt. La revue de capacités est liée à l’artefact exact installé et redemande quand une update demande plus d’autorité. Et le changement supply-chain le plus concret : les installs ClawHub GitHub exigent désormais un SHA de commit complet au lieu d’une branche ou d’un tag mutable. Une nouvelle page dependency-locking documente la frontière de revue lockfile.

Deux limites honnêtes. Première : la phrase inchangée — « Plugins run in-process with the Gateway – treat them as trusted code. » — apparaît aux deux tags. 2.0 n’a pas sandboxed les plugins hors du process Gateway ; il a changé ce qu’on vous demande avant qu’un plugin entre. Seconde : un glissement de wording — la doc disait « untrusted » code et dit maintenant « executable » code — lecture : passage à un modèle de sources en tiers, pas une preuve de changement de comportement.

« Trusted sources » n’est pas une garantie. ClawHub désigné source de confiance signifie que son état de scan est exposé avant install — pas que le package est authentique ou sûr. Le vendeur le dit lui-même : la revue montre ce qu’un plugin demande à faire, tandis que l’authenticité et la sûreté du code continuent de dépendre de l’intégrité de l’artefact, de l’identité du registry et de la code review. Traitez le nouveau flux comme de meilleures questions posées plus tôt — pas comme une assurance.

05 — Clés : le credential store sépare protégé et lisible

Le nouveau Secret Store scoped équipe — aussi SQLite, géré via CLI et Settings — sépare deux types de valeurs. Les secrets protégés sont write-only après sauvegarde et peuvent être injectés dans une requête HTTPS Gateway-hosted approuvée via prompts masqués, références Vault / 1Password, et substitution liée à la destination — sans jamais apparaître en clair dans la config ou le texte visible du modèle. Les valeurs d’environnement lisibles par l’agent sont un grant plus faible : la commande qui les reçoit peut encore les imprimer ou les transmettre. Un broker 1Password optionnel résout des références curated avec auth service-account, approbation par secret et audit sans valeur — sa page de doc n’existait pas un tag plus tôt.

« Secret Store values are not encrypted at rest and depend on the filesystem permissions of OpenClaw’s state directory. » — notes de release OpenClaw, v2026.8.1

Et le chemin de substitution a des bords : la substitution destination-bound ne s’applique qu’aux commandes HTTPS Gateway-hosted dont le subprocess honore ses réglages proxy — sockets bruts, containers, nodes distants, harnesses provider-native, HTTP plain et WebSockets sont hors de ce chemin. Lecture juste : vraie amélioration sur où les credentials peuvent éviter d’apparaître, avec un plancher de trust boundary (permissions filesystem) que le vendeur nomme plutôt que de cacher.

06 — La cadence : la pause, mesurée

L’éditeur cadre 2.0 contre sa propre habitude de shipping — et le cadre est vérifiable via l’API GitHub Releases :

« Before this update, we had shipped 106 releases in 230 days, most within a day or two of the one before them, so going nearly seven weeks without shipping was not normal for us. » — blog OpenClaw, 30 août 2026

Claims de cadence OpenClaw confrontées à l’API GitHub Releases.

Vérifier un chiffre vendeur et le trouver juste est plus rare qu’il ne devrait. « 106 releases in 230 days » n’est pas un round marketing — c’est le count littéral des releases stables GitHub sur cette fenêtre exacte. La pause est de 48 jours, matchant la phrase et pas le titre. Nuance : le gap n’était pas un stop total — quatre tags non-prerelease et six prereleases sont tombés dedans, lus comme patches / backports sur des lignes antérieures plutôt que nouvelles feature releases.

Les chiffres communauté voyagent autrement. Le blog affirme que la release « was built by 933 contributors, including 569 first-time contributors, and is composed of over 16,000 pull requests », et qu’elle contient environ la moitié de toutes les PR jamais mergées. Ce sont des chiffres vendeur non vérifiés indépendamment ici — l’endpoint public contributors GitHub compte la lifetime du repo, une population différente.

Méthodologie

• Counts de release — API REST GitHub releases : « stable » = prerelease: false ; fenêtres inclusives des endpoints.
• Diffs de documentation — chaque chemin fetché aux tags v2026.7.1 et v2026.8.1 (plus v2026.6.11 pour l’en-tête de scope). Présence = statut HTTP seulement.
• Chiffres de perf — ceux d’OpenClaw, test simulé contre Gateway mocké + 50 ms latence HTTP/1.1 — un scénario. Non reproduits indépendamment.
• Chiffres communauté — vendeur-stated, non vérifiés indépendamment.

07 — Votre move : avant d’upgrader

Trois migrations demandent du planning : le passage sessions→SQLite (backup d’abord), le retrait du plugin OpenProse bundlé et de la commande /prose, et la migration des références de modèles codex/* et openai-codex/* vers openai/*. Le body de release nomme openclaw doctor --fix pour les migrations OpenProse et routes OpenAI seulement. Deux defaults méritent un regard délibéré car ils sont on by default : consolidation mémoire background model-backed (« grounded dreaming », avec disable explicite) et self-learning automatique, qui applique de nouvelles skills scanner-approuvées sans demander. Et une date à noter : dépréciations annoncées pour le 1er septembre, dont un gate de retrait SDK pour plugins externes — gates annoncés, pas des retraits dans cette release.

• Upgrade cette semaine → backup, puis migrate. Backup vérifié avant upgrade, puis openclaw doctor --fix pour OpenProse / routes OpenAI. Vérifiez les snapshots avec openclaw backup sqlite.
• Rester sur 2026.7.x → connaître la ligne à sens unique. Rien n’oblige l’upgrade, mais une fois migré, les nouvelles sessions sont invisibles aux anciennes releases. Les équipes multi-versions ne doivent pas assumer un retour arrière des fichiers de session.
• Plugins tiers → re-vérifier vos sources. Nouvelles sources npm/git/local/marketplace avertissent ; installs non-interactives besoin de --force après revue. Pinnez ClawHub GitHub par SHA complet.
• Sessions partagées → faire confiance à la boundary, pas à l’UI. Les contrôles de collaboration ne sont pas de l’isolation tenant — et un accès révoqué peut brièvement paraître disponible. Une équipe mutuellement confiante par Gateway ; Gateways, credentials et hosts séparés pour tout le reste.

Le pattern plus large vaut le coup d’être classé : les release notes d’une plateforme d’agents sont désormais aussi des documents de sécurité, et les lire — les differ — fait partie de l’opération de l’outil.

08 — Conclusion : une boundary, lue précisément

Enlevez le théâtre du numéro de version et OpenClaw 2.0 est un trade cohérent : les sessions sont devenues durables, déplaçables et partageables, et en échange le projet a dû dire — précisément — qui est à l’intérieur de la trust boundary et qui n’y est pas. La documentation l’a dit, discrètement : l’en-tête qui lisait « personal assistant security model » lit maintenant « one trust boundary per gateway », et cinq nouvelles pages documentent où cette boundary court.

Résumé opérationnel pour une install existante : backup avant de toucher, parce que la migration sessions est à sens unique en pratique ; ré-auditez d’où viennent vos plugins, parce que le flux d’install pose désormais des questions de provenance ; et lisez le caveat du Secret Store avant de le traiter comme un vault — les valeurs ne sont pas chiffrées at rest. Les chiffres vendeur, là où on a pu les checker, ont tenu : 106 releases en 230 jours se reproduisent exactement depuis l’API GitHub, et la pause était de 48 jours — presque sept semaines, quel que soit le titre du blog.

Le chiffre headline dont il faut rester sceptique est celui qui a voyagé le plus loin : 575 millisecondes est un nombre de labo Gateway mocké d’un seul scénario simulé, et le vendeur l’a dit même quand beaucoup de couverture ne l’a pas fait. La release qui referme la boucle de février mérite le même traitement qu’elle a donné à son propre benchmark — la claim, avec le qualificatif attaché.

FAQ — upgrader vers OpenClaw 2.0

Puis-je rollback vers une ancienne OpenClaw après upgrade ?

Pas proprement. Les release notes indiquent que les sessions créées après la migration SQLite n’apparaissent pas dans les anciennes releases, et qu’avant un downgrade il faut utiliser le CLI courant pour restaurer les artefacts de transcripts legacy archivés. En pratique, traitez la migration comme à sens unique : backup vérifié avant upgrade, et openclaw backup sqlite pour créer / vérifier des snapshots vraiment restaurables.

OpenClaw 2.0 est-il vraiment la version 2.0.0 ?

Non en semver. Le projet utilise CalVer YYYY.M.N ; la release s’appelle officiellement v2026.8.1 (AKA OpenClaw 2.0).

Est-ce que 2.0 sandbox les plugins hors du Gateway ?

Non. Aux deux tags, la doc répète que les plugins tournent in-process avec le Gateway et doivent être traités comme du code de confiance. 2.0 change les questions posées avant l’install, pas l’isolation process.

Qu’est-ce que le gate de retrait SDK du 1er septembre ?

Des dépréciations annoncées (dont un gate de retrait SDK pour plugins externes) pour le 1er septembre — des gates annoncés dans cette release, pas des retraits déjà effectués. Si vous publiez des plugins, surveillez la cible de migration SDK / Agent Plugins nommée dans les notes.