Auto-héberger le runtime d’agents SandBase

Ce que vous obtenez en auto-hébergeant le runtime d’agents SandBase

Auto-héberger le runtime d’agents SandBase consiste à exécuter SandBase Harness sur un serveur que vous administrez. Les sessions, les identifiants, la mémoire et les journaux d’audit sont alors stockés sur votre disque, et non sur celui d’un tiers. Il s’agit d’un service Node. Il écoute sur 127.0.0.1:3000, fournit une API HTTP /v1 et une console web, puis conserve son état dans SQLite, à côté des fichiers de vos agents.

L’API /v1 reprend la structure de Claude Managed Agents (CMA), l’API d’agents managés hébergée. C’est ce qui rend ce runtime intéressant dans les deux sens : vous pouvez écrire du code avec l’Anthropic SDK et faire pointer son baseURL vers votre propre serveur, puis déplacer le même code vers un déploiement hébergé.

SandBase Harness ne fournit pas de modèle. Il en appelle un. En août 2026, il prend en charge les endpoints OpenAI, Anthropic et compatibles avec OpenAI. Cela couvre les gateways auto-hébergées et des fournisseurs comme DeepSeek V4. Vous devez toujours fournir une clé API ou un serveur local qui parle l’API OpenAI.

Ce dont vous avez besoin avant de commencer

• Un VPS sous Ubuntu 24.04 avec au moins 2 GB de RAM. La compilation TypeScript est l’étape la plus lourde de l’installation.
• Node.js 22 ou une version ultérieure, et npm 10 ou une version ultérieure. Ce sont les versions minimales strictes indiquées par le projet.
• git, ainsi qu’une clé API pour le fournisseur de modèles que vous prévoyez d’utiliser.
• Docker, uniquement si vous voulez des sandbox de conteneurs par session.

Ubuntu 24.04 fournit Node 18.19 dans son propre dépôt. Cette version est inférieure au minimum requis. Installez donc Node depuis NodeSource.

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs git
node -v
npm -v

node -v doit afficher v22 ou une version ultérieure, et npm -v doit afficher 10 ou une version ultérieure. Si node -v affiche encore v18.19.1, le paquet de la distribution est toujours installé et prioritaire dans PATH. Supprimez-le avant de continuer, car la compilation utilise la version de node trouvée par le shell.

Installer SandBase depuis le tag v0.3.2

Installez depuis un tag, jamais depuis une branche qui évolue. Un clone bare de main récupère ce qui a été ajouté il y a une heure, et les clés de configuration ci-dessous peuvent ne pas lui correspondre. v0.3.2 est le tag actuel au 16 août 2026.

sudo install -d -o "$USER" -g "$USER" /opt/sandbase
cd /opt/sandbase
git clone --branch v0.3.2 --depth 1 https://github.com/sandbaseai/sandbase-harness.git
cd sandbase-harness
npm ci
npm run build

Utilisez npm ci, pas npm install. ci installe exactement les versions enregistrées dans le lockfile commité, de sorte que votre arborescence corresponde à celle testée par les mainteneurs. npm install peut résoudre des versions plus récentes. C’est ainsi qu’un tag épinglé cesse discrètement de l’être.

Créez maintenant un workspace. Le workspace est un répertoire distinct qui contient vos fichiers d’agent et tout l’état d’exécution. En le conservant en dehors du checkout des sources, vous pouvez récupérer un tag plus récent sans modifier vos données.

mkdir -p /opt/sandbase/workspace
cd /opt/sandbase/workspace
node /opt/sandbase/sandbase-harness/dist/index.js init
node /opt/sandbase/sandbase-harness/dist/index.js start

init écrit un répertoire .managed-agents/ dans le workspace. start démarre la console sur http://127.0.0.1:3000/dashboard et l’API sur http://127.0.0.1:3000/v1. Aucun des deux n’est encore accessible depuis votre laptop, ce qui est correct et sera expliqué plus loin. Accédez pour l’instant à la console via SSH :

ssh -N -L 3000:127.0.0.1:3000 you@your-server

Ce long chemin node .../dist/index.js devient vite pénible. Donnez-lui donc un nom.

