CLI

Die Beeuni-Befehlszeile, ihr Authentifizierungsmodell, der Entwicklungszyklus und alle Befehle.

Die beeuni-Befehlszeilenschnittstelle (CLI) steuert Beeuni über ein Terminal – auf deinem Laptop oder in einer Sitzungssandbox. Diese Seite zeigt den üblichen Entwicklungsablauf und listet anschließend alle stabilen Befehle und Flags auf.

Installation

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

Das Installationsprogramm lädt eine vorgefertigte Binärdatei für macOS und Linux herunter. Windows wird nicht unterstützt.

Authentifizierungsmodell

Beeuni speichert die Authentifizierung pro Host, nicht global. Ein Host ist ein Beeuni-API-Endpunkt. Verwende cloud, um dich mit Beeuni zu verbinden.

Die Konfigurationsdatei befindet sich unter ~/.config/beeuni/config.json, Modus 0600. Überschreibe den Pfad mit BEEUNI_CONFIG_FILE.

Die CLI folgt einer Hierarchie: Host → Konto → Projekt → Sitzung. Du meldest dich bei einem Host an, wählst darin ein Konto, dann ein Projekt in diesem Konto und öffnest Sitzungen im Projekt. beeuni hosts login durchläuft die ersten drei Schritte der Reihe nach: Es meldet dich an, wählt das Konto und legt anschließend ein Standardprojekt fest.

Jedes Token beginnt mit beeuni_pat_. Ein Benutzertoken von beeuni login sieht alle Konten und Projekte, denen du angehörst. Ein Projekttoken wird automatisch für eine Sitzungssandbox erstellt und ist auf ein Projekt beschränkt. Siehe Tokenumfang.

Der Entwicklungsablauf

Dieser Ablauf setzt voraus, dass die CLI installiert ist und du beeuni login ausgeführt hast. Eine Anleitung zur Einrichtung findest du unter Schnellstart.

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

Referenz

Authentifizierungsbefehle

beeuni hosts login / hosts logout / hosts whoami sind die kanonischen Formen. login / logout / whoami sind Kurzformen, die für den aktiven Host gelten.

Hosts

Eine URL eines Remote-Hosts, die mit http:// beginnt, wird zu https:// normalisiert. Die CLI sendet niemals ein Token über unverschlüsseltes HTTP an einen Remote-Host. localhost ist davon ausgenommen.

Konten

Mitglieder

Wer gehört zum Konto und mit welcher Kontorolle? Die Rollen sind owner, admin und member. Inhaber und Administratoren haben implizit die Rolle „Manager“ für jedes Projekt. Daher ist member die einzige Rolle, für die projektbezogene Berechtigungen vergeben werden.

Eine <user> ist eine Benutzer-ID oder die E-Mail-Adresse einer Person, die bereits zum Konto gehört. Optionen: --account <id>, --host <name>, --json, -y.

Gruppen

Eine Kontengruppe ist eine benannte Gruppe von Personen, denen Sie einmalig eine Rolle zuweisen. Binden Sie eine Gruppe mit beeuni access grant --group <id> --role <key> an einen Bereich; widerrufen Sie die Bindung mit beeuni access revoke <assignment-id>.

Ein <group> ist eine Gruppen-ID oder der exakte Name der Gruppe. Für Lesezugriffe ist group.read erforderlich. create, set und add erfordern group.update oder group.members.manage sowie die Enterprise-Entitlement rbac. rm und remove dienen der Bereinigung und sind nie durch Entitlements eingeschränkt.

Tokens

Nicht-interaktive Zugangsdaten für das Konto. Für Lesezugriffe ist token.read erforderlich. Jedes Kontomitglied kann eigene persönliche Schlüssel ausstellen und widerrufen (token.personal.create, token.personal.revoke); ein persönlicher Schlüssel handelt in Ihrem Namen und verfügt nie über mehr als Ihre eigenen Rollen. Dienstkonten und die Schlüssel anderer Personen erfordern token.create / token.revoke (Eigentümer und Administrator).

Ein persönlicher API-Schlüssel handelt in Ihrem Namen und erlischt mit Ihrer Mitgliedschaft. Ein Dienstkonto handelt als es selbst und erbt keinen Zugriff: Ein neues Dienstkonto hat keine Berechtigungen. Gewähren Sie ihm mit beeuni access grant --service-account <id> --role <key> eine Berechtigung. --expires <when> akzeptiert ISO-8601 oder einen Zeitraum ab jetzt: 30d, 12h, 6w, 1y.

Abrechnung

Plan, Credits und Ausgaben des aktiven Kontos anzeigen. Nur lesend: Planänderungen, Aufladungen und Zahlungsmethoden werden im Dashboard verwaltet.

Filter: --project <id>, --session <id> und --owner <id> (Sitzungen, mit --by session). Optionen: --account <id>, --host <name>, --json.

Projekte

Ein Befehl ermittelt „das Projekt“ in dieser Reihenfolge:

1. Das Flag --project.
2. Die Umgebungsvariable BEEUNI_PROJECT_ID.
3. .beeuni/link.json im aktuellen Arbeitsverzeichnis.
4. Der mit beeuni projects use festgelegte globale Standard.

Ein Projekt zeigt ein einziges Symbol. Daher entfernt das Schreiben von --icon das Glyph, und das Schreiben von --glyph entfernt das Emoji; die Übergabe beider Werte wird abgelehnt. Glyph-Farben: grey, red, orange, yellow, lime, blue, purple, magenta. set und features erfordern project.settings.write. Ein von der Plattform als nicht verfügbar markiertes Flag bleibt unabhängig von der Projektüberschreibung deaktiviert.

Ein CLI-Token des Projekts ist an ein einziges Projekt gebunden — die API lehnt ihn überall sonst ab. Eine Sitzungssandbox verwendet ihr sitzungsgebundenes BEEUNI_TOKEN. cli-tokens ls erfordert Leserechte für das Projekt; new und rm erfordern project.credentials.issue. Ein sitzungsgebundener Token kann weder Projekt-Tokens ausstellen noch widerrufen (403), unabhängig davon, ob im Projekt Agents deklariert sind. Ein CLI-Token des Projekts folgt der PAT-Richtlinie des Kontos: Wenn das Konto ein Ablaufdatum erfordert, übergeben Sie --expires-at; ein Ablaufdatum jenseits der maximalen Lebensdauer führt zu 400.

beeuni projects upgrade erfordert Schreibrechte für das Projekt. Der Standard-Agent aktualisiert die Marketplace-Baseline, schreibt das Manifest neu, führt beeuni validate aus und öffnet einen Änderungsantrag. Er führt niemals einen Merge durch: Ein Mensch prüft die Änderungen.

Projektgerüst

beeuni init [project-name] [options] erstellt ein neues Projektverzeichnis. Das Starterpaket schreibt ein v2-beeuni.yaml, agents/, skills/, memory/ und harnesses/opencode/. Der Befehl kann die lokale Erkennung von Coding-Tools einrichten, ohne die Standard-Agent-Laufzeit zu ändern. Der Befehl schreibt .beeuni/link.json nicht. beeuni ship oder beeuni projects link erstellen diese Datei.

Die Auswahl des lokalen Coding-Tools ändert die Standard-Agent-Laufzeit nicht.

beeuni init enthält keine Marketplace-Auswahl. Das Hinzufügen eines Marketplace-Skills ist ein Agentenimport: Starten Sie eine Sitzung und bitten Sie den Agenten, einen Skill zu importieren.

Bereitstellen

beeuni ship stellt Ihren aktuellen Branch bereit, führt einen Commit durch und überträgt ihn in das Git-Repository des Projekts. Führen Sie den Befehl einmal aus, um das Projekt zu erstellen. Führen Sie ihn jederzeit erneut aus, um zu synchronisieren. Alias: beeuni deploy.

Jeder Durchlauf:

• Führt die Prüfungen beeuni validate aus: beeuni.yaml zusammengeführt mit jeder Datei, die es unter imports: auflistet, Sandbox-Dockerfiles, Agent-Verdrahtung und Repository-Größe (mit --no-verify überspringen). Ein Fehler verhindert den Ship. Eine Warnung niemals.
• Committet Änderungen im Arbeitsbaum (mit --no-commit überspringen).
• Fragt nach allen fehlenden env-Secrets (mit --no-env überspringen).
• Pusht den aktuellen Branch in den gleichnamigen Remote-Branch.
• Verbindet alle deklarierten Connectoren, für die noch eine Authentifizierung erforderlich ist (mit --no-connect überspringen).

Ein vorhandener GitHub-origin wird über die Beeuni GitHub App verknüpft. Jedes andere vorhandene origin wird unverändert registriert. Ohne origin wird ein verwaltetes Beeuni-Git-Repository erstellt.

Apps

Apps hosten statische Websites, Server, Worker und Datenbanken. Jede App hat eine feste URL. Ein Release enthält Code und Konfiguration; ein fehlgeschlagenes Deployment ersetzt das aktive Release nicht.

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

Verbinde Apps mit uses und den Beispielen aus beeuni apps connect. Keine administrativen Zugangsdaten im Client-Code speichern.

Laufende Ressourcen verbrauchen Kontoguthaben. Billing und Usage zeigen Guthaben und Verbrauch. Apps haben kein separates Monatsbudget.

Apps

Sessions

Jede Session läuft in einer eigenen Sandbox auf ihrem eigenen Branch.

sessions queue erfordert project.session.start – dieselbe Berechtigung wie zum Senden einer Nachricht. Ein eingereihter Prompt bleibt auch nach dem Schließen des Terminals bestehen und wird zugestellt, sobald die Sitzung ihn entgegennehmen kann. Füge einen mit beeuni sessions chat <id> -p "…" --queue hinzu oder lenke den laufenden Durchlauf mit --steer. sessions queue ls zeigt für jeden Prompt seinen DELIVERY (steer, queue oder interrupt) und bei einem Steuerungs-Prompt, der als queue ausgeführt wird, den Grund: unsupported (die Sitzung kann während eines Durchlaufs keine Nachrichten entgegennehmen), not_prompter (der Durchlauf eines anderen Mitglieds läuft) oder turn_ended.

sessions approvals sind dauerhaft: Anders als sessions pending überstehen sie einen Neustart der Sandbox. Erfordert project.members.manage oder die Rolle als Mensch, der die Sitzung gestartet hat. Ein Agent kann niemals seine eigene Freigabe erteilen.

sessions attachments liest den privaten Dateispeicher der Sitzung, nicht ihren Arbeitsbereich. Dateien werden beim Senden dort abgelegt; alle Dateien, die der Agent angezeigt hat, werden am Ende des Durchlaufs dort abgelegt.

sessions files liest den Arbeitsbaum, den der Agent gerade bearbeitet, bevor Änderungen übernommen werden; beeuni files liest stattdessen das übernommene Repository. Pfade werden relativ zu /workspace aufgelöst, sofern sie nicht mit /workspace, /tmp, /home oder /opt beginnen. Der Befehl weckt die Sandbox auf, wenn sie inaktiv ist. Optionen: --from <local path> (write liest diese Datei statt von stdin), --content (find durchsucht Inhalte mit ripgrep statt Dateinamen), --limit <N> (find Dateinamenlimit) und -y, um die Bestätigung für rm zu überspringen.

sessions share unterliegt der Kontrolle des Eigentümers: Die API lehnt einen Projektmanager ab, der die Sitzung nicht bereits lesen kann. Eine geteilte Sitzung wird nur mit Anbieterschlüsseln ausgeführt, die für das gesamte Projekt freigegeben sind: Ein Modell, das mit deinen eigenen Schlüsseln ausgeführt wurde, wechselt für diesen Anbieter zu den Projektschlüsseln. Wenn kein solcher Schlüssel vorhanden ist, wird die Freigabe abgelehnt (409 SHARED_SESSION_NEEDS_PROJECT_KEY).

Optionen für sessions links create: --port <n> (Standard: 3000; 22, 8000 und die opencode-Ports werden abgelehnt), --path <p> (Standard: /), --preview <id> (ein benannter Kandidat – web, vite, dev-server, api-docs – statt --port/--path), --file <path> (gibt eine Datei aus dem Arbeitsbereich statt einer Vorschau frei; immer schreibgeschützt), --mode view\|interactive (Standard: view; interactive erlaubt Schreibzugriffe und WebSockets und wird für --file ignoriert), --label <text> und --expires <iso>. Zum Erstellen eines Links ist der Sitzungseigentümer erforderlich, da der Link selbst keine Anmeldung erfordert. Für das Auflisten und Widerrufen genügt auch ein Projektmanager.

Innerhalb einer Sandbox ist BEEUNI_SESSION_ID die ID deiner eigenen Sitzung.

Änderungsanfragen

Eine Änderungsanfrage (CR) führt einen Branch auf einem beliebigen Git-Host in einen anderen zusammen. Sie ist der einzige Weg, wie ein Agent Sitzungsänderungen in den Standard-Branch übernehmen kann. Siehe Änderungsanfragen.

request-changes speichert die Anmerkung in der CR und übermittelt sie an die Ursprungssitzung, wobei deren Sandbox gestartet wird, falls sie inaktiv ist. Erfordert project.review.act – dasselbe Berechtigungs-Leaf wie im Review Center, nicht gitops.push.

<cr> akzeptiert eine projektspezifische Nummer (3) oder die vollständige ID. Innerhalb einer Sandbox liest die CLI das Token automatisch aus – keine Anmeldung oder kein Link erforderlich.

Überprüfung

Der Prüfungseingang des Projekts – alles, was auf eine menschliche Entscheidung wartet: Änderungsanfragen, Connector-Tool-Aufrufe, die eine Richtlinie zur Genehmigung gesperrt hat, sowie Ausgaben, Entscheidungen und Batches, die Agenten zur Freigabe einreichen. Entspricht dem Review Center des Dashboards. Für jedes Projekt aktiviert; project.review.read und project.review.act regeln das Lesen und Handeln.

Urteile: approve, reject, changes, answer, dismiss. Segmente: needs_you, waiting, done. Arten: change, approval, output, decision, batch.

Welche Wirkung ein Urteil hat, hängt von der Element-ID ab. Bei cr:<id> führt approve die Änderung zusammen, reject schließt sie, und changes sendet die Anmerkung an den Agenten zurück, der sie geöffnet hat (erfordert --message). Bei call:<id> erlaubt approve den Tool-Aufruf, und reject lehnt ihn ab; für eine Connector-Freigabe gibt es keine anderen Urteile – prüfe zuerst die Argumente mit beeuni review show. Bei allen anderen IDs wird der native Aktionsendpunkt verwendet, der jedes Urteil akzeptiert.

bulk wirkt nur auf native IDs. Eine Connector-Freigabe erfordert eine eigene Prüfung der Parameter, und bei einer Änderungsanfrage muss der Diff angezeigt werden. Beide werden daher gemeldet und übersprungen – dieselbe Regel wie bei der Mehrfachauswahl im Dashboard.

Optionen für submit: --kind output\|decision\|batch (erforderlich), --title <text> (erforderlich), --summary <text>, --risk none\|low\|medium\|high (Standardwert none), --detail <json> (ein JSON-Objekt), --agent <name> und --session <id> (wird ignoriert, wenn es nicht die Sitzung dieses Projekts ist).

Zum Lesen wird project.review.read benötigt, für Urteile project.review.act und submit erfordert project.review.submit.

Geheimnisse

Verschlüsselte Werte, die im Projekt gespeichert sind. Standardmäßig wird ein Secret beim Start als einfache Umgebungsvariable in jede Session-Sandbox injiziert (Umgebungsexposition). Die erzwungene Bereitstellung — bei der die Sandbox ein Handle enthält und Beeuni den tatsächlichen Wert außerhalb der Sandbox einsetzt (erzwungene Exposition beim Egress und beeuni secrets call) — ist experimentell. Aktiviere das Feature-Flag secrets_egress (Settings → Feature flags), um es zu verwenden; ist das Flag deaktiviert, gibt beeuni secrets delivery … egress 403 feature_disabled zurück. Siehe Secrets.

grant behebt eine Zeile, die ls als nicht zustellbar meldet. Der Befehl erweitert nur die Liste eines einzelnen Agenten; um sie einzuschränken oder zu ersetzen, schreibe die gesamte Menge mit beeuni agents scope. There is no secrets revoke neu — die API bietet keine Route, um eine einzelne Kennung aus einer Freigabe zu entfernen. Die erste Freigabe in einem Projekt ohne Agents startet die Governance: Ab dann erhält ein Agent, der nicht im Manifest aufgeführt ist, keine Projekt-Secrets, und der Befehl weist darauf hin, wenn das passiert.

Env

Agents

Modellkonfigurationen pro Agent im verknüpften Projekt.

Jede Scope-Option ersetzt den bisherigen Wert; keine führt Werte zusammen. Ein Wert für --set wird als JSON geparst, wenn das möglich ist, andernfalls als String übernommen. Modellanheftungen und scope werden sofort angewendet, ohne einen beeuni.yaml-Commit; default und config committen nach beeuni.yaml auf dem Standard-Branch des Projekts. Für scope wird project.agent.write benötigt, ebenso für default und config.

Tools

Die Tools, die den Sessions dieses Projekts zur Verfügung stehen. Sie werden aus der lokalen beeuni.yaml und deren Imports gelesen. Im Stammverzeichnis des Projekts ausführen. Siehe Tools.

Ohne Schlüssel tools: erhält jede Session alle fünf Beeuni-Tools (web_search, image_search, scrape_webpage, memory, show). Mit einem Schlüssel tools: erhalten Sessions nur die darin aufgeführten Beeuni-Tools. Um ein Beeuni-Tool zu entfernen, lösche seine Zeile unter tools: und führe dann beeuni validate aus. Um die Tools eines einzelnen Agenten einzuschränken, verwende agents.<name>.tools. Exitcodes: 0 abgeschlossen, 1 abgelehnt (eine Datei ist vorhanden oder ein Manifest oder Import lässt sich nicht parsen), 2 kein Manifest, eine unbekannte Option oder ein Name, der kein Beeuni-Tool ist.

Models

Welche Modelle das Projekt anbietet und mit welchem es startet. Dieselbe Ansicht wie unter Customize → Models im Dashboard. Ein Projekt speichert nur seine Abweichungen vom Katalogstandard (das neueste Modell jeder Familie). Die Aktivierung dient nur der Anzeige: Sie bestimmt, welche Optionen in Auswahlfeldern erscheinen, nicht, welche Modelle das Gateway bereitstellt.

Modell-IDs sind Gateway-Wire-IDs — eine einfache verwaltete ID (glm-5.3-flash) oder eine BYOK-provider/model. Eine ID kann aus beeuni models ls --json kopiert werden. Anheftungen pro Agent finden sich unter beeuni agents model <agent> <model-id>. Für Schreibvorgänge wird project.model.write benötigt.

Channels

Verwaltet die Verbindung des Projekts zu einer Chatplattform. Tokens werden verschlüsselt in den Secrets des Projekts gespeichert und serverseitig aufgelöst — sie werden niemals in die Sandbox injiziert.

--platform slack|teams wählt die Plattform aus; Standard: slack. Teams connect gibt die URL für die Microsoft-Administratorzustimmung aus. Wird die Zustimmung für den gesamten Mandanten erteilt, wird die App automatisch im Teams-Katalog veröffentlicht. Siehe Connectors.

Der E-Mail-Kanal basiert auf AgentMail und benötigt das Feature-Flag agentmail_email. email connect-Optionen: --connector <slug> (Standard: beeuni_email), --api-key <k> (eigenen AgentMail-Schlüssel verwenden; - liest von stdin), --display-name <n> (Absendername für ausgehende E-Mails; standardmäßig der Projektname), --username <u> und --domain <d> (neues verwaltetes Postfach) sowie --inbox-id <id> mit --email <addr> (vorhandenes Postfach verbinden – beide sind zusammen erforderlich). --allow kann wiederholt angegeben werden und versetzt die Richtlinie in den eingeschränkten Modus. Ein Wert ohne @ oder ein Wert mit vorangestelltem @ wird als Domain interpretiert. --allow-all leert die Liste und lässt wieder alle Absender zu.

E-Mails und bind-Schreibvorgänge benötigen project.connector.write.

Connectors

Connectors, die ein Agent als Tools aufruft. add, rm und policy set bearbeiten die lokale beeuni.yaml. Führe beeuni ship aus, um die Änderungen anzuwenden, es sei denn, du übergibst --apply, um das Cloud-Projekt sofort zu ändern.

policy ls, show, set, add und rm bezeichnen die projektweite Oberfläche. Ein Connector, dessen Name einem dieser Verben entspricht, muss daher als policy <slug> ls angesprochen werden. Ein <match> ist ein Toolname, ein Glob-Muster (send_*) oder ein /regex/.

Optionen für 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.

Sandboxes

Verwaltet die Sandbox-Images des Projekts. Eine Vorlage definiert ein Image oder Dockerfile sowie Ressourcen; ein Build erstellt den Snapshot, von dem Sitzungen starten.

Einen Provider festzulegen erfordert project.settings.write.

Optionen für add/update: --name <label>, --cpu <n>, --memory <n> (GiB), --disk <n> (GiB).

Backends

Datenbanken sind Apps mit persistenten Volumes. Verwalte und verbinde sie über Apps.

Apps

Marketplace

Durchsuche den Beeuni-Marktplatz und installiere ein Element in einem Projekt.

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

Die Installation wird vom Agenten ausgeführt: Sie startet eine Projektsitzung, die das Element klont, es liest, passende Inhalte zusammenführt und einen Änderungsvorschlag öffnet. Es gibt keine Mechanismen zur deterministischen Installation, Aktualisierung oder Entfernung.

System-Skills

Die Beeuni-System-Skills sind die betriebliche Referenz der Plattform für Menschen und Agenten. Sie behandeln Sitzungen, Sandboxes, die Standard-Agent-Laufzeit, Connectors, Speicher und Channels. Diese öffentliche Seite ist der Einstiegspunkt; die authentifizierte CLI liest die Skills vom laufenden Host. Verwende beeuni system-skills list, um die verfügbaren Skills zu finden, und dann get für den benötigten Skill. Die API stellt sie live bereit, sodass sie der Version des bereitgestellten Hosts entsprechen. Eine lokale Kopie ist nicht unbedingt aktuell.

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

beeuni skills ist ein dauerhafter Alias für denselben Befehl. Melde dich zuerst mit beeuni login beim Host an; die Skills-API erfordert eine Authentifizierung. Verwende --host <name>, wenn du mit einem anderen Host arbeitest. Eine öffentliche Dokumentationsseite kann diese aktuellen, host-spezifischen Anweisungen nicht ersetzen.

Diese Liste enthält immer nur die System-Skills, keine Mischung. Optionale Skills findest du im Marktplatz: beeuni marketplace list --type skill. Die Befehlssyntax findest du unter beeuni <command> --help; die vollständige Plattformreferenz steht in beeuni system-skills get beeuni-system --full.

Connector

Die Schnittstelle des Agenten in der Sandbox zu allen Connectors. Jeder Aufruf wird serverseitig geprüft, aufgelöst und protokolliert; die CLI speichert keine Zugangsdaten von Drittanbietern. Authentifizierung: BEEUNI_TOKEN. Ausgabe im JSON-Format.

Dateien

Schreibgeschützte Ansicht des Git-Repositorys des Projekts. Verwendet den Standard-Branch, sofern --ref keinen anderen Branch, Tag oder Commit angibt.

Optionen für alle Unterbefehle: --ref <ref>, --path <p>, --limit <n>, --json. download akzeptiert außerdem -o, --out <file>, das erforderlich ist.

Für jeden Unterbefehl ist project.file.read erforderlich. download lehnt außerdem jeden Teilbaum ab, der einen Agenten oder Skill enthält, für den du keine Berechtigung hast — ein ZIP-Archiv lässt sich während des Streamings nicht filtern. Archiviere in diesem Fall einen enger gefassten --path.

Auslöser

Ein Auslöser startet eine Sitzung nach Zeitplan, über einen Webhook, durch ein App-Ereignis oder über einen Monitor (experimentell). add, rm, enable, disable bearbeiten das lokale Manifest — führe beeuni ship aus, um die Änderungen anzuwenden. pause/resume schalten einen separaten serverseitigen Schalter um. Siehe Auslöser.

Optionen für add: --type <cron\|webhook\|event\|monitor> (Standard: cron), --prompt <text> (erforderlich), --agent <name>, --cron <expr> (6 Felder, z. B. "0 0 9 * * 1-5"), --run-at <iso> (einmalig zu diesem Zeitpunkt statt nach einem Cron-Zeitplan ausführen), --timezone <tz> (Standard: UTC), --secret-env <NAME>, --name <label>, --disabled.

Nur für aktive Auslöser verfügbare Optionen — gültig für add --apply und alle set: --model <provider/model>, --session-mode <fresh\|keyed\|pinned\|reuse>, --session-key <tmpl> (eine Sitzung pro Schlüssel gruppieren, z. B. "{{ body.data.chat_jid }}"; setzt keyed voraus), --session-id <id> (die Sitzung, in der ein pinned-Auslöser wiederholt ausgeführt wird; muss eine Sitzung dieses Projekts sein), --session-access <private\|project\|members> (Standard: private), --member <uuid> und --group <uuid> (wiederholbar; jede Option setzt members voraus) sowie --filter <path=value> (wiederholbar; jede Angabe muss übereinstimmen, z. B. --filter body.type=push).

set akzeptiert alle nur für aktive Auslöser verfügbaren Optionen sowie --name, --prompt, --cron, --run-at, --timezone, --secret-env, --agent und --enabled true|false. --cron und --run-at schließen sich gegenseitig aus: Wenn eine gesetzt wird, wird die andere gelöscht. Monitorfelder können nur hinzugefügt werden.

Erinnerungen

Eine Erinnerung fordert eine Sitzung später erneut zur Eingabe auf, einmalig oder wiederholt. Sie wird in der Datenbank gespeichert, nicht in beeuni.yaml. Innerhalb einer Sitzung ist der Standardwert für --session $BEEUNI_SESSION_ID. Siehe Erinnerungen.

Zeitplanoptionen: --in <duration> oder --at <iso> (erste Ausführung; allein verwendet, wird einmalig ausgeführt), --every <duration> (Wiederholung, mindestens 5m), --cron "<expr>" mit --timezone <tz>. Weitere Optionen: --name <label>, --session <id> (ein eindeutiges Präfix genügt), --project <id>, --host <name>, --json.

Ereignisoptionen (--type event): --connector <slug> und --event <TYPE> (beide erforderlich), --config key=value (wiederholbar, Zeichenfolgenwerte) und --config-json '{...}' (typisierte Werte). set akzeptiert dieselben Flags. Ein Ereignisauslöser lehnt --cron, --run-at, --timezone, --secret-env und die Monitoroptionen ab. Die Eingabeaufforderung liest {{ event.data.<field> }}; siehe App-Ereignisauslöser.

Monitoroptionen (--type monitor): --run <cmd> (relativer Repository-Pfad zum zu überwachenden Befehl; erforderlich), --mode <poll\|stream> (erforderlich; poll führt bei --interval erneut aus, stream hält den Befehl am Laufen), --interval <dur> (nur mode=poll, mindestens 30 s, z. B. 60s, 5m) und --expect-event-within <dur> (Leerlaufüberwachung; wenn innerhalb des Zeitfensters kein Ereignis eintritt, wird stattdessen ein Lebenszyklusereignis ausgelöst; mindestens 5 min, z. B. 24h). Ein Monitor ist ein Repository-Befehl, den die Plattform rund um die Uhr ausführt; jede stdout-Zeile löst den Auslöser aus. Die Funktion ist experimentell: Die Plattform führt Monitore nur dort aus, wo das Feature-Flag monitors aktiviert ist.

Zugriff

Die CLI-Oberfläche für die zentrale Berechtigungstabelle. Jede Zeile ist eine Zuweisung: ein Prinzipal, eine Rolle, ein Geltungsbereich, optional auf ein Objekt eingeschränkt. Siehe Konten und Zugriff für das Modell. Kontorollen: owner, admin, member. Projektrollen: manager, member.

Optionen für Berechtigungen: --project <id> (Standard: das verknüpfte Projekt), --account (das gesamte Konto), --agent <name> (Berechtigung auf einen Agenten beschränken — eine Objektzuweisung), --connection <id> (Nutzung eines gemeinsam genutzten Connector-Kontos beschränken; die erste Zuweisung beschränkt das Konto auf seine Berechtigungsempfänger, und durch den Widerruf der letzten Zuweisung wird es wieder für das gesamte Projekt freigegeben), --everyone (allen mit Zugriff auf das Projekt Berechtigungen erteilen; der Eintrag enthält --agent oder --connection, niemals eine Rolle) und --expires <iso> (Zeitstempel für den automatischen Widerruf). --principal filtert eine Liste und akzeptiert user:<id>, group:<id>, service_account:<id>, project:<id> oder pending:<email>; eine allein angegebene ID wird als Benutzer interpretiert. Eine Zuweisung an alle wird als everyone angezeigt. Die Identität eines Agenten ist ein service_account; mit --service-account <id> weist du einem Agenten eine Rolle zu. --user akzeptiert eine E-Mail-Adresse und löst sie über das Mitgliederverzeichnis des Kontos auf.

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…

Die Verben für Projektmitglieder sind eine Lesesicht auf dieselben Zuweisungen:

Jedes Verb in den beiden obigen Blöcken benötigt project.members.manage.

Eine Person, eine Gruppe oder ein Agent erhält Rollen von Beeuni; ein Agent trägt zusätzlich Beeuni-Berechtigungen in beeuni.yaml, und eine Sitzung kann nur das tun, was beide erlauben. Siehe Ein Vokabular, zwei Bindungen.

Audit

Die Audit-Befehle lesen das zentrale Rekonstruktionsprotokoll. Konto- und Projektlisten werden in absteigender Aktualitätsreihenfolge ausgegeben. Eine Sitzungschronik ist nach Erstellungszeit geordnet (session_sequence ist nur bei Zeilen gesetzt, die vor 2026-10 geschrieben wurden; diese werden zuerst angezeigt). --all folgt jedem Fortsetzungs-Cursor. ls listet die letzten 90 Tage auf; export reicht 365 Tage zurück, und Ereignisse, die älter als 90 Tage sind, stammen aus dem Archiv (siehe Aufbewahrung des Audit-Protokolls). Die Tabelle zeigt den Titel jeder Zeile (zum Beispiel EVENT „LLM-Gateway-Schlüssel widerrufen“) neben ihrem ACTION (gateway.key.revoke); --action filtert nach dem Aktionspräfix. Alle Aktionen und Titel: Aktionen im Audit-Protokoll.

Audit-Webhooks streamen den Verlauf an ein SIEM. Jedes Verb benötigt account.write; add und enable benötigen außerdem die Enterprise-Berechtigung. disable und rm tun dies niemals.

Filter: --actor, --actor-type, --project, --session, --source, --phase, --outcome, --action, --resource-type, --request-id, --correlation-id, --query, --since, --until, --cursor und --limit. Kontolisten und Exporte erfordern audit.read und die auditAccess-Berechtigung des Kontos. Projektweite Listen erfordern project.members.manage, da sie Metadaten privater Sitzungen enthalten können. Die Rekonstruktion einer Sitzung erfordert project.session.read sowie Sichtbarkeit für diese Sitzung.

Rollen

Eine Rolle ist eine benannte Gruppe von Berechtigungen. Systemrollen (owner, admin, member auf Kontoebene; manager, member auf Projektebene; außerdem agent-user, das Kennzeichen, das eine Objektzuweisung trägt) sind schreibgeschützte Verweise. Benutzerdefinierte Rollen können Sie selbst erstellen und bearbeiten und benötigen die Enterprise-rbac-Berechtigung.

Binden Sie eine Rolle mit beeuni access grant an einen Principal. Die älteren Verben beeuni roles assign / unassign / assignments funktionieren weiterhin und schreiben in dieselbe Tabelle, aber beeuni access ist der dokumentierte Weg. beeuni roles actions wurde durch beeuni permissions ls abgelöst.

Eine benutzerdefinierte Rolle fügt nur Berechtigungen hinzu. Beeuni kennt keine Verweigerungsregel, daher kann eine Rolle einem Manager keine Berechtigung entziehen.

Berechtigungen

Der Berechtigungskatalog als Daten. Eine Zeile pro Blattaktion, mit dem Geltungsbereich, in dem sie entschieden wird, ob sie delegierbar ist und was sie impliziert. Rollen werden aus diesen Schlüsseln erstellt — beeuni roles create --actions und beeuni roles set-actions akzeptieren genau diese. Alias: beeuni perms.

Gewährungen

Weist einem Principal ein Projektobjekt zu — eine Objektzuweisung. Geheimnisse und Konnektoren befinden sich auf Agenten; daher gewährt die Zuweisung eines Agenten an eine Person alles, was dieser Agent deklariert. Ein Agent ist standardmäßig geschlossen: Ein Mitglied erreicht ihn nur, wenn eine Zuweisung es selbst oder eine seiner Gruppen nennt. beeuni access grant --agent <name> schreibt dieselbe Zeile.

Manifestvalidierung

Siehe Manifestreferenz.

Repositorygröße

Eine Sitzung erstellt ihre Agentenkonfiguration aus jeder Datei, die Git im Basis-Commit verfolgt. Eine neue Sitzung übernimmt diese Dateien aus ihrem eigenen Checkout, unabhängig von der Größe. Eine laufende Sitzung übernimmt eine Änderung des Basis-Branches über den Projektsnapshot, den die Beeuni-Cloud bis zu 512 MiB komprimiert erstellt; darüber hinaus behält die Sitzung die von ihr ausgeführte Konfiguration, bis eine neue Sitzung startet. Jede Sitzung lädt außerdem jede Datei herunter. beeuni validate zählt die von Git gespeicherten Dateien sowie die nicht verfolgten Dateien, die beeuni ship als Nächstes committet, und gibt eine Warnung aus, wenn eine Datei 10 MiB oder mehr groß ist oder die Gesamtsumme 512 MiB überschreitet. Eine Git-LFS-Datei wird als ihr Zeiger gezählt, da die Version nur den Zeiger enthält. Die Warnung nennt die größten Dateien. Der Befehl schlägt dadurch nie fehl.

So beheben Sie das Problem:

• Verschieben Sie große statische Ressourcen (Videos, Bilder, Datensätze, Modellgewichte) in einen Objektspeicher wie S3, R2 oder GCS oder in ein CDN und laden Sie sie zur Laufzeit herunter.
• Fügen Sie Build-Ausgaben (dist/, out/) zu .gitignore hinzu.
• Für einen Pfad, der in Git bleiben muss, aber von keinem Agenten gelesen wird, fügen Sie <path> export-ignore zu .gitattributes hinzu. Die Version lässt ihn ebenso wie die Prüfung aus; eine Verzeichnisregel gilt für alles darunter. Das Verzeichnis der Agentenkonfiguration und beeuni.yaml werden immer vollständig ausgeliefert.

Token-Gültigkeitsbereich

Jedes Token beginnt mit beeuni_pat_. Ein Benutzertoken gilt für jedes Projekt in deinen Konten. Ein Projekttoken gilt für ein einzelnes Projekt und wird automatisch in die Sandboxes dieses Projekts eingefügt. Die vollständige Referenz zur Token-Familie findest du unter Session runtime.

Exit-Codes