CLI

La ligne de commande beeuni, son modèle d’authentification, la boucle de développement et chaque commande.

L’interface en ligne de commande (CLI) beeuni permet de contrôler Beeuni depuis un terminal — sur votre ordinateur ou dans un environnement de session isolé. Cette page présente le cycle de développement habituel, puis répertorie chaque commande stable et chaque option.

Installation

curl -fsSL https://beeuni.ai/install | bash

Le programme d’installation télécharge un binaire précompilé pour macOS et Linux. Windows n’est pas pris en charge.

Modèle d’authentification

Beeuni stocke l’authentification par hôte, et non de façon globale. Un hôte correspond à un point de terminaison de l’API Beeuni. Utilisez cloud pour vous connecter à Beeuni.

Le fichier de configuration se trouve à l’emplacement ~/.config/beeuni/config.json, avec le mode 0600. Remplacez son chemin avec BEEUNI_CONFIG_FILE.

La CLI suit une hiérarchie : hôte → compte → projet → session. Vous vous connectez à un hôte, choisissez un compte dans cet hôte, choisissez un projet dans ce compte, puis ouvrez des sessions dans ce projet. beeuni hosts login exécute les trois premières étapes dans l’ordre : il vous connecte, choisit le compte, puis définit un projet par défaut.

Tous les jetons commencent par beeuni_pat_. Un jeton utilisateur, obtenu avec beeuni login, donne accès à tous les comptes et projets auxquels vous appartenez. Un jeton de projet est créé automatiquement pour un environnement de session isolé et limité à un seul projet. Consultez Portée des jetons.

Le cycle de développement

Ce cycle suppose que la CLI est installée et que vous avez exécuté beeuni login. Consultez Démarrage rapide pour la configuration.

beeuni init my-app
cd my-app

beeuni projects link <project-id>

beeuni ship

beeuni sessions new --prompt "Build the login page" --wait

beeuni connect

beeuni sessions chat

beeuni tui        # or: beeuni t, or beeunit
beeunit --project <id> --new --terminal   # new session + sandbox shell, one command

beeuni sessions shell

beeuni sessions ls

beeuni cr ls
beeuni cr diff 1
beeuni cr merge 1

Référence

Commandes d’authentification

beeuni hosts login / hosts logout / hosts whoami sont les formes canoniques. login / logout / whoami sont des raccourcis qui agissent sur l’hôte actif.

Hôtes

L’URL d’un hôte distant qui commence par http:// est normalisée en https://. La CLI n’envoie jamais de jeton à un hôte distant via HTTP non chiffré. localhost fait exception.

Comptes

Membres

Qui appartient au compte et quel est son rôle dans celui-ci. Les rôles sont owner, admin et member. Les propriétaires et les administrateurs disposent implicitement du rôle Manager dans chaque projet. member est donc le seul rôle qui nécessite des autorisations propres à chaque projet.

Un <user> est un identifiant utilisateur ou l’adresse e-mail d’une personne déjà membre du compte. Options : --account <id>, --host <name>, --json, -y.

Groupes

Un groupe de comptes est un ensemble nommé de personnes auxquelles vous attribuez un rôle en une seule fois. Associez un groupe à une portée avec beeuni access grant --group <id> --role <key> ; révoquez cette association avec beeuni access revoke <assignment-id>.

Un <group> est un identifiant de groupe ou son nom exact. Les lectures nécessitent group.read. create, set et add nécessitent group.update ou group.members.manage, ainsi que le droit rbac de l’entreprise. rm et remove servent au nettoyage et ne sont jamais soumis à des droits.

Jetons

Identifiants non interactifs du compte. Les lectures nécessitent token.read. Chaque membre du compte peut créer et révoquer ses propres clés personnelles (token.personal.create, token.personal.revoke) ; une clé personnelle agit en votre nom et ne possède jamais plus de vos propres rôles. Les comptes de service et les clés d’autres personnes nécessitent token.create / token.revoke (propriétaire et administrateur).

Une clé API personnelle agit en votre nom et expire avec votre adhésion. Un compte de service agit en son propre nom et n’hérite d’aucun accès : un nouveau compte ne possède aucune autorisation. Accordez-lui-en une avec beeuni access grant --service-account <id> --role <key>. --expires <when> accepte une date ISO-8601 ou une durée à partir de maintenant : 30d, 12h, 6w, 1y.

Facturation

Lisez le forfait, les crédits et les dépenses du compte actif. Lecture seule : les changements de forfait, les recharges et les moyens de paiement se font dans le tableau de bord.

Filtres : --project <id>, --session <id> et --owner <id> (sessions, avec --by session). Options : --account <id>, --host <name>, --json.

Projets

Une commande détermine « le projet » dans cet ordre :

1. L’option --project.
2. La variable d’environnement BEEUNI_PROJECT_ID.
3. .beeuni/link.json dans le répertoire de travail exact.
4. La valeur par défaut globale définie par beeuni projects use.

Un projet n’affiche qu’une seule icône : écrire --icon efface le glyphe et écrire --glyph efface l’emoji ; transmettre les deux est refusé. Couleurs des glyphes : grey, red, orange, yellow, lime, blue, purple, magenta. set et features nécessitent project.settings.write. Un indicateur que la plateforme marque comme indisponible reste désactivé, quelle que soit la surcharge du projet.

Un jeton CLI de projet est associé à un seul projet — l’API le rejette partout ailleurs. Un bac à sable de session utilise son BEEUNI_TOKEN associé à la session. cli-tokens ls nécessite l’accès en lecture au projet ; new et rm nécessitent project.credentials.issue. Un jeton associé à une session ne peut ni créer ni révoquer de jetons de projet (403), que le projet déclare ou non des agents. Un jeton CLI de projet suit la politique PAT du compte : lorsque le compte exige une expiration, transmettez --expires-at ; une expiration dépassant la durée de vie maximale renvoie 400.

beeuni projects upgrade nécessite l’accès en écriture au projet. L’agent par défaut actualise la référence du marketplace, réécrit le manifeste, exécute beeuni validate et ouvre une demande de modification. Il ne fusionne jamais les modifications : un humain examine le diff.

Structure du projet

beeuni init [project-name] [options] crée un nouveau répertoire de projet. Le modèle initial écrit un beeuni.yaml v2, agents/, skills/, memory/ et harnesses/opencode/. La commande peut configurer la détection des outils de codage locaux sans modifier le moteur d’agent par défaut. Elle n’écrit pas .beeuni/link.json. beeuni ship ou beeuni projects link créent ce fichier.

La sélection de l’outil de codage local ne modifie pas le moteur d’agent par défaut.

beeuni init n’inclut pas de sélecteur de marketplace. Ajouter une compétence de marketplace est une importation d’agent : démarrez une session et demandez à l’agent d’en importer une.

Livraison

beeuni ship prépare, valide et pousse votre branche actuelle vers le dépôt git du projet. Exécutez-la une fois pour créer le projet, puis à nouveau à tout moment pour le synchroniser. Alias : beeuni deploy.

À chaque exécution :

• Exécute les vérifications beeuni validate : beeuni.yaml fusionné avec tous les fichiers qu’il répertorie sous imports:, les Dockerfiles du bac à sable, le câblage de l’agent et la taille du dépôt (ignorer avec --no-verify). Une erreur bloque la publication. Un avertissement ne la bloque jamais.
• Valide toute modification non validée de l’arborescence de travail (ignorer avec --no-commit).
• Demande tout secret env manquant (ignorer avec --no-env).
• Pousse la branche actuelle vers la branche distante du même nom.
• Connecte tout connecteur déclaré qui nécessite encore une authentification (ignorer avec --no-connect).

Un origin GitHub existant est associé via l’application Beeuni GitHub. Tout autre origin existant est enregistré tel quel. Sans origin, un dépôt git Beeuni géré est créé.

Applications

Apps héberge des sites statiques, serveurs, tâches et bases de données. Chaque App possède une URL stable. Une version contient le code et la configuration ; un déploiement échoué ne remplace pas la version active.

beeuni apps list
beeuni apps show main
beeuni apps connect main
beeuni apps launch --template convex --slug main
beeuni apps deploy dist --type static --spa
beeuni apps machines main
beeuni apps volumes main

Reliez les Apps avec uses et les exemples de beeuni apps connect. Ne placez pas les identifiants administratifs dans le code client.

Les ressources actives consomment les crédits du compte. Consultez Billing et Usage. Apps ne possède pas de budget mensuel distinct.

Apps

Sessions

Chaque session s’exécute dans un bac à sable sur sa propre branche.

sessions queue nécessite project.session.start — la même autorisation que pour envoyer un message. Une invite mise en file d’attente persiste à la fermeture du terminal et est transmise lorsque la session peut la recevoir. Ajoutez-en une avec beeuni sessions chat <id> -p "…" --queue, ou orientez le tour en cours avec --steer. sessions queue ls affiche l’DELIVERY de chaque invite (steer, queue ou interrupt) et, pour une invite d’orientation exécutée comme queue, le motif : unsupported (la session ne peut pas recevoir de messages pendant un tour), not_prompter (le tour d’un autre membre est en cours) ou turn_ended.

Les sessions approvals sont persistantes : contrairement aux sessions pending, elles survivent au redémarrage du bac à sable. Il faut project.members.manage, ou être l’humain qui a lancé la session. Un agent ne peut jamais résoudre sa propre demande d’approbation.

sessions attachments lit le stockage de fichiers privé de la session, et non son espace de travail. Les fichiers y sont déposés au moment de l’envoi, et chaque fichier présenté par l’agent y est déposé à la fin du tour.

sessions files lit l’arborescence de travail que l’agent modifie en ce moment, avant que quoi que ce soit soit validé ; beeuni files lit plutôt le dépôt validé. Les chemins sont résolus sous /workspace, sauf s’ils commencent par /workspace, /tmp, /home ou /opt. La commande réveille le bac à sable s’il est en veille. Options : --from <local path> (write lit ce fichier au lieu de stdin), --content (find recherche dans le contenu avec ripgrep plutôt que dans les noms de fichiers), --limit <N> (limite de fichiers find) et -y pour ignorer la confirmation rm.

sessions share est soumis au contrôle du propriétaire : l’API refuse les demandes d’un responsable de projet qui ne peut pas déjà lire la session. Une session partagée s’exécute uniquement avec les clés du fournisseur partagées avec l’ensemble du projet : un modèle exécuté avec vos propres clés passe aux clés du projet pour ce fournisseur ; si aucune clé de ce fournisseur n’est disponible, le partage est refusé (409 SHARED_SESSION_NEEDS_PROJECT_KEY).

Options de sessions links create : --port <n> (par défaut 3000 ; 22, 8000 et les ports opencode sont refusés), --path <p> (par défaut /), --preview <id> (un candidat nommé — web, vite, dev-server, api-docs — au lieu de --port/--path), --file <path> (partager un fichier de l’espace de travail au lieu d’un aperçu ; toujours en lecture seule), --mode view\|interactive (par défaut view ; interactive autorise les écritures et les websockets, et est ignoré pour --file), --label <text> et --expires <iso>. La création d’un lien nécessite l’accord du propriétaire de la session, car le lien lui-même ne nécessite aucune connexion ; la liste et la révocation sont également accessibles à un responsable de projet.

Dans un bac à sable, BEEUNI_SESSION_ID est l’identifiant de votre propre session.

Demandes de modification

Une demande de modification (CR) fusionne une branche dans une autre sur n’importe quel hébergeur Git. C’est le seul moyen pour un agent d’intégrer le travail de sa session dans la branche par défaut. Voir Demandes de modification.

request-changes ajoute une note à la CR et la transmet à la session d’origine, en démarrant son bac à sable s’il est en veille. Nécessite project.review.act — la même autorisation terminale que celle utilisée par le Centre de révision, et non gitops.push.

<cr> accepte un numéro propre au projet (3) ou l’identifiant complet. Dans un bac à sable, l’interface en ligne de commande lit automatiquement son jeton — aucune connexion ni aucun lien ne sont nécessaires.

Révision

La boîte de réception de révision du projet — tout ce qui attend une décision humaine : demandes de modification, appels d’outils de connecteur dont la politique exige une approbation, ainsi que les résultats, décisions et lots soumis par les agents pour approbation. Elle reflète le Centre de révision du tableau de bord. Activée pour tous les projets ; project.review.read et project.review.act contrôlent la lecture et les actions.

Verdicts : approve, reject, changes, answer, dismiss. Segments : needs_you, waiting, done. Types : change, approval, output, decision, batch.

La destination d’un verdict dépend de l’identifiant de l’élément. Pour cr:<id>, approve fusionne la modification, reject la ferme et changes renvoie la note à l’agent qui l’a ouverte (--message requis). Pour call:<id>, approve autorise l’exécution de l’appel et reject le refuse ; une approbation de connecteur n’accepte aucun autre verdict — consultez d’abord ses arguments avec beeuni review show. Tous les autres identifiants sont traités par le point de terminaison d’action natif, qui accepte tous les verdicts.

bulk agit uniquement sur les identifiants natifs. Une approbation de connecteur nécessite l’examen de ses paramètres et une demande de modification nécessite de consulter son diff ; les deux sont signalées et ignorées — même règle que pour la sélection multiple du tableau de bord.

Options de submit : --kind output\|decision\|batch (obligatoire), --title <text> (obligatoire), --summary <text>, --risk none\|low\|medium\|high (par défaut none), --detail <json> (un objet JSON), --agent <name> et --session <id> (ignoré si la session ne fait pas partie de ce projet).

La lecture nécessite project.review.read, les verdicts nécessitent project.review.act et submit nécessite project.review.submit.

Secrets

Valeurs chiffrées stockées sur le projet. Par défaut, un secret est injecté comme variable d’environnement en clair dans chaque sandbox de session au démarrage (exposition via l’environnement). La livraison renforcée — où la sandbox conserve un handle et où Beeuni substitue la valeur réelle à l’extérieur (exposition renforcée par la sortie, et beeuni secrets call) — est expérimentale. Activez l’indicateur de fonctionnalité secrets_egress (Settings → Feature flags) pour l’utiliser ; lorsqu’il est désactivé, beeuni secrets delivery … egress renvoie 403 feature_disabled. Voir Secrets.

grant corrige une ligne que ls signale comme impossible à livrer. Il élargit uniquement la liste d’un agent ; pour la réduire ou la remplacer, réécrivez l’ensemble avec beeuni agents scope. There is no secrets revoke — l’API ne propose aucune route supprimant un seul identifiant d’une autorisation. La première autorisation accordée sur un projet sans agent lance la gouvernance : dès lors, un agent absent du manifeste ne reçoit aucun secret du projet, et la commande l’indique lorsque cela se produit.

Environnement

Agents

Paramètres de modèle par agent sur le projet associé.

Chaque option de portée remplace ; aucune ne fusionne. Une valeur --set est analysée comme JSON lorsqu’elle peut l’être, et conservée comme chaîne dans le cas contraire. Les définitions de modèles et scope s’appliquent instantanément, sans commit beeuni.yaml ; default et config effectuent un commit vers beeuni.yaml sur la branche par défaut du projet. scope nécessite project.agent.write, tout comme default et config.

Outils

Les outils dont disposent les sessions de ce projet, lus depuis le fichier beeuni.yaml local et ses imports. Exécutez depuis la racine du projet. Voir Outils.

Sans clé tools:, chaque session reçoit les cinq outils Beeuni (web_search, image_search, scrape_webpage, memory, show). Avec une clé tools:, les sessions reçoivent uniquement les outils Beeuni qu’elle répertorie. Pour supprimer un outil Beeuni, supprimez sa ligne sous tools:, puis exécutez beeuni validate. Pour limiter les outils d’un agent, utilisez agents.<name>.tools. Codes de sortie : 0 terminé, 1 refusé (un fichier existe, un manifeste ou un import ne peut pas être analysé), 2 aucun manifeste, option inconnue ou nom qui n’est pas un outil Beeuni.

Modèles

Les modèles proposés par le projet et celui avec lequel il démarre. Même interface que la section Customize → Models du tableau de bord. Un projet ne stocke que ses exceptions à la valeur par défaut du catalogue (le modèle le plus récent de chaque famille). L’activation est uniquement visuelle : elle détermine ce que proposent les sélecteurs, jamais ce que la passerelle fournit.

Les identifiants de modèles sont des identifiants filaires de la passerelle — un identifiant géré nu (glm-5.3-flash) ou un provider/model BYOK. Copiez-en un depuis beeuni models ls --json. Les définitions par agent se trouvent sur beeuni agents model <agent> <model-id>. Les écritures nécessitent project.model.write.

Canaux

Gère la connexion du projet à une plateforme de discussion. Les jetons sont stockés chiffrés dans les secrets du projet et résolus côté serveur — ils ne sont jamais injectés dans la sandbox.

--platform slack|teams sélectionne la plateforme ; par défaut slack. Teams connect affiche l’URL de consentement de l’administrateur Microsoft ; l’octroi du consentement à l’échelle du tenant publie automatiquement l’application dans le catalogue Teams. Voir Connectors.

Le canal e-mail repose sur AgentMail et nécessite le feature flag agentmail_email. Options email connect : --connector <slug> (par défaut beeuni_email), --api-key <k> (utilisez votre propre clé AgentMail ; - lit depuis stdin), --display-name <n> (nom affiché comme expéditeur des e-mails sortants ; par défaut, le nom du projet), --username <u> et --domain <d> (nouvelle boîte de réception gérée), et --inbox-id <id> avec --email <addr> (associer une boîte de réception existante — les deux sont obligatoires ensemble). --allow peut être répété et active le mode restreint ; une valeur seule sans @, ou précédée de @, est interprétée comme un domaine. --allow-all vide la liste et accepte à nouveau tous les expéditeurs.

Les écritures e-mail et bind nécessitent project.connector.write.

Connecteurs

Les connecteurs sont des outils qu’un agent peut appeler. add, rm et policy set modifient le fichier local beeuni.yaml ; exécutez beeuni ship pour appliquer les changements, sauf si vous transmettez --apply pour modifier immédiatement le projet cloud.

policy ls, show, set, add et rm constituent la surface à l’échelle du projet. Un connecteur portant l’un de ces noms de verbes doit donc être désigné par policy <slug> ls. Un <match> peut être un nom d’outil, un motif glob (send_*) ou un /regex/.

Options add : --name <label>, --provider <pipedream\|mcp\|openapi\|postman\|graphql\|http>, --app <slug>, --url <url>, --transport <http\|sse>, --endpoint <url>, --base-url <url>, --spec <url\|path>, --auth-type <none\|bearer\|basic\|custom>, --credential shared.

Environnements de test

Gère les images d’environnement de test du projet. Un modèle définit une image ou un Dockerfile, ainsi que des ressources ; une compilation produit l’instantané à partir duquel les sessions démarrent.

L’affectation d’un fournisseur nécessite project.settings.write.

Options add/update : --name <label>, --cpu <n>, --memory <n> (GiB), --disk <n> (GiB).

Backends

Les bases de données sont des Apps avec des volumes persistants. Gérez-les et connectez-les via Apps.

Apps

Marketplace

Parcourez la marketplace Beeuni et installez un élément dans un projet.

Options : --query <text>, --type <type>, --source <source>, --host <name>, --project <id>, --json.

L’installation est pilotée par un agent : il démarre une session de projet qui clone l’élément, l’examine, fusionne ce qui convient et ouvre une demande de modification. Il n’existe pas de mécanisme d’installation, de mise à jour ou de suppression déterministe.

Compétences système

Les compétences système de Beeuni constituent la référence opérationnelle de la plateforme, pour les personnes comme pour les agents. Elles couvrent les sessions, les environnements isolés, le moteur d’agent par défaut, les connecteurs, la mémoire et les canaux. Cette page publique en est le point d’entrée ; la CLI authentifiée récupère les compétences depuis l’hôte en cours d’exécution. Utilisez beeuni system-skills list pour découvrir les compétences disponibles, puis get pour celle dont vous avez besoin. L’API les fournit en direct, elles correspondent donc à la version déployée de l’hôte. Ne considérez pas une copie locale comme à jour.

Options : --host <name>, --json.

beeuni skills est un alias permanent pour la même commande. Connectez-vous d’abord à l’hôte avec beeuni login ; l’API des compétences exige une authentification. Utilisez --host <name> pour travailler avec un autre hôte. Une page de documentation publique ne peut pas remplacer ces instructions en direct, propres à l’hôte.

Cette liste contient toujours les compétences système, jamais un mélange. Les compétences facultatives se trouvent dans la marketplace : beeuni marketplace list --type skill. Pour la syntaxe des commandes, utilisez beeuni <command> --help ; pour la référence complète de la plateforme, consultez beeuni system-skills get beeuni-system --full.

Connecteur

L’interface de l’agent dans l’environnement isolé avec tous les connecteurs. Chaque appel est vérifié, résolu et audité côté serveur ; la CLI ne détient jamais d’identifiants tiers. Authentification : BEEUNI_TOKEN. La sortie est au format JSON.

Fichiers

Vue en lecture seule du dépôt git du projet. Agit sur la branche par défaut, sauf si --ref indique une autre branche, une balise ou un commit.

Options disponibles pour chaque sous-commande : --ref <ref>, --path <p>, --limit <n>, --json. download accepte également -o, --out <file>, obligatoire.

Chaque sous-commande nécessite project.file.read. download refuse aussi tout sous-arbre qui inclurait un agent ou une compétence auxquels vous n’avez pas accès — un zip ne peut pas être filtré pendant son téléchargement — ; dans ce cas, archivez un --path plus restreint.

Déclencheurs

Un déclencheur démarre une session selon un calendrier, un webhook, un événement d’application ou un moniteur (expérimental). add, rm, enable, disable modifient le manifeste local — exécutez beeuni ship pour appliquer les changements. pause/resume actionnent un interrupteur distinct côté serveur. Voir Déclencheurs.

Options de add : --type <cron\|webhook\|event\|monitor> (par défaut cron), --prompt <text> (obligatoire), --agent <name>, --cron <expr> (6 champs, p. ex. "0 0 9 * * 1-5"), --run-at <iso> (exécution unique à cet instant au lieu d’une expression cron), --timezone <tz> (UTC par défaut), --secret-env <NAME>, --name <label>, --disabled.

Options réservées aux déclencheurs actifs — valides avec add --apply et chaque set : --model <provider/model>, --session-mode <fresh\|keyed\|pinned\|reuse>, --session-key <tmpl> (regroupe une session par clé, p. ex. "{{ body.data.chat_jid }}" ; implique keyed), --session-id <id> (la session dans laquelle boucle un déclencheur pinned ; doit être une session de ce projet), --session-access <private\|project\|members> (par défaut private), --member <uuid> et --group <uuid> (répétables ; chacun implique members), et --filter <path=value> (répétable ; tous doivent correspondre, p. ex. --filter body.type=push).

set accepte toutes les options réservées aux déclencheurs actifs, ainsi que --name, --prompt, --cron, --run-at, --timezone, --secret-env, --agent et --enabled true|false. --cron et --run-at sont exclusifs : définir l’un efface l’autre. Les champs du moniteur sont uniquement ajoutés.

Rappels

Un rappel relance une session ultérieurement, une fois ou de manière répétée. Il est stocké dans la base de données, et non dans beeuni.yaml. Dans une session, --session vaut $BEEUNI_SESSION_ID par défaut. Voir Rappels.

Options de planification : --in <duration> ou --at <iso> (première exécution ; utilisé seul, déclenche une seule exécution), --every <duration> (répétition, minimum 5m), --cron "<expr>" avec --timezone <tz>. Autres options : --name <label>, --session <id> (un préfixe unique suffit), --project <id>, --host <name>, --json.

Options d’événement (--type event) : --connector <slug> et --event <TYPE> (toutes deux obligatoires), --config key=value (répétable, valeurs de type chaîne) et --config-json '{...}' (valeurs typées). set accepte les mêmes indicateurs. Un déclencheur d’événement rejette --cron, --run-at, --timezone, --secret-env et les options de moniteur. L’invite lit {{ event.data.<field> }} ; voir Déclencheurs d’événements d’application.

Options de moniteur (--type monitor) : --run <cmd> (commande relative au dépôt à superviser ; obligatoire), --mode <poll\|stream> (obligatoire ; poll relance la commande sur --interval, stream la maintient en vie), --interval <dur> (mode=poll uniquement, minimum 30 s, p. ex. 60s, 5m) et --expect-event-within <dur> (surveillance du silence ; en l’absence d’événement dans le délai, déclenche plutôt un événement de cycle de vie, minimum 5 min, p. ex. 24h). Un moniteur est une commande du dépôt que la plateforme exécute 24 h/24, et chaque ligne de sortie standard déclenche l’événement. Cette fonctionnalité est expérimentale : la plateforme n’exécute les moniteurs que lorsque le flag de fonctionnalité monitors est activé.

Accès

L’interface CLI de la table unique des autorisations. Chaque ligne est une attribution : un principal, un rôle, une portée, éventuellement limitée à un objet. Voir Comptes et accès pour le modèle. Rôles de compte : owner, admin, member. Rôles de projet : manager, member.

Options d’autorisation : --project <id> (par défaut : le projet associé), --account (tout le compte), --agent <name> (limite l’autorisation à un agent — attribution à un objet), --connection <id> (limite l’utilisation d’un compte de connecteur partagé ; la première autorisation réserve le compte à ses bénéficiaires, et la révocation de la dernière le rend de nouveau accessible à tout le projet), --everyone (accorde l’accès à toutes les personnes ayant accès au projet ; cette option attend un --agent ou un --connection, jamais un rôle) et --expires <iso> (horodatage de révocation automatique). --principal filtre une liste et accepte user:<id>, group:<id>, service_account:<id>, project:<id> ou pending:<email> ; un identifiant seul est interprété comme celui d’un utilisateur. Une autorisation accordée à tout le monde apparaît sous la forme everyone. L’identité d’un agent est un service_account ; --service-account <id> permet donc d’attribuer un rôle à un agent. --user accepte une adresse e-mail et la résout à l’aide de l’annuaire des membres du compte.

beeuni access grant --user alice@corp.com --role manager
beeuni access grant --user alice@corp.com --role admin --account
beeuni access grant --group 8f3c… --role member --project 1a2b…
beeuni access grant --user alice@corp.com --agent support-bot
beeuni access grant --everyone --agent support-bot
beeuni access grant --group 8f3c… --connection 2b7e…
beeuni access revoke 4d5e…

Les verbes de membre du projet sont une vue de lecture des mêmes attributions :

Chaque verbe des deux blocs ci-dessus nécessite project.members.manage.

Une personne, un groupe ou un agent reçoit des rôles de Beeuni ; un agent possède également des permissions Beeuni dans beeuni.yaml, et une session ne peut faire que ce que les deux autorisent. Voir Un vocabulaire, deux liaisons.

Audit

Les commandes d’audit lisent le journal centralisé de reconstruction. Les listes de comptes et de projets sont triées de la plus récente à la plus ancienne. La chronologie d’une session est ordonnée par heure de création (session_sequence n’est défini que sur les lignes écrites avant 2026-10, qui apparaissent en premier). --all suit chaque curseur de continuation. ls répertorie les 90 derniers jours ; export remonte jusqu’à 365 jours, et les événements de plus de 90 jours proviennent des archives (voir Conservation des audits). Le tableau affiche le titre de chaque ligne (EVENT, par exemple « Clé de passerelle LLM révoquée ») à côté de son ACTION (gateway.key.revoke) ; --action filtre par préfixe d’action. Toutes les actions et tous les titres : Actions du journal d’audit.

Les webhooks d’audit transmettent la piste à un SIEM. Chaque verbe nécessite account.write ; add et enable nécessitent également le droit d’accès Enterprise. disable et rm ne le nécessitent jamais.

Filtres : --actor, --actor-type, --project, --session, --source, --phase, --outcome, --action, --resource-type, --request-id, --correlation-id, --query, --since, --until, --cursor et --limit. Les listes et les exports de comptes nécessitent audit.read et le droit d’accès auditAccess du compte. Les listes de l’ensemble du projet nécessitent project.members.manage, car elles peuvent inclure des métadonnées de sessions privées. La reconstitution d’une session nécessite project.session.read et la visibilité de cette session.

Rôles

Un rôle est un ensemble nommé de permissions. Les rôles système (owner, admin, member au niveau du compte ; manager, member au niveau du projet ; ainsi que agent-user, le marqueur porté par une attribution d’objet) sont des références en lecture seule. Vous pouvez créer et modifier vos rôles personnalisés, qui nécessitent le droit d’accès Enterprise rbac.

Associez un rôle à un principal avec beeuni access grant. Les anciens verbes beeuni roles assign / unassign / assignments fonctionnent toujours et écrivent dans la même table, mais beeuni access est la méthode documentée. beeuni roles actions est remplacé par beeuni permissions ls.

Un rôle personnalisé ne fait qu’ajouter des permissions. Beeuni ne dispose d’aucune règle de refus : un rôle ne peut donc pas retirer une permission à un gestionnaire.

Permissions

Le catalogue des permissions, sous forme de données. Une ligne par action terminale, avec la portée à laquelle elle est évaluée, son caractère délégable et les permissions qu’elle implique. Les rôles sont construits à partir de ces clés — beeuni roles create --actions et beeuni roles set-actions les utilisent exactement. Alias : beeuni perms.

Attributions

Attribue un objet de projet à un principal — une attribution d’objet. Les secrets et les connecteurs résident sur les agents ; attribuer un agent à une personne lui accorde donc tout ce que cet agent déclare. Par défaut, un agent est fermé : un membre ne peut y accéder que si une attribution le désigne ou désigne l’un de ses groupes. beeuni access grant --agent <name> écrit dans la même ligne.

Validation du manifeste

Voir Référence du manifeste.

Taille du dépôt

Une session construit sa configuration d’agent à partir de tous les fichiers suivis par Git au commit de base. Une nouvelle session récupère ces fichiers depuis sa propre copie de travail, quelle que soit leur taille. Une session en cours prend en compte les modifications de la branche de base via l’instantané du projet, que Beeuni Cloud génère jusqu’à 512 MiB compressés ; au-delà, la session conserve sa configuration en cours jusqu’au démarrage d’une nouvelle session. Chaque session télécharge également tous les fichiers. beeuni validate compte les fichiers stockés par Git, ainsi que les fichiers non suivis que beeuni ship ajoute ensuite, et affiche un avertissement lorsqu’un fichier atteint 10 MiB ou plus, ou que le total dépasse 512 MiB. Un fichier Git LFS est compté comme son pointeur, car la version ne contient que le pointeur. L’avertissement indique les fichiers les plus volumineux. La commande n’échoue jamais.

Pour supprimer l’avertissement :

• Déplacez les ressources statiques volumineuses (vidéos, images, jeux de données, poids de modèles) vers un stockage objet comme S3, R2 ou GCS, ou vers un CDN, et téléchargez-les au moment de l’exécution.
• Ajoutez les fichiers générés lors de la compilation (dist/, out/) à .gitignore.
• Pour un chemin qui doit rester dans Git mais qu’aucun agent ne lit, ajoutez <path> export-ignore à .gitattributes. La version le laisse de côté, tout comme la vérification ; une règle de répertoire s’applique à tout son contenu. Le répertoire de configuration de l’agent et beeuni.yaml sont toujours inclus en entier.

Portée des jetons

Chaque jeton commence par beeuni_pat_. Un jeton utilisateur s’applique à tous les projets de vos comptes. Un jeton de projet s’applique à un seul projet et est injecté automatiquement dans les environnements de test de ce projet. Consultez la référence complète des familles de jetons dans Session runtime.

Codes de sortie