alias sandbase='node /opt/sandbase/sandbase-harness/dist/index.js'

Les commandes ci-dessous sont écrites en sandbase <command> dans cette configuration.

N’installez pas ce paquet depuis npm

Le projet l’indique dans sa propre documentation d’installation : le paquet non scoped managed-agents visible sur npm n’est pas celui du projet. npx managed-agents et npm install -g managed-agents récupèrent donc un composant sans rapport avec le runtime recherché. Installez le projet depuis la source GitHub taguée jusqu’à ce que les mainteneurs annoncent un paquet scoped officiel. Ce point ne constitue pas un simple détail historique du projet : v0.3.1 sert principalement à remplacer l’installation rapide depuis npm par la procédure utilisant la source taguée et épinglée.

Configurer l’espace de travail avec un fournisseur de modèles

init écrit .managed-agents/config.yaml. Un seul fournisseur est configuré pour l’ensemble de l’espace de travail. Chaque agent sélectionne ensuite des identifiants de modèle précis.

model:
  provider: openai
  api_key: ${OPENAI_API_KEY}
storage:
  metadata:
    provider: sqlite
    options: {}
  artifacts:
    provider: local
    options:
      base_path: files

Le formulaire ${OPENAI_API_KEY} récupère la valeur dans l’environnement du processus. La clé reste ainsi en dehors du fichier de configuration et de toutes les sauvegardes de ce fichier. Placez-la dans un fichier d’environnement que seul root peut lire, car systemd lit EnvironmentFile= avec les privilèges root avant de les abandonner.

sudo install -d -m 750 /etc/sandbase
sudo touch /etc/sandbase/runtime.env
sudo chmod 600 /etc/sandbase/runtime.env

Ouvrez ce fichier dans un éditeur et ajoutez une ligne, OPENAI_API_KEY=sk-.... Les clés des fournisseurs doivent être placées ici. Les secrets utilisés par un agent pendant une session doivent plutôt être stockés dans les credential vaults du runtime. Il s’agit d’un problème différent, avec un impact différent. Lisez garder les secrets hors des agents IA avant de coller un token de production dans l’un ou l’autre emplacement.

L’agent YAML : mcp_servers, tools et règles d’autorisation

Les agents sont définis dans des fichiers YAML du répertoire agents/ de l’espace de travail. C’est dans cette partie du runtime que vous passerez concrètement le plus de temps. Les clés sont plus faciles à comprendre une fois que vous avez écrit manuellement une petite boucle d’agent, car chacune correspond à un élément que vous devriez sinon coder vous-même : le system prompt, la liste des outils et le contrôle exécuté avant le lancement d’un outil.

name: Incident commander
description: Triages alerts and coordinates response.
model: gpt-4o
system: |-
  You are an on-call incident commander.
mcp_servers:
  - name: sentry
    type: url
    url: https://mcp.sentry.dev/mcp
tools:
  - type: agent_toolset_20260401
    default_config:
      permission_policy: { type: always_ask }
    configs:
      - name: bash
        permission_policy: { type: always_ask }
  - type: mcp_toolset
    mcp_server_name: sentry
metadata:
  template: incident-commander

Chargez-le, puis vérifiez qu’il a bien été importé :

sandbase reload
sandbase list
sandbase chat agent_assistant --message "hello"

reload importe le YAML initial dans SQLite. list doit maintenant afficher l’agent avec un ID. Si list ne l’affiche pas, le fichier n’a pas été analysé et .managed-agents/logs/runtime.log contient la raison.

mcp_servers déclare des endpoints MCP (model context protocol). type: url signifie que le runtime communique en HTTP avec un serveur exécuté ailleurs. Tout ce que vous exploitez déjà peut donc fonctionner ici, y compris les serveurs MCP hébergés sur le même VPS que le runtime. La recherche web est généralement le premier outil utilisé. Avant d’en connecter un, il est utile de lire comment fournir à un agent votre propre instance SearXNG, car un outil qui renvoie des pages rédigées par des tiers injecte directement du texte non fiable dans le contexte du modèle. Pour un premier raccordement plus prudent, préférez la configuration inverse : un endpoint en lecture seule exposant des données que vous contrôlez déjà. C’est ce que openGym expose à côté du suivi des entraînements lui-même. L’agent peut ainsi répondre aux questions sur votre historique d’entraînement sans pouvoir le modifier.

