CLI

La riga di comando di beeuni, il suo modello di autenticazione, il ciclo di sviluppo e tutti i comandi.

L’interfaccia a riga di comando (CLI) di beeuni controlla Beeuni da un terminale, sul tuo laptop o in una sandbox di sessione. Questa pagina illustra il ciclo di sviluppo quotidiano, poi elenca tutti i comandi e i flag stabili.

Installazione

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

Il programma di installazione scarica un binario precompilato per macOS e Linux. Windows non è supportato.

Modello di autenticazione

Beeuni memorizza l’autenticazione per host, non globalmente. Un host è un endpoint API di Beeuni. Usa cloud per connetterti a Beeuni.

Il file di configurazione si trova in ~/.config/beeuni/config.json, con modalità 0600. Puoi modificarne il percorso con BEEUNI_CONFIG_FILE.

La CLI segue una gerarchia: host → account → progetto → sessione. Accedi a un host, scegli un account al suo interno, scegli un progetto nell’account e apri sessioni nel progetto. beeuni hosts login esegue in ordine i primi tre passaggi: ti fa accedere, sceglie l’account e imposta un progetto predefinito.

Ogni token inizia con beeuni_pat_. Un token utente, ottenuto con beeuni login, consente di vedere tutti gli account e i progetti di cui fai parte. Un token di progetto viene creato automaticamente per una sandbox di sessione ed è limitato a un solo progetto. Vedi Ambito del token.

Il ciclo di sviluppo

Questo ciclo presuppone che la CLI sia installata e che tu abbia eseguito beeuni login. Per la configurazione, vedi Avvio rapido.

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

Riferimento

Comandi di autenticazione

beeuni hosts login / hosts logout / hosts whoami sono le forme canoniche. login / logout / whoami sono scorciatoie che agiscono sull’host attivo.

Host

L’URL di un host remoto che inizia con http:// viene convertito in https://. La CLI non invia mai token a un host remoto tramite HTTP non cifrato. localhost fa eccezione.

Account

Membri

Chi fa parte dell’account e quale ruolo ricopre nell’account. I ruoli sono owner, admin e member. Proprietari e amministratori hanno implicitamente il ruolo Manager in ogni progetto, quindi member è l’unico ruolo a cui vengono assegnate autorizzazioni per singolo progetto.

Un <user> è un ID utente o l’email di una persona già presente nell’account. Opzioni: --account <id>, --host <name>, --json, -y.

Gruppi

Un gruppo di account è un insieme di persone a cui assegni un ruolo una sola volta. Associa un gruppo a un ambito con beeuni access grant --group <id> --role <key>; revoca con beeuni access revoke <assignment-id>.

Un <group> è un ID di gruppo o il suo nome esatto. Per le operazioni di lettura serve group.read. Per create, set e add serve group.update o group.members.manage, oltre all’autorizzazione enterprise rbac. rm e remove servono per la pulizia e non sono mai soggetti a limitazioni di autorizzazione.

Token

Credenziali non interattive per l’account. Per le operazioni di lettura serve token.read. Ogni membro dell’account può creare e revocare le proprie chiavi personali (token.personal.create, token.personal.revoke); una chiave personale agisce come te e non ha mai più ruoli dei tuoi. Per gli account di servizio e le chiavi di altre persone servono token.create / token.revoke (owner e admin).

Una chiave API personale agisce come te e smette di funzionare quando termina la tua appartenenza. Un account di servizio agisce per conto proprio e non eredita alcun accesso: un account nuovo non dispone di autorizzazioni. Concedigliene una con beeuni access grant --service-account <id> --role <key>. --expires <when> accetta una data ISO-8601 o una durata futura: 30d, 12h, 6w, 1y.

Fatturazione

Leggi il piano, i crediti e le spese dell’account attivo. Sola lettura: per modificare i piani, ricaricare il saldo e gestire i metodi di pagamento, usa la dashboard.

Filtri: --project <id>, --session <id> e --owner <id> (sessioni, con --by session). Opzioni: --account <id>, --host <name>, --json.

Progetti

Un comando individua «il progetto» in quest’ordine:

1. Il flag --project.
2. La variabile d’ambiente BEEUNI_PROJECT_ID.
3. .beeuni/link.json nella directory di lavoro esatta.
4. Il valore predefinito globale impostato da beeuni projects use.

Un progetto mostra una sola icona: scrivendo --icon si cancella il glifo e scrivendo --glyph si cancella l’emoji; non è consentito specificarli entrambi. Colori dei glifi: grey, red, orange, yellow, lime, blue, purple, magenta. Per set e features serve project.settings.write. Un flag che la piattaforma contrassegna come non disponibile resta disattivato, indipendentemente dall’override del progetto.

Un token CLI del progetto è associato a un solo progetto: l’API lo rifiuta ovunque altro. Un ambiente sandbox di sessione usa il proprio BEEUNI_TOKEN associato alla sessione. Per cli-tokens ls serve l’accesso in lettura al progetto; per new e rm serve project.credentials.issue. Un token associato a una sessione non può creare né revocare token del progetto (403), indipendentemente dal fatto che il progetto dichiari degli agenti. Un token CLI del progetto segue le regole PAT dell’account: se l’account richiede una scadenza, specifica --expires-at; una scadenza oltre la durata massima restituisce 400.

beeuni projects upgrade richiede l’accesso in scrittura al progetto. L’agente predefinito aggiorna la versione di riferimento del marketplace, riscrive il manifesto, esegue beeuni validate e apre una richiesta di modifica. Non esegue mai il merge: la differenza viene revisionata da una persona.

Struttura iniziale del progetto

beeuni init [project-name] [options] crea una nuova directory di progetto. Il modello iniziale genera un beeuni.yaml v2, agents/, skills/, memory/ e harnesses/opencode/. Il comando può configurare il rilevamento degli strumenti di programmazione locali senza modificare il runtime predefinito. Il comando non scrive .beeuni/link.json. beeuni ship o beeuni projects link creano quel file.

La selezione degli strumenti di programmazione locali non modifica il runtime predefinito.

beeuni init non include un selettore di marketplace. Per aggiungere una competenza dal marketplace, chiedi all’agente di importarla avviando una sessione.

Pubblicazione

beeuni ship prepara, esegue il commit e invia il branch corrente al repository Git del progetto. Eseguilo una volta per creare il progetto. Eseguilo di nuovo in qualsiasi momento per sincronizzare le modifiche. Alias: beeuni deploy.

A ogni esecuzione:

• Esegue i controlli beeuni validate: beeuni.yaml unito a ogni file elencato in imports:, ai Dockerfile delle sandbox, al collegamento degli agenti e alle dimensioni del repository (salta con --no-verify). Un errore interrompe la pubblicazione. Un avviso non la interrompe mai.
• Esegue il commit di eventuali modifiche non salvate nell’albero di lavoro (salta con --no-commit).
• Chiede eventuali secret env mancanti (salta con --no-env).
• Esegue il push del branch corrente sul branch remoto con lo stesso nome.
• Connette tutti i connettori dichiarati che richiedono ancora l’autenticazione (salta con --no-connect).

Un origin GitHub esistente viene collegato tramite l’app GitHub di Beeuni. Qualsiasi altro origin esistente viene registrato così com’è. Se non è presente alcun origin, viene creato un repository Git gestito da Beeuni.

App

Apps ospita siti statici, server, processi e database. Ogni App ha un URL stabile. Una release contiene codice e configurazione; una distribuzione fallita non sostituisce la release attiva.

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

Collega le App con uses e gli esempi di beeuni apps connect. Non inserire credenziali amministrative nel codice client.

Le risorse attive consumano crediti dell’account. Controlla Billing e Usage. Apps non ha un budget mensile separato.

Apps

Sessioni

Ogni sessione viene eseguita in una sandbox sul proprio branch.

sessions queue richiede project.session.start, lo stesso permesso necessario per inviare un messaggio. Un prompt in coda resta disponibile anche dopo la chiusura del terminale e viene consegnato quando la sessione è in grado di riceverlo. Inseriscine uno con beeuni sessions chat <id> -p "…" --queue oppure orienta il turno in corso con --steer. sessions queue ls mostra DELIVERY di ogni prompt (steer, queue o interrupt) e, per un prompt di reindirizzamento eseguito come queue, il motivo: unsupported (la sessione non può ricevere messaggi durante un turno), not_prompter (è in corso il turno di un altro membro) o turn_ended.

sessions approvals sono persistenti: a differenza di sessions pending, sopravvivono al riavvio della sandbox. Per usarli serve project.members.manage oppure essere la persona che ha avviato la sessione. Un agente non può mai risolvere una propria approvazione.

sessions attachments legge l’archivio privato di file della sessione, non la sua area di lavoro. I file vi vengono salvati al momento dell’invio e tutti i file mostrati dall’agente vi vengono salvati al termine del turno.

sessions files legge l’albero di lavoro che l’agente sta modificando in quel momento, prima che venga eseguito un commit; beeuni files legge invece il repository con i commit. I percorsi vengono risolti in /workspace, a meno che non inizino con /workspace, /tmp, /home o /opt. Il comando riattiva la sandbox se è inattiva. Opzioni: --from <local path> (write legge questo file invece di stdin), --content (find cerca nei contenuti con ripgrep invece che nei nomi dei file), --limit <N> (limite di nomi file find) e -y per saltare la conferma rm.

sessions share è soggetto al controllo del proprietario: l’API rifiuta la richiesta di un responsabile di progetto che non abbia già accesso in lettura alla sessione. Una sessione condivisa viene eseguita solo con chiavi del provider condivise con l’intero progetto: un modello che usava le tue chiavi personali passa alle chiavi del progetto per quel provider; se nesbeeuni chiave del progetto consente di eseguirlo, la condivisione viene rifiutata (409 SHARED_SESSION_NEEDS_PROJECT_KEY).

Opzioni di sessions links create: --port <n> (predefinito 3000; 22, 8000 e le porte di opencode vengono rifiutate), --path <p> (predefinito /), --preview <id> (un candidato specifico — web, vite, dev-server, api-docs — invece di --port/--path), --file <path> (condividi un file dell’area di lavoro invece di un’anteprima; sempre in sola lettura), --mode view\|interactive (predefinito view; interactive consente scritture e websocket ed è ignorato per --file), --label <text> e --expires <iso>. Per creare un link serve il proprietario della sessione, perché il link non richiede accesso; per elencare e revocare i link è sufficiente anche un responsabile di progetto.

All’interno di una sandbox, BEEUNI_SESSION_ID è l’id della propria sessione.

Richieste di modifica

Una richiesta di modifica (CR) unisce un branch a un altro su qualsiasi hosting Git. È l’unico modo in cui un agente può portare il lavoro svolto nella sessione nel branch predefinito. Vedi Richieste di modifica.

request-changes registra la nota sulla CR e la invia alla sessione di origine, riavviando la sandbox se è inattiva. Richiede project.review.act, lo stesso permesso specifico usato dal Review Center, non gitops.push.

<cr> accetta un numero specifico del progetto (3) oppure l’id completo. All’interno di una sandbox, la CLI legge automaticamente il token: non serve accedere né usare un link.

Revisione

La casella di revisione del progetto contiene tutto ciò che attende una decisione umana: richieste di modifica, chiamate a strumenti dei connettori bloccate da una policy in attesa di approvazione, nonché output, decisioni e batch inviati dagli agenti per l’approvazione. Rispecchia il Review Center della dashboard. È attiva per tutti i progetti; project.review.read e project.review.act controllano la lettura e l’esecuzione delle azioni.

Esiti: approve, reject, changes, answer, dismiss. Segmenti: needs_you, waiting, done. Tipi: change, approval, output, decision, batch.

L’effetto dell’esito dipende dall’id dell’elemento. Per cr:<id>, approve esegue l’unione della modifica, reject la chiude e changes invia la nota all’agente che l’ha aperta (è richiesto --message). Per call:<id>, approve consente l’esecuzione della chiamata allo strumento e reject la rifiuta; un’approvazione del connettore non ammette altri esiti: prima esamina gli argomenti con beeuni review show. Per tutti gli altri id viene usato l’endpoint nativo delle azioni, che accetta ogni esito.

bulk agisce solo sugli id nativi. Le approvazioni dei connettori richiedono di esaminare i relativi parametri e le richieste di modifica richiedono di visualizzare il diff: entrambe vengono segnalate e ignorate, come avviene con la selezione multipla nella dashboard.

Opzioni di submit: --kind output\|decision\|batch (obbligatorio), --title <text> (obbligatorio), --summary <text>, --risk none\|low\|medium\|high (valore predefinito none), --detail <json> (un oggetto JSON), --agent <name> e --session <id> (ignorato se non si riferisce a una sessione di questo progetto).

Per leggere serve project.review.read, per esprimere un verdetto serve project.review.act e submit richiede project.review.submit.

Segreti

Valori cifrati archiviati nel progetto. Per impostazione predefinita, all’avvio un segreto viene iniettato come variabile d’ambiente in chiaro in ogni sandbox di sessione (esposizione tramite ambiente). La consegna vincolata — in cui la sandbox conserva un riferimento e Beeuni sostituisce il valore reale al di fuori di essa (esposizione vincolata in uscita e beeuni secrets call) — è sperimentale. Attiva il flag di funzionalità secrets_egress (Settings → Feature flags) per usarla; se il flag è disattivato, beeuni secrets delivery … egress restituisce 403 feature_disabled. Vedi Secrets.

grant serve a correggere una riga che ls segnala come non recapitabile. Può solo ampliare l’elenco di un agente; per restringerlo o sostituirlo, riscrivi l’intero insieme con beeuni agents scope. There is no secrets revoke — l’API non ha un endpoint per rimuovere un singolo identificatore da un’autorizzazione. La prima autorizzazione concessa in un progetto senza agenti avvia la governance: da quel momento, un agente non elencato nel manifest non riceve i segreti del progetto e il comando lo segnala quando accade.

Env

Agents

Impostazioni del modello per agente nel progetto collegato.

Ogni opzione di ambito sostituisce i valori; nesbeeuni li unisce. Un valore --set viene interpretato come JSON se è valido, altrimenti viene mantenuto come stringa. I modelli fissati e scope si applicano immediatamente, senza commit di beeuni.yaml; default e config eseguono il commit su beeuni.yaml nel ramo predefinito del progetto. scope richiede project.agent.write, così come default e config.

Tools

Gli strumenti disponibili nelle sessioni del progetto, letti dal file locale beeuni.yaml e dai relativi import. Esegui dalla radice del progetto. Vedi Tools.

Se non è presente la chiave tools:, ogni sessione riceve tutti e cinque gli strumenti Beeuni (web_search, image_search, scrape_webpage, memory, show). Se è presente la chiave tools:, le sessioni ricevono solo gli strumenti Beeuni elencati. Per rimuovere uno strumento Beeuni, elimina la relativa riga sotto tools:, poi esegui beeuni validate. Per limitare gli strumenti di un singolo agente, usa agents.<name>.tools. Codici di uscita: 0 completato, 1 operazione rifiutata (un file esiste, oppure un manifest o un import non è analizzabile), 2 manifest mancante, opzione sconosciuta o nome che non corrisponde a uno strumento Beeuni.

Models

Quali modelli offre il progetto e quale usa all’avvio. Stessa schermata di Customize → Models nel dashboard. Un progetto memorizza solo le eccezioni al valore predefinito del catalogo (il modello più recente di ogni famiglia). L’abilitazione è solo visiva: determina cosa mostrano i selettori, non cosa fornisce il gateway.

Gli ID modello sono ID wire del gateway — un ID gestito semplice (glm-5.3-flash) o un provider/model BYOK. Copiane uno da beeuni models ls --json. I modelli fissati per agente sono in beeuni agents model <agent> <model-id>. Le modifiche richiedono project.model.write.

Channels

Gestisce la connessione del progetto a una piattaforma di chat. I token sono archiviati cifrati nei segreti del progetto e risolti lato server: non vengono mai iniettati nella sandbox.

--platform slack|teams seleziona la piattaforma; predefinita: slack. Teams connect stampa l’URL di consenso amministrativo Microsoft; concedendo il consenso a livello di tenant, l’app viene pubblicata automaticamente nel catalogo di Teams. Vedi Connettori.

Il canale email è basato su AgentMail e richiede il flag della funzionalità agentmail_email. Opzioni email connect: --connector <slug> (predefinita beeuni_email), --api-key <k> (usa la tua chiave AgentMail; - legge da stdin), --display-name <n> (nome mittente per le email in uscita; per impostazione predefinita, il nome del progetto), --username <u> e --domain <d> (una nuova casella gestita) e --inbox-id <id> con --email <addr> (collega una casella esistente: entrambi sono obbligatori). --allow è ripetibile e attiva la modalità con restrizioni; un valore senza @ o con @ iniziale viene interpretato come dominio. --allow-all cancella l’elenco e consente nuovamente tutti i mittenti.

Le scritture email e bind richiedono project.connector.write.

Connettori

Connettori che un agente usa come strumenti. add, rm e policy set modificano il file locale beeuni.yaml; esegui beeuni ship per applicare le modifiche, a meno che tu non passi --apply per modificare immediatamente il progetto cloud.

policy ls, show, set, add e rm sono comandi che agiscono sull’intero progetto: perciò, un connettore che ha lo stesso nome di uno di questi verbi va indicato come policy <slug> ls. Un <match> è il nome di uno strumento, un glob (send_*) o un /regex/.

Opzioni 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.

Sandbox

Gestisce le immagini sandbox del progetto. Un modello definisce un’immagine o un Dockerfile e le risorse; una build crea lo snapshot da cui vengono avviate le sessioni.

Fissare un provider richiede project.settings.write.

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

Backend

I database sono App con volumi persistenti. Gestiscili e collegali tramite Apps.

Apps

Marketplace

Esplora il marketplace di Beeuni e installa un elemento in un progetto.

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

L’installazione è gestita dall’agente: avvia una sessione del progetto che clona l’elemento, lo legge, integra ciò che è compatibile e apre una richiesta di modifica. Non esiste alcun meccanismo deterministico per installare, aggiornare o rimuovere elementi.

Competenze di sistema

Le competenze di sistema di Beeuni sono il riferimento operativo della piattaforma per persone e agenti. Coprono sessioni, sandbox, il runtime predefinito, connettori, memoria e canali. Questa pagina pubblica è il punto di ingresso; la CLI autenticata legge le competenze dall’host in esecuzione. Usa beeuni system-skills list per scoprire le competenze disponibili, poi get quella necessaria. L’API le fornisce in tempo reale, quindi corrispondono alla versione dell’host distribuita. Non considerare aggiornata una copia locale.

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

beeuni skills è un alias permanente dello stesso comando. Accedi prima all’host con beeuni login; l’API delle competenze richiede l’autenticazione. Usa --host <name> quando lavori con un altro host. Una pagina di documentazione pubblica non può sostituire queste istruzioni aggiornate e specifiche dell’host.

Questo elenco contiene sempre le competenze di sistema, mai un insieme misto. Le competenze facoltative si trovano nel marketplace: beeuni marketplace list --type skill. Per la sintassi dei comandi, usa beeuni <command> --help; per il riferimento completo della piattaforma, leggi beeuni system-skills get beeuni-system --full.

Connettore

L’interfaccia dell’agente nella sandbox per ogni connettore. Ogni chiamata viene verificata, risolta e sottoposta ad audit lato server; la CLI non conserva mai credenziali di terze parti. Autenticazione: BEEUNI_TOKEN. L’output è JSON.

File

Vista in sola lettura del repository git del progetto. Opera sul branch predefinito, a meno che --ref non specifichi un altro branch, tag o commit.

Opções para todos os subcomandos: --ref <ref>, --path <p>, --limit <n>, --json. download também aceita -o, --out <file>, que é obrigatório.

Todos os subcomandos precisam de project.file.read. Além disso, download recusa qualquer subárvore que inclua um agente ou uma skill fora do seu escopo — não é possível filtrar um zip durante a transmissão —, então, nesse caso, arquive um --path mais restrito.

Gatilhos

Um gatilho inicia uma sessão com base em um agendamento, webhook, evento de app ou monitor (experimental). add, rm, enable e disable editam o manifesto local — execute beeuni ship para aplicar. pause/resume alternam um controle separado no servidor. Consulte Gatilhos.

Opções de add: --type <cron\|webhook\|event\|monitor> (padrão cron), --prompt <text> (obrigatório), --agent <name>, --cron <expr> (6 campos, por exemplo "0 0 9 * * 1-5"), --run-at <iso> (executa uma vez neste instante, em vez de usar um cron), --timezone <tz> (padrão: UTC), --secret-env <NAME>, --name <label>, --disabled.

Opções exclusivas para gatilhos ativos — válidas em add --apply e em todos os set: --model <provider/model>, --session-mode <fresh\|keyed\|pinned\|reuse>, --session-key <tmpl> (agrupa uma sessão por chave, por exemplo "{{ body.data.chat_jid }}"; implica keyed), --session-id <id> (a sessão em que um gatilho pinned faz loops; deve ser uma sessão deste projeto), --session-access <private\|project\|members> (padrão private), --member <uuid> e --group <uuid> (podem ser repetidas; cada uma implica members), e --filter <path=value> (pode ser repetida; todas precisam corresponder, por exemplo --filter body.type=push).

set aceita todas as opções exclusivas para gatilhos ativos, além de --name, --prompt, --cron, --run-at, --timezone, --secret-env, --agent e --enabled true|false. --cron e --run-at são exclusivas: definir uma limpa a outra. Os campos do monitor só podem ser adicionados.

Lembretes

Um lembrete envia um novo prompt para uma sessão mais tarde, uma vez ou de forma recorrente. Ele é armazenado no banco de dados, não em beeuni.yaml. Dentro de uma sessão, --session tem como padrão $BEEUNI_SESSION_ID. Consulte Lembretes.

Opções de agendamento: --in <duration> ou --at <iso> (primeiro disparo; se usado sozinho, dispara uma vez), --every <duration> (recorrência, mínimo de 5m), --cron "<expr>" com --timezone <tz>. Outras opções: --name <label>, --session <id> (um prefixo exclusivo funciona), --project <id>, --host <name>, --json.

Opções de evento (--type event): --connector <slug> e --event <TYPE> (ambas obrigatórias), --config key=value (repetível, valores de string) e --config-json '{...}' (valores tipados). set aceita as mesmas flags. Um gatilho de evento rejeita --cron, --run-at, --timezone, --secret-env e as opções de monitor. O prompt lê {{ event.data.<field> }}; consulte Gatilhos de eventos de app.

Opções de monitor (--type monitor): --run <cmd> (comando relativo ao repositório a ser monitorado; obrigatório), --mode <poll\|stream> (obrigatório; poll executa novamente em --interval, stream mantém o comando em execução), --interval <dur> (somente mode=poll, mínimo de 30s, por exemplo 60s, 5m) e --expect-event-within <dur> (watchdog de silêncio; se nenhum evento ocorrer dentro do intervalo, dispara um evento de ciclo de vida; mínimo de 5m, por exemplo 24h). Um monitor é um comando do repositório que a plataforma executa 24 horas por dia, 7 dias por semana, e cada linha de stdout dispara o gatilho. É experimental: a plataforma executa monitores somente onde a feature flag monitors está ativada.

Acesso

A interface de linha de comando da tabela única de concessões. Cada linha é uma atribuição: um principal, uma função, um escopo e, opcionalmente, um objeto específico. Consulte Contas e acesso para entender o modelo. Funções da conta: owner, admin, member. Funções do projeto: manager, member.

Opções de concessão: --project <id> (padrão: o projeto vinculado), --account (a conta inteira), --agent <name> (restringe a concessão a um agente — uma atribuição a objeto), --connection <id> (restringe o uso de uma conta de conector compartilhada; a primeira concessão limita a conta aos seus beneficiários, e revogar a última a libera novamente para todo o projeto), --everyone (concede acesso a todos que têm acesso ao projeto; recebe um --agent ou um --connection, nunca uma função) e --expires <iso> (timestamp de revogação automática). --principal filtra uma lista e aceita user:<id>, group:<id>, service_account:<id>, project:<id> ou pending:<email>; um id sem prefixo é interpretado como usuário. Uma concessão para todos é exibida como everyone. A identidade de um agente é um service_account, então --service-account <id> é a forma de atribuir uma função a um agente. --user aceita um email e o resolve no diretório de membros da conta.

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…

Os verbos de membros do projeto são uma visão de leitura das mesmas atribuições:

Todos os verbos nos dois blocos acima precisam de project.members.manage.

Uma pessoa, um grupo ou um agente recebe funções do Beeuni; além disso, um agente carrega permissões do Beeuni em beeuni.yaml, e uma sessão só pode fazer o que ambos permitem. Consulte Um vocabulário, duas vinculações.

Auditoria

Os comandos de auditoria leem o log centralizado de reconstrução. As listas de contas e projetos são ordenadas da mais recente para a mais antiga. A linha do tempo de uma sessão é ordenada por horário de criação (session_sequence só é definido nas linhas gravadas antes de 2026-10, que aparecem primeiro). --all acompanha cada cursor de continuação. ls lista os últimos 90 dias; export retrocede 365 dias, e os eventos com mais de 90 dias vêm do arquivo (consulte Retenção de auditoria). A tabela mostra junto a cada linha o título (EVENT, por exemplo, “Chave do gateway LLM revogada”) e seu ACTION (gateway.key.revoke); --action filtra pelo prefixo da ação. Todas as ações e títulos: Ações do log de auditoria.

Os webhooks de auditoria transmitem o registro para um SIEM. Todos os verbos precisam de account.write; add e enable também exigem o direito de uso enterprise. disable e rm nunca exigem.

Filtros: --actor, --actor-type, --project, --session, --source, --phase, --outcome, --action, --resource-type, --request-id, --correlation-id, --query, --since, --until, --cursor e --limit. As listas e exportações da conta exigem audit.read e o direito de uso auditAccess da conta. As listas de todo o projeto exigem project.members.manage, pois podem incluir metadados de sessões privadas. A reconstrução de uma sessão exige project.session.read e visibilidade dessa sessão.

Funções

Uma função é um conjunto nomeado de permissões. As funções do sistema (owner, admin, member no escopo da conta; manager, member no escopo do projeto; além de agent-user, o marcador carregado por uma atribuição de objeto) são referências somente leitura. Você pode criar e editar funções personalizadas, que exigem o direito de uso enterprise rbac.

Vincule uma função a um principal com beeuni access grant. Os verbos mais antigos beeuni roles assign / unassign / assignments ainda funcionam e gravam na mesma tabela, mas beeuni access é o caminho documentado. beeuni roles actions foi substituído por beeuni permissions ls.

Uma função personalizada apenas adiciona permissões. O Beeuni não tem regras de negação, portanto uma função não pode impedir que um gerente tenha uma permissão.

Permissões

O catálogo de permissões, como dados. Uma linha por ação final, com o escopo em que ela é avaliada, se pode ser delegada e o que implica. As funções são criadas a partir dessas chaves — beeuni roles create --actions e beeuni roles set-actions usam exatamente essas chaves. Alias: beeuni perms.

Concessões

Atribui um objeto do projeto a um principal — uma atribuição de objeto. Os segredos e conectores ficam nos agentes; portanto, atribuir um agente a uma pessoa concede tudo o que esse agente declara. Por padrão, o acesso a um agente é fechado: um membro só pode acessá-lo quando uma atribuição o identifica pelo nome ou identifica um grupo ao qual pertence. beeuni access grant --agent <name> grava a mesma linha.

Validação do manifesto

Consulte Referência do manifesto.

Tamanho do repositório

Uma sessão cria a configuração do agente a partir de todos os arquivos rastreados pelo Git no commit base. Uma nova sessão obtém esses arquivos do próprio checkout, independentemente do tamanho. Uma sessão em execução recebe as alterações na branch base por meio do snapshot do projeto, que o Beeuni Cloud cria até 512 MiB compactados; acima disso, a sessão mantém a configuração em execução até o início de uma nova sessão. Todas as sessões também baixam todos os arquivos. beeuni validate contabiliza os arquivos armazenados pelo Git, além dos arquivos não rastreados que beeuni ship adicionará em seguida, e exibe um aviso quando um arquivo tiver 10 MiB ou mais ou o total ultrapassar 512 MiB. Um arquivo do Git LFS é contabilizado como seu ponteiro, pois a versão inclui apenas o ponteiro. O aviso indica os arquivos maiores. Ele nunca faz o comando falhar.

Para eliminar o aviso:

• Mova recursos estáticos grandes (vídeos, imagens, conjuntos de dados, pesos de modelos) para um armazenamento de objetos como S3, R2 ou GCS, ou para uma CDN, e baixe-os durante a execução.
• Adicione a saída da compilação (dist/, out/) a .gitignore.
• Para um caminho que precisa permanecer no Git, mas que nenhum agente lê, adicione <path> export-ignore a .gitattributes. A versão o exclui, assim como a verificação; uma regra de diretório abrange tudo o que estiver dentro dele. O diretório de configuração do agente e beeuni.yaml sempre são incluídos por inteiro.

Escopo do token

Ogni token inizia con beeuni_pat_. Un token utente è valido per tutti i progetti dei tuoi account. Un token di progetto è valido per un solo progetto e viene inserito automaticamente nelle sandbox di quel progetto. Consulta il riferimento completo alla famiglia di token in Runtime della sessione.

Codici di uscita