CLI

La línea de comandos de beeuni, su modelo de autenticación, el ciclo de desarrollo y todos los comandos.

La interfaz de línea de comandos (CLI) de beeuni controla Beeuni desde una terminal: tu portátil o un sandbox de sesión. Esta página muestra el ciclo de desarrollo diario y, después, enumera todos los comandos y las opciones estables.

Instalación

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

El instalador descarga un binario precompilado para macOS y Linux. Windows no es compatible.

Modelo de autenticación

Beeuni almacena la autenticación por host, no globalmente. Un host es un único endpoint de la API de Beeuni. Usa cloud para conectarte a Beeuni.

El archivo de configuración se encuentra en ~/.config/beeuni/config.json, con modo 0600. Anula su ruta con BEEUNI_CONFIG_FILE.

La CLI sigue una jerarquía: host → cuenta → proyecto → sesión. Inicias sesión en un host, eliges una cuenta dentro de él, eliges un proyecto dentro de esa cuenta y abres sesiones dentro del proyecto. beeuni hosts login recorre los tres primeros pasos en orden: inicia sesión, elige la cuenta y establece un proyecto predeterminado.

Cada token comienza con beeuni_pat_. Un token de usuario, procedente de beeuni login, permite ver todas las cuentas y proyectos a los que perteneces. Un token de proyecto se genera automáticamente para un sandbox de sesión y está limitado a un proyecto. Consulta Ámbito del token.

El ciclo de desarrollo

Este ciclo presupone que la CLI está instalada y que ejecutaste beeuni login. Consulta Inicio rápido para la configuración.

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

Referencia

Comandos de autenticación

beeuni hosts login / hosts logout / hosts whoami son las formas canónicas. login / logout / whoami son accesos directos que actúan sobre el host activo.

Hosts

Una URL de host remoto que comienza con http:// se normaliza a https://. La CLI nunca envía un token mediante HTTP sin cifrar a un host remoto. localhost está exento.

Cuentas

Miembros

Quién pertenece a la cuenta y qué rol tiene en ella. Los roles son owner, admin y member. Los propietarios y administradores tienen el rol Manager implícito en todos los proyectos, por lo que member es el único rol que admite permisos por proyecto.

Un <user> es un id de usuario o el correo electrónico de alguien que ya pertenece a la cuenta. Opciones: --account <id>, --host <name>, --json, -y.

Grupos

Un grupo de cuentas es un conjunto de personas con nombre al que asignas un rol una sola vez. Vincula un grupo a un ámbito con beeuni access grant --group <id> --role <key>; revoca la vinculación con beeuni access revoke <assignment-id>.

Un <group> es el ID de un grupo o su nombre exacto. Para leer, se necesita group.read. create, set y add requieren group.update o group.members.manage, además de la autorización empresarial rbac. rm y remove son operaciones de limpieza y nunca requieren autorización.

Tokens

Credenciales no interactivas de la cuenta. Para leer, se necesita token.read. Todos los miembros de la cuenta pueden crear y revocar sus propias claves personales (token.personal.create, token.personal.revoke); una clave personal actúa como tú y nunca tiene más permisos que tus propios roles. Las cuentas de servicio y las claves de otras personas requieren token.create / token.revoke (propietario y administrador).

Una clave de API personal actúa como tú y deja de funcionar cuando termina tu membresía. Una cuenta de servicio actúa por sí misma y no hereda ningún acceso: una cuenta nueva no tiene permisos. Asígnale permisos con beeuni access grant --service-account <id> --role <key>. --expires <when> acepta fechas ISO-8601 o una duración relativa: 30d, 12h, 6w, 1y.

Facturación

Consulta el plan, los créditos y el gasto de la cuenta activa. Solo lectura: los cambios de plan, las recargas y los métodos de pago se gestionan desde el panel.

Filtros: --project <id>, --session <id> y --owner <id> (sesiones, con --by session). Opciones: --account <id>, --host <name>, --json.

Proyectos

Un comando resuelve «el proyecto» en este orden:

1. La opción --project.
2. La variable de entorno BEEUNI_PROJECT_ID.
3. .beeuni/link.json en el directorio de trabajo exacto.
4. El proyecto predeterminado global establecido por beeuni projects use.