Déclarer un serveur ne transmet pas ses outils à l’agent. La liste tools s’en charge, via une entrée mcp_toolset dont mcp_server_name correspond à name ci-dessus. Si l’agent se comporte comme si les outils MCP n’existaient pas, comparez ces deux chaînes caractère par caractère avant de chercher ailleurs.

agent_toolset_20260401 correspond à l’ensemble d’outils intégré. Le suffixe daté indique une version de schéma. Un agent qui y est associé conserve donc les définitions d’outils contre lesquelles il a été conçu. default_config définit la policy pour tous les outils de l’ensemble. Chaque entrée sous configs remplace cette policy pour un outil donné, identifié par son nom, comme bash dans l’exemple.

permission_policy est l’élément qui distingue un runtime d’un simple appel au modèle. always_ask met la session en pause et attend qu’un humain approuve l’appel avant son exécution. always_allow l’autorise. Définir bash sur always_ask signifie que l’agent ne peut pas exécuter de commande shell sans que vous voyiez d’abord la commande exacte. C’est le même contrôle que vous utiliseriez pour exécuter Claude Code en toute sécurité sur un VPS. Si vous utilisez également DeepSeek Harness, les mêmes contrôles y sont fournis sous forme d’add-ons plutôt que de clés YAML. Les plugins qui limitent les budgets et contrôlent les appels d’outils sont l’équivalent le plus proche de ce bloc.

Les trois modes de sandbox et le cas d’usage de chacun

Les appels d’outils qui exécutent du code s’exécutent dans une sandbox. Le backend est choisi pour chaque environnement via sandbox_provider dans l’objet config de l’environnement, ou dans Settings, puis Sandbox, dans la console. Les environnements sont créés via l’API à l’adresse POST /v1/environments.

local exécute le code comme un processus enfant du runtime, sur l’hôte, avec l’utilisateur du runtime. C’est le mode par défaut. Il convient si vous êtes le seul utilisateur et si l’agent lit uniquement les fichiers qui vous appartiennent. Ce mode n’assure aucune isolation. Un appel d’outil qui supprime des fichiers supprime vos fichiers, et un appel d’outil qui lit /etc/sandbase/runtime.env lit votre clé de provider.

docker démarre un conteneur par session.

{
  "sandbox_provider": "docker",
  "image": "node:22-slim",
  "resources": { "memory": "1g", "cpu": 1 }
}

La session dispose de son propre système de fichiers, de sa propre limite mémoire et de sa propre part de CPU. Le conteneur est supprimé avec la session. Passez à ce mode dès qu’un agent exécute du code que vous n’avez pas écrit. En contrepartie, l’utilisateur du runtime doit pouvoir accéder au socket Docker, et l’appartenance au groupe docker équivaut à des privilèges root sur l’hôte. Les conteneurs créés par session ont la même structure que les sandboxes d’agent auto-hébergées avec un conteneur par exécution. Le raisonnement concernant ce qu’un processus échappé pourrait atteindre s’applique donc ici de la même manière.

kubernetes exécute la charge de travail de la session sous la forme d’un pod et la pilote avec kubectl exec et kubectl cp. L’image du runtime doit contenir kubectl, et son ServiceAccount doit disposer des permissions RBAC (role-based access control) nécessaires pour créer, supprimer, récupérer, lister et surveiller les pods dans le namespace cible, ainsi que la sous-ressource exec. Ce mode ne justifie sa mise en place que si vous exploitez déjà un cluster.

Pourquoi le runtime est-il lié à 127.0.0.1 ?

Parce qu’il démarre avec l’authentification désactivée. Le runtime active l’authentification par bearer token lorsqu’il existe au moins une clé API, mais un nouveau init n’en crée aucune. Lier le runtime à 0.0.0.0 avec cette configuration par défaut exposerait sur Internet un runtime d’agent sans authentification, qui dispose d’outils shell et de votre clé de fournisseur.

Si vous voulez donc le rendre accessible, laissez l’adresse d’écoute telle quelle et effectuez deux autres opérations.

Commencez par activer l’authentification. Définissez MANAGED_AGENTS_API_KEY dans le fichier d’environnement du service, ou créez une clé avec POST /v1/api-keys. Cette commande renvoie un champ secret_key une seule fois et ne l’affiche plus ensuite. Les clients envoient alors Authorization: Bearer <key> avec chaque requête. Une clé correspond à une identité partagée. Si vous voulez en réalité un agent isolé distinct pour chaque membre de l’équipe, avec les clés de fournisseur conservées dans une gateway unique, OneCLI est conçu pour ce modèle.

Ensuite, placez un reverse proxy devant le runtime et terminez-y TLS (transport layer security). Le runtime sert intentionnellement du HTTP en clair et attend qu’un autre composant gère les certificats.

server {
    listen 443 ssl;
    server_name agents.example.com;

    ssl_certificate     /etc/letsencrypt/live/agents.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agents.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

Deux de ces lignes ne sont pas décoratives. proxy_buffering off est nécessaire, car les sessions sont transmises avec des server-sent events (SSE). Lorsque le buffering est activé, nginx conserve la réponse jusqu’à ce que son buffer soit plein. La console n’affiche donc rien pendant que l’agent travaille, puis affiche tout à la fin. proxy_read_timeout 3600s est également nécessaire, car la valeur par défaut est de 60 secondes. Un flux qui reste silencieux plus d’une minute est alors fermé par le proxy au milieu d’une exécution, ce qui donne l’impression que le runtime a planté.

Sur le firewall, ouvrez 22 et 443. Laissez 3000 fermé, car le proxy y accède via le loopback et aucun accès externe ne doit être possible.

Pointez le SDK Anthropic vers votre propre machine

Le runtime implémente une surface /v1 de forme CMA. Un client du SDK Anthropic peut donc communiquer avec lui en modifiant un seul champ.

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({
  apiKey: process.env.MANAGED_AGENTS_API_KEY ?? 'local-dev-key',
  baseURL: 'http://127.0.0.1:3000'
});

Il accepte également les en-têtes beta envoyés par les clients Claude Managed Agents, anthropic-beta: managed-agents-2026-04-01 et anthropic-beta: agent-memory-2026-07-22. Ils sont facultatifs avec un runtime local. Ils permettent au code écrit pour un déploiement hébergé de fonctionner ici sans modification.

La compatibilité est étroite, mais pas totale. Consultez docs/api-matrix.md dans le checkout avant de supposer qu’une surface existe. Le projet y documente ses propres limitations, notamment pour les outils personnalisés côté client, qui nécessitent encore un enregistrement nommé au-dessus du protocole actuel de résultats d’événements.

Le protocole HTTP simple fonctionne tout aussi bien. C’est le moyen le plus rapide de vérifier que le runtime est opérationnel :

curl -N -X POST http://127.0.0.1:3000/v1/sessions/SESSION_ID/messages \
  -H "Content-Type: application/json" \
  -d '{"content": "Hello", "stream": true}'

Une réponse saine est un flux d’événements qui continue d’arriver. Si la connexion est interrompue, reprenez à partir du dernier événement reçu au lieu de rejouer tout le tour :

curl -N http://127.0.0.1:3000/v1/sessions/SESSION_ID/events/stream \
  -H "Last-Event-ID: EVENT_ID"

Ce flux reprenable permet à une session de survivre à la fermeture d’un ordinateur portable. Les événements sont persistés sur le serveur. Le client rejoue donc un journal au lieu de conserver l’unique copie.

Où sont stockés les identifiants, la mémoire et les journaux d’audit

Tout ce que le runtime gère se trouve sous .managed-agents/ dans le workspace.

.managed-agents/
├── config.yaml
├── data.db
├── logs/runtime.log
├── files/
├── skills/
├── snapshots/
└── sandbox/

• data.db contient les métadonnées SQLite : les agents, les sessions, les entrées du coffre d’identifiants, les entrées du store de mémoire et les clés API.
• files/ contient les octets des fichiers téléversés et skills/ contient les packages de skills téléversés.
• snapshots/ contient les snapshots des workspaces de session et sandbox/ contient les répertoires de travail des sessions en mode local.
• logs/runtime.log est le premier emplacement à consulter lorsqu’une action ne produit rien sans afficher d’erreur.

Les coffres d’identifiants regroupent des secrets. Chaque coffre est ajouté avec un auth_type tel que environment_variable, puis associé à une session via vault_ids lors de la création de celle-ci. Les stores de mémoire contiennent des entrées nommées que vous montez dans une session sous la forme d’un memory_store avec ses propres paramètres d’accès et instructions. Les deux sont stockés dans data.db. C’est précisément ce qui distingue ce fonctionnement d’un simple appel au modèle : le runtime conserve les informations entre les sessions et journalise ce qui s’est produit.

Comme tout se trouve dans un seul répertoire, sauvegardez-le en une seule fois.

sudo systemctl stop sandbase
sudo tar czf /root/sandbase-$(date +%F).tgz -C /opt/sandbase/workspace .managed-agents
sudo systemctl start sandbase

Arrêtez d’abord le service. Copier une base de données SQLite pendant que le runtime y écrit peut produire un fichier impossible à ouvrir lors de la restauration. Vous ne le découvrirez que le jour où vous en aurez besoin. Si vous préférez conserver les fichiers YAML des agents dans git et stocker l’état ailleurs, la documentation de déploiement permet de définir l’emplacement de l’état avec --data-dir sur start.

La restauration suit le processus inverse : récupérez le même tag sur une machine vierge, décompressez l’archive dans le workspace, puis démarrez le service. La clé de votre provider ne se trouve pas dans l’archive si vous avez utilisé la forme ${OPENAI_API_KEY}. Conservez-la donc dans un emplacement auquel vous aurez toujours accès.

Exécuter le service avec systemd

Attribuez au runtime son propre utilisateur afin qu’un appel d’outil en mode sandbox local ne puisse pas agir en votre nom.

sudo adduser --system --group --no-create-home --home /opt/sandbase sandbase
sudo chown -R sandbase:sandbase /opt/sandbase

Enregistrez ceci sous /etc/systemd/system/sandbase.service.

[Unit]
Description=SandBase Harness runtime
After=network-online.target

[Service]
User=sandbase
Group=sandbase
WorkingDirectory=/opt/sandbase/workspace
EnvironmentFile=/etc/sandbase/runtime.env
ExecStart=/usr/bin/node /opt/sandbase/sandbase-harness/dist/index.js start --host 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

L’exemple de déploiement du projet appelle un binaire managed-agents sur PATH. Une installation depuis les sources taguées n’en crée pas. ExecStart exécute donc node sur le point d’entrée compilé.

sudo systemctl daemon-reload
sudo systemctl enable --now sandbase
sudo systemctl status sandbase
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/dashboard

Un résultat correct est active (running) depuis status et 200 depuis curl. Dans tout autre cas, consultez d’abord journalctl -u sandbase -n 50, puis .managed-agents/logs/runtime.log. enable --now est la moitié importante, car un processus lancé manuellement disparaît au prochain redémarrage.

Ce qui échoue et le message affiché

npm run build est arrêté sans message d’erreur par npm. Sur un VPS de 1 GB, la compilation TypeScript est arrêtée par l’out-of-memory killer du kernel. Celui-ci écrit le message dans le kernel log, et non dans npm. Confirmez-le avec journalctl -k | grep -i "out of memory", qui affiche une ligne indiquant le processus node arrêté. Ajoutez du swap, ou effectuez le build sur une instance plus grande et copiez dist/.

Error: listen EADDRINUSE: address already in use 127.0.0.1:3000. Un autre processus utilise déjà le port. sudo ss -lntp | grep 3000 indique lequel. Arrêtez ce processus ou démarrez le runtime avec --port 3001, puis mettez à jour le proxy.

Le dashboard ne se charge pas depuis votre laptop. C’est le comportement attendu, car le runtime écoute sur l’interface loopback. Utilisez le tunnel SSH indiqué plus haut ou terminez la configuration du reverse proxy. Ne corrigez pas ce problème avec --host 0.0.0.0, car l’authentification reste désactivée tant qu’aucune key n’existe.

Les sandboxes Docker échouent avec permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock. L’utilisateur sandbase n’appartient pas au groupe docker. Corrigez cela avec sudo usermod -aG docker sandbase, puis redémarrez le service. Gardez à l’esprit ce que vous avez accordé : ce groupe donne les privilèges root sur l’hôte. Cela annule donc en partie la raison pour laquelle vous avez attribué son propre utilisateur au runtime.

Les sandboxes Kubernetes échouent avec Error from server (Forbidden). Le ServiceAccount ne dispose pas des permissions sur les pods ou sur la sous-ressource exec. Vérifiez-le directement avec kubectl auth can-i create pods/exec -n <namespace>, qui renvoie yes ou no.

Toutes les requêtes renvoient 401 après l’ajout d’une API key. L’authentification est activée dès qu’une première key existe. Elle s’applique à la console comme à l’API. Envoyez Authorization: Bearer <key>. Si vous avez perdu la key, créez-en une autre, car secret_key n’est renvoyée qu’une seule fois et n’est pas stockée sous une forme lisible.

Les tools d’un serveur MCP n’apparaissent jamais dans une session. Comparez le mcp_server_name du bloc tools avec le name dans mcp_servers. Vérifiez ensuite que le runtime peut atteindre l’URL depuis le serveur lui-même avec curl -i <url>. Un serveur MCP de type URL est une dépendance réseau. Un VPS résout les noms et achemine le trafic différemment de votre laptop.

FAQ

Puis-je exécuter SandBase Harness sans clé OpenAI ou Anthropic ?

Oui, si vous disposez d’un endpoint compatible avec OpenAI. Le runtime prend en charge les fournisseurs OpenAI, Anthropic et compatibles avec OpenAI. Un serveur local qui implémente l’API OpenAI fonctionne donc également. Définissez le fournisseur du workspace dans .managed-agents/config.yaml, puis indiquez cet endpoint dans api_key. Le runtime n’intègre aucun modèle. Un service doit donc répondre aux appels.

Est-il sûr d’exposer le runtime sur un port public ?

Non, pas avec la configuration installée. Il écoute sur 127.0.0.1:3000 et démarre avec l’authentification désactivée. La solution ne consiste pas à utiliser une autre adresse d’écoute. Créez une clé API ou définissez MANAGED_AGENTS_API_KEY pour activer l’authentification par bearer token. Placez ensuite nginx ou Caddy devant le runtime pour gérer TLS. Fermez le port 3000 dans le firewall afin que le proxy soit le seul point d’accès.

Quelle est la différence entre les sandbox locales, Docker et Kubernetes ?

local exécute le code des outils comme un processus enfant du runtime sur l’hôte, avec les permissions de l’utilisateur du runtime et sans isolation. docker attribue à chaque session son propre conteneur, avec son propre système de fichiers, une limite de mémoire et une part de CPU, puis le supprime à la fin de la session. kubernetes exécute la session comme un pod et le pilote avec kubectl exec. Cette méthode nécessite kubectl dans l’image du runtime, ainsi que RBAC sur les pods et sur la sous-ressource exec dans le namespace cible.

Que dois-je exactement sauvegarder ?

Le répertoire .managed-agents/ du workspace. Il contient config.yaml, la base de données SQLite data.db avec les agents, les sessions, les entrées du coffre de credentials et les entrées de mémoire, ainsi que les fichiers importés, les packages de skills et les snapshots de session. Arrêtez le service avant de le copier afin que SQLite ne soit pas modifiée pendant la création de l’archive. Les clés API des fournisseurs référencées comme ${OPENAI_API_KEY} ne se trouvent pas dans la sauvegarde. Stockez-les séparément.

Pourquoi cloner le tag v0.3.2 au lieu de main ?

Un tag correspond à un arbre figé. Les clés de configuration et les commandes CLI décrites sont donc celles que vous obtenez réellement. main évolue, et une clé de configuration peut être renommée entre la rédaction d’un guide et son exécution. Le projet indique également que le package managed-agents non scoped publié sur npm ne correspond pas à ce projet. npx managed-agents installe donc un package sans rapport. La release v0.3.1 sert principalement à remplacer cette procédure npm rapide par l’installation depuis la source associée au tag spécifié.