Un proyecto muestra un solo icono, así que al escribir --icon se borra el glifo y al escribir --glyph se borra el emoji; si se indican ambos, se rechaza la operación. Colores de glifo: grey, red, orange, yellow, lime, blue, purple, magenta. set y features requieren project.settings.write. Si la plataforma marca una función como no disponible, permanece desactivada independientemente de la anulación del proyecto.

Un token CLI de proyecto está vinculado a un solo proyecto: la API lo rechaza en cualquier otro. Un entorno aislado de sesión usa su BEEUNI_TOKEN vinculado a la sesión. cli-tokens ls requiere permiso de lectura del proyecto; new y rm requieren project.credentials.issue. Un token vinculado a una sesión no puede crear ni revocar tokens de proyecto (403), tanto si el proyecto declara agentes como si no. Un token CLI de proyecto sigue la política de PAT de la cuenta: si la cuenta exige una fecha de vencimiento, indica --expires-at; si la fecha supera la duración máxima, se devuelve 400.

beeuni projects upgrade requiere permiso de escritura en el proyecto. El agente predeterminado actualiza la base del marketplace, reescribe el manifiesto, ejecuta beeuni validate y abre una solicitud de cambio. Nunca la fusiona: una persona revisa las diferencias.

Estructura inicial del proyecto

beeuni init [project-name] [options] crea un directorio de proyecto nuevo. La plantilla inicial escribe un beeuni.yaml v2, agents/, skills/, memory/ y harnesses/opencode/. El comando puede configurar el descubrimiento de herramientas de programación locales sin cambiar el entorno de ejecución predeterminado en la nube. El comando no escribe .beeuni/link.json. beeuni ship o beeuni projects link crean ese archivo.

La selección de herramientas de programación locales no cambia el entorno de ejecución predeterminado en la nube.

beeuni init no incluye un selector de marketplace. Añadir una habilidad del marketplace es una importación del agente: inicia una sesión y pídele al agente que la importe.

Publicar

beeuni ship prepara, confirma y sube la rama actual al repositorio Git del proyecto. Ejecútalo una vez para crear el proyecto. Vuelve a ejecutarlo cuando quieras sincronizarlo. Alias: beeuni deploy.

Cada ejecución:

• Ejecuta las comprobaciones de beeuni validate: beeuni.yaml se combina con cada archivo que enumera en imports:, los Dockerfiles del sandbox, la configuración del agente y el tamaño del repositorio (se omite con --no-verify). Un error detiene la publicación. Una advertencia nunca lo hace.
• Confirma cualquier árbol de trabajo con cambios (se omite con --no-commit).
• Solicita cualquier secreto env que falte (se omite con --no-env).
• Envía la rama actual a la rama remota con el mismo nombre.
• Conecta cualquier conector declarado que aún necesite autenticación (se omite con --no-connect).

Un origin existente de GitHub se vincula mediante la GitHub App de Beeuni. Cualquier otro origin existente se registra tal cual. Si no existe origin, se crea un repositorio git administrado por Beeuni.

Apps

Apps aloja sitios estáticos, servidores, tareas y bases de datos. Cada App tiene una URL estable. Una versión contiene código y configuración; un despliegue fallido no sustituye la versión activa.

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

Conecta Apps mediante uses y los ejemplos de beeuni apps connect. No incluyas credenciales administrativas en el código cliente.

Los recursos activos consumen créditos de la cuenta. Consulta Billing y Usage. Apps no tiene un presupuesto mensual separado.

Apps

Sesiones

Cada sesión se ejecuta en un sandbox en su propia rama.

sessions queue requiere project.session.start —el mismo permiso que enviar un mensaje. Una solicitud en cola persiste aunque se cierre el terminal y se entrega cuando la sesión puede recibirla. Añade una con beeuni sessions chat <id> -p "…" --queue o dirige el turno en curso con --steer. sessions queue ls muestra el DELIVERY de cada solicitud (steer, queue o interrupt) y, si una solicitud de dirección se ejecuta como queue, el motivo: unsupported (la sesión no puede recibir mensajes durante un turno), not_prompter (hay otro turno de un miembro en curso) o turn_ended.

sessions approvals son persistentes: a diferencia de sessions pending, sobreviven al reinicio del entorno aislado. Se necesita project.members.manage o ser la persona que inició la sesión. Un agente nunca puede resolver su propia aprobación.

sessions attachments lee el almacén privado de archivos de la sesión, no su espacio de trabajo. Los archivos se guardan ahí al enviarlos, y todos los archivos que mostró el agente se guardan ahí al final del turno.

sessions files lee el árbol de trabajo que el agente está editando en este momento, antes de confirmar cualquier cambio; beeuni files lee el repositorio confirmado. Las rutas se resuelven dentro de /workspace, salvo que empiecen por /workspace, /tmp, /home o /opt. El comando activa el entorno aislado si está inactivo. Opciones: --from <local path> (write lee este archivo en lugar de stdin), --content (find busca en el contenido con ripgrep en vez de en los nombres de archivo), --limit <N> (find límite de archivos) y -y para omitir la confirmación de rm.

sessions share se rige por el propietario: la API rechaza a un gestor del proyecto que no pueda leer ya la sesión. Una sesión compartida solo se ejecuta con claves de proveedor compartidas con todo el proyecto: un modelo que se ejecutaba con tus propias claves pasa a usar las claves del proyecto para ese proveedor; si no hay ninguna clave que permita ejecutarlo, se rechaza la solicitud de compartir (409 SHARED_SESSION_NEEDS_PROJECT_KEY).

Opciones de sessions links create: --port <n> (valor predeterminado 3000; se rechazan 22, 8000 y los puertos de opencode), --path <p> (valor predeterminado /), --preview <id> (un candidato con nombre —web, vite, dev-server, api-docs— en lugar de --port/--path), --file <path> (comparte un archivo del espacio de trabajo en lugar de una vista previa; siempre de solo lectura), --mode view\|interactive (valor predeterminado view; interactive permite escrituras y websockets, y se ignora para --file), --label <text> y --expires <iso>. Para crear un enlace se necesita ser propietario de la sesión, porque el enlace no requiere iniciar sesión; para mostrar la lista y revocar enlaces también se acepta a un gestor del proyecto.

Dentro de un entorno aislado, BEEUNI_SESSION_ID es el id de tu propia sesión.

Solicitudes de cambio

Una solicitud de cambio (CR) fusiona una rama con otra en cualquier host de git. Es la única forma de que un agente incorpore el trabajo de una sesión a la rama predeterminada. Consulta Solicitudes de cambio.

request-changes registra la nota en la CR y la envía a la sesión de origen, activando su entorno aislado si está inactivo. Requiere project.review.act —el mismo permiso específico que usa el Centro de revisión, no gitops.push.

<cr> acepta un número de proyecto (3) o el id completo. Dentro de un entorno aislado, la CLI lee automáticamente el token; no hace falta iniciar sesión ni usar un enlace.

Revisión

La bandeja de revisión del proyecto contiene todo lo que espera una decisión humana: solicitudes de cambio, llamadas a herramientas de conectores cuya política exige aprobación y resultados, decisiones y lotes que los agentes envían para su aprobación. Es el equivalente del Centro de revisión del panel. Está habilitada para todos los proyectos; project.review.read y project.review.act controlan la lectura y la gestión.

Veredictos: approve, reject, changes, answer, dismiss. Segmentos: needs_you, waiting, done. Tipos: change, approval, output, decision, batch.

El efecto de un veredicto depende del id del elemento. Para cr:<id>, approve fusiona el cambio, reject lo cierra y changes devuelve la nota al agente que lo abrió (se requiere --message). Para call:<id>, approve permite que se ejecute la llamada a la herramienta y reject la rechaza; una aprobación de conector no admite ningún otro veredicto: consulta primero sus argumentos con beeuni review show. Cualquier otro id se envía al endpoint de acción nativa, que admite todos los veredictos.

bulk solo actúa sobre ids nativos. Tanto las aprobaciones de conectores, que requieren revisar sus parámetros, como las solicitudes de cambio, que requieren ver su diff, se notifican y se omiten; es la misma regla que aplica la selección múltiple del panel.

Opciones de submit: --kind output\|decision\|batch (obligatorio), --title <text> (obligatorio), --summary <text>, --risk none\|low\|medium\|high (valor predeterminado: none), --detail <json> (un objeto JSON), --agent <name> y --session <id> (se ignora si no corresponde a una sesión de este proyecto).

Para leer se requiere project.review.read; para emitir veredictos, project.review.act; y submit requiere project.review.submit.

Secretos

Valores cifrados almacenados en el proyecto. De forma predeterminada, al iniciar, un secreto se inyecta como variable de entorno de texto sin formato en cada entorno aislado de sesión (exposición mediante el entorno). La entrega con aplicación de políticas —en la que el entorno aislado conserva un identificador y Beeuni sustituye el valor real fuera de él (exposición controlada en la salida y beeuni secrets call)— es experimental. Activa la marca de función secrets_egress (Settings → Feature flags) para usarla; con la marca desactivada, beeuni secrets delivery … egress devuelve 403 feature_disabled. Consulta Secrets.

grant soluciona los casos en que ls informa que no se puede entregar un secreto. Solo amplía la lista de un agente; para reducirla o sustituirla, vuelve a escribir el conjunto completo con beeuni agents scope. There is no secrets revoke: la API no tiene ninguna ruta para eliminar un identificador concreto de una concesión. La primera concesión en un proyecto sin agentes inicia la gobernanza: desde entonces, los agentes que no figuren en el manifiesto no reciben secretos del proyecto, y el comando lo indica cuando sucede.

Env

Agents

Configuración del modelo de cada agente en el proyecto vinculado.

Cada opción de ámbito sustituye el valor; ninguna lo combina. Un valor --set se interpreta como JSON si se puede analizar; de lo contrario, se conserva como cadena. Las fijaciones de modelo y scope se aplican al instante, sin confirmación de beeuni.yaml; default y config confirman los cambios en beeuni.yaml de la rama predeterminada del proyecto. scope requiere project.agent.write, al igual que default y config.

Tools

Las herramientas que reciben las sesiones de este proyecto, leídas desde el archivo local beeuni.yaml y sus imports. Ejecuta el comando desde la raíz del proyecto. Consulta Tools.

Si no hay una clave tools:, todas las sesiones reciben las cinco herramientas de Beeuni (web_search, image_search, scrape_webpage, memory, show). Si hay una clave tools:, las sesiones reciben solo las herramientas de Beeuni que esta enumera. Para quitar una herramienta de Beeuni, elimina su línea debajo de tools: y luego ejecuta beeuni validate. Para limitar las herramientas de un agente, usa agents.<name>.tools. Códigos de salida: 0 completado; 1 rechazado (existe un archivo, un manifiesto o una importación no se puede analizar); 2 no hay manifiesto, opción desconocida o el nombre no corresponde a una herramienta de Beeuni.

Models

Qué modelos ofrece el proyecto y cuál usa inicialmente. La misma interfaz que Customize → Models en el panel. El proyecto solo guarda las excepciones al valor predeterminado del catálogo (el modelo más reciente de cada familia). La habilitación solo afecta a lo que se muestra: determina las opciones que ofrecen los selectores, nunca lo que ofrece la pasarela.

Los ID de modelo son ID de protocolo de la pasarela: un ID gestionado sin prefijo (glm-5.3-flash) o un provider/model de BYOK. Copia uno de beeuni models ls --json. Las fijaciones por agente se configuran en beeuni agents model <agent> <model-id>. Para escribir se necesita project.model.write.

Channels

Administra la conexión del proyecto a una plataforma de chat. Los tokens se almacenan cifrados en los secretos del proyecto y se resuelven en el servidor; nunca se inyectan en el entorno aislado.

--platform slack|teams selecciona la plataforma; valor predeterminado: slack. Teams connect imprime la URL de consentimiento de administrador de Microsoft; otorgar el consentimiento para todo el tenant publica automáticamente la aplicación en el catálogo de Teams. Consulta Conectores.

El canal de correo electrónico usa AgentMail y necesita la marca de función agentmail_email. email connect opciones: --connector <slug> (valor predeterminado beeuni_email), --api-key <k> (usa tu propia clave de AgentMail; - lee de stdin), --display-name <n> (nombre del remitente en los correos salientes; por defecto, el nombre del proyecto), --username <u> y --domain <d> (una bandeja de entrada administrada nueva), y --inbox-id <id> con --email <addr> (adjunta una bandeja de entrada existente; ambas son necesarias juntas). --allow se puede repetir y pone la política en modo restringido; un valor sin @, o uno con un @ inicial, se interpreta como un dominio. --allow-all borra la lista y vuelve a aceptar a cualquier remitente.

Las escrituras de correo electrónico y bind necesitan project.connector.write.

Conectores

Conectores que un agente invoca como herramientas. add, rm y policy set editan el beeuni.yaml local; ejecuta beeuni ship para aplicarlo, a menos que pases --apply para cambiar inmediatamente el proyecto en la nube.

policy ls, show, set, add y rm son la superficie de todo el proyecto, por lo que un conector cuyo nombre coincida con uno de esos verbos debe abordarse como policy <slug> ls. Un <match> es un nombre de herramienta, un glob (send_*) o un /regex/.

Opciones de 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

Administra las imágenes de sandbox del proyecto. Una plantilla define una imagen o un Dockerfile, además de los recursos; una compilación produce la instantánea desde la que se inician las sesiones.

Fijar un proveedor necesita project.settings.write.

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

Backends

Las bases de datos son Apps con volúmenes persistentes. Adminístralas y conéctalas mediante Apps.

Apps

Marketplace

Explora el marketplace de Beeuni e instala un elemento en un proyecto.

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

La instalación la gestiona un agente: inicia una sesión de proyecto que clona el elemento, lo lee, integra lo que encaja y abre una solicitud de cambio. No hay un mecanismo determinista para instalar, actualizar o eliminar.

Habilidades del sistema

Las habilidades del sistema de Beeuni son la referencia operativa de la plataforma, tanto para las personas como para los agentes. Abarcan sesiones, entornos aislados, el entorno de ejecución predeterminado, conectores, memoria y canales. Esta página pública es el punto de entrada; la CLI autenticada obtiene las habilidades del host en ejecución. Usa beeuni system-skills list para descubrir las habilidades disponibles y, luego, get la que necesites. La API las sirve en tiempo real, por lo que coinciden con la versión implementada en el host. No consideres actualizada una copia local.

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

beeuni skills es un alias permanente para el mismo comando. Inicia sesión primero en el host con beeuni login; la API de habilidades requiere autenticación. Usa --host <name> cuando trabajes con otro host. Una página pública de documentación no puede sustituir estas instrucciones actualizadas y específicas del host.

Esta lista siempre contiene las habilidades del sistema, nunca una combinación. Las habilidades opcionales están en el marketplace: beeuni marketplace list --type skill. Para la sintaxis de los comandos, usa beeuni <command> --help; para consultar la referencia completa de la plataforma, lee beeuni system-skills get beeuni-system --full.

Conector

La interfaz del agente en el entorno aislado con todos los conectores. Cada llamada se valida, resuelve y audita en el servidor; la CLI nunca almacena credenciales de terceros. Autenticación: BEEUNI_TOKEN. La salida es JSON.

Archivos

Vista de solo lectura del repositorio git del proyecto. Opera en la rama predeterminada, salvo que --ref especifique otra rama, etiqueta o confirmación.

Opciones en todos los subcomandos: --ref <ref>, --path <p>, --limit <n>, --json. download también acepta -o, --out <file>, que es obligatorio.

Todos los subcomandos necesitan project.file.read. download además rechaza cualquier subárbol que incluyera un agente o una habilidad fuera del ámbito asignado; un zip no se puede filtrar durante la transmisión, así que en ese caso archiva un --path más específico.

Activadores

Un activador inicia una sesión a partir de una programación, un webhook, un evento de aplicación o un monitor (experimental). add, rm, enable, disable editan el manifiesto local; ejecuta beeuni ship para aplicarlo. pause/resume cambian un interruptor independiente del lado del servidor. Consulta Activadores.

Opciones de add: --type <cron\|webhook\|event\|monitor> (predeterminado cron), --prompt <text> (obligatorio), --agent <name>, --cron <expr> (de 6 campos, p. ej., "0 0 9 * * 1-5"), --run-at <iso> (se ejecuta una vez en este instante en lugar de mediante cron), --timezone <tz> (UTC de forma predeterminada), --secret-env <NAME>, --name <label>, --disabled.

Opciones solo activas — válidas en add --apply y en cada set: --model <provider/model>, --session-mode <fresh\|keyed\|pinned\|reuse>, --session-key <tmpl> (agrupa una sesión por clave, p. ej., "{{ body.data.chat_jid }}"; implica keyed), --session-id <id> (la sesión en bucle de un activador pinned; debe ser la sesión de este proyecto), --session-access <private\|project\|members> (predeterminado private), --member <uuid> y --group <uuid> (repetibles; cada uno implica members), y --filter <path=value> (repetible; todos deben coincidir, p. ej., --filter body.type=push).

set acepta todas las opciones solo activas, además de --name, --prompt, --cron, --run-at, --timezone, --secret-env, --agent y --enabled true|false. --cron y --run-at son exclusivas: establecer una borra la otra. Los campos del monitor solo permiten adiciones.

Recordatorios

Un recordatorio vuelve a solicitar algo en una sesión posterior, una vez o repetidamente. Se almacena en la base de datos, no en beeuni.yaml. Dentro de una sesión, --session tiene $BEEUNI_SESSION_ID como valor predeterminado. Consulta Recordatorios.

Opciones de programación: --in <duration> o --at <iso> (primera activación; por sí sola, se activa una vez), --every <duration> (repetición, mín. 5m), --cron "<expr>" con --timezone <tz>. Otras opciones: --name <label>, --session <id> (se acepta un prefijo único), --project <id>, --host <name>, --json.

Opciones de evento (--type event): --connector <slug> y --event <TYPE> (ambas obligatorias), --config key=value (repetible, valores de cadena) y --config-json '{...}' (valores tipados). set acepta las mismas opciones. Un activador de evento rechaza --cron, --run-at, --timezone, --secret-env y las opciones de monitor. El mensaje se lee en {{ event.data.<field> }}; consulta Activadores de eventos de aplicación.

Opciones de monitor (--type monitor): --run <cmd> (comando relativo al repositorio que se supervisará; obligatorio), --mode <poll\|stream> (obligatorio; poll vuelve a ejecutarse en --interval, stream mantiene activo el comando), --interval <dur> (solo mode=poll, mínimo 30 s, p. ej., 60s, 5m) y --expect-event-within <dur> (supervisor de silencio; si no hay ningún evento dentro del intervalo, activa un evento de ciclo de vida en su lugar, mínimo 5 min, p. ej., 24h). Un monitor es un comando del repositorio que la plataforma ejecuta las 24 horas, y cada línea de stdout activa el activador. Es experimental: la plataforma solo ejecuta monitores donde está activado el indicador de función monitors.

Acceso

La interfaz de CLI de la tabla de concesiones única. Cada fila es una asignación: un principal, un rol y un ámbito, opcionalmente limitado a un objeto. Consulta Cuentas y acceso para conocer el modelo. Roles de cuenta: owner, admin, member. Roles de proyecto: manager, member.

Opciones de concesión: --project <id> (predeterminado: el proyecto vinculado), --account (toda la cuenta), --agent <name> (limita la concesión a un agente; una asignación de objeto), --connection <id> (limita el uso de una cuenta de conector compartida; la primera concesión limita la cuenta a sus beneficiarios, y revocar la última vuelve a abrirla a todo el proyecto), --everyone (concede acceso a todos los que tienen acceso al proyecto; contiene un --agent o un --connection, nunca un rol) y --expires <iso> (marca de tiempo de revocación automática). --principal filtra una lista y acepta user:<id>, group:<id>, service_account:<id>, project:<id> o pending:<email>; un identificador sin más se interpreta como un usuario. Una concesión para todos aparece como everyone. La identidad de un agente es un service_account, por lo que --service-account <id> es la forma de asignar un rol a un agente. --user acepta un correo electrónico y lo busca en el directorio de miembros de la cuenta.

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…

Los verbos de miembros del proyecto son un modelo de lectura sobre las mismas asignaciones:

Todos los verbos de los dos bloques anteriores requieren project.members.manage.

Una persona, un grupo o un agente obtiene roles de Beeuni; además, un agente lleva permisos de Beeuni en beeuni.yaml, y una sesión solo puede hacer lo que ambos permiten. Consulta Un vocabulario, dos vinculaciones.

Auditoría

Los comandos de auditoría leen el registro centralizado de reconstrucción. Las listas de cuentas y proyectos aparecen primero con los elementos más recientes. La cronología de una sesión sigue el orden de creación (session_sequence solo se establece en las filas escritas antes de 2026-10, que aparecen primero). --all sigue cada cursor de continuación. ls muestra los últimos 90 días; export retrocede 365 días, y los eventos de más de 90 días provienen del archivo (consulta Retención de auditorías). La tabla muestra el título de cada fila (EVENT, por ejemplo, «Clave de pasarela LLM revocada») junto a su ACTION (gateway.key.revoke); --action filtra por prefijo de acción. Todas las acciones y títulos: Acciones del registro de auditoría.

Los webhooks de auditoría transmiten el registro a un SIEM. Todos los verbos requieren account.write; add y enable también requieren el derecho de uso empresarial. disable y rm nunca lo requieren.

Filtros: --actor, --actor-type, --project, --session, --source, --phase, --outcome, --action, --resource-type, --request-id, --correlation-id, --query, --since, --until, --cursor y --limit. Las listas y exportaciones de cuentas requieren audit.read y el derecho de uso auditAccess de la cuenta. Las listas de todo el proyecto requieren project.members.manage porque pueden incluir metadatos de sesiones privadas. La reconstrucción de sesiones requiere project.session.read y visibilidad de esa sesión.

Roles

Un rol es un conjunto de permisos con nombre. Los roles del sistema (owner, admin, member en el ámbito de la cuenta; manager, member en el ámbito del proyecto; además de agent-user, el marcador que lleva una asignación de objeto) son referencias de solo lectura. Puedes crear y editar roles personalizados, que requieren el derecho de uso empresarial rbac.

Vincula un rol a un principal con beeuni access grant. Los verbos anteriores beeuni roles assign / unassign / assignments siguen funcionando y escriben en la misma tabla, pero beeuni access es la forma documentada. beeuni roles actions fue reemplazado por beeuni permissions ls.

Un rol personalizado solo agrega permisos. Beeuni no tiene reglas de denegación, así que un rol no puede retener permisos de un administrador.

Permisos

El catálogo de permisos, como datos. Una fila por acción de nivel inferior, con el ámbito en el que se decide, si se puede delegar y qué implica. Los roles se crean a partir de estas claves: beeuni roles create --actions y beeuni roles set-actions aceptan exactamente estas claves. Alias: beeuni perms.

Concesiones

Asigna un objeto del proyecto a un principal: una asignación de objeto. Los secretos y conectores residen en los agentes, así que asignar un agente a una persona le concede todo lo que ese agente declara. De forma predeterminada, el acceso a un agente está cerrado: un miembro solo puede acceder a él cuando una asignación lo incluye a él o a uno de sus grupos. beeuni access grant --agent <name> escribe la misma fila.

Validación del manifiesto

Consulta Referencia del manifiesto.

Tamaño del repositorio

Una sesión crea su configuración del agente a partir de todos los archivos que Git sigue en la confirmación base. Una sesión nueva obtiene esos archivos de su propia copia de trabajo, sin importar el tamaño. Una sesión en ejecución incorpora los cambios de la rama base mediante la instantánea del proyecto, que Beeuni Cloud compila hasta 512 MiB comprimidos; por encima de ese límite, la sesión conserva la configuración que está usando hasta que se inicia una sesión nueva. Además, todas las sesiones descargan todos los archivos. beeuni validate cuenta los archivos almacenados por Git, además de los archivos sin seguimiento que beeuni ship incluirá en la próxima confirmación, y muestra una advertencia si un archivo pesa 10 MiB o más, o si el total supera los 512 MiB. Un archivo de Git LFS cuenta como su puntero, porque la versión solo contiene el puntero. La advertencia indica cuáles son los archivos más grandes. Nunca hace que falle el comando.

Para eliminar la advertencia:

• Traslada los recursos estáticos grandes (vídeos, imágenes, conjuntos de datos, pesos de modelos) a un almacenamiento de objetos como S3, R2 o GCS, o a una CDN, y descárgalos en tiempo de ejecución.
• Añade el resultado de la compilación (dist/, out/) a .gitignore.
• Para las rutas que deban permanecer en Git pero que ningún agente lea, añade <path> export-ignore a .gitattributes. La versión las omite, al igual que esta comprobación; una regla para un directorio abarca todo lo que contiene. El directorio de configuración del agente y beeuni.yaml siempre se incluyen completos.

Ámbito del token

Cada token empieza con beeuni_pat_. Un token de usuario tiene alcance en todos los proyectos de tus cuentas. Un token de proyecto tiene alcance en un solo proyecto y se inyecta automáticamente en los entornos aislados de ese proyecto. Consulta la referencia completa de familias de tokens en Entorno de ejecución de sesión.

Códigos de salida