OpenMausBot es una aplicación de chat donde cada contacto de la barra lateral es un agente con su propio modelo, la memoria de su propio hilo y su propio ordenador. Es Apache-2.0, ejecuta los CLI claude y codex que ya pagas, y se creó el 11 de agosto de 2026. El 9 de noviembre de 2026 tenía 18.250 estrellas, 9.211 commits, 106 versiones publicadas y 1.068.158 líneas de código repartidas en 5.793 archivos.
Son las cifras de un proyecto que creció más rápido que casi cualquier otro de la categoría este año, y la pregunta interesante no es si es real. Lo es. La pregunta es dónde está la frontera de seguridad, porque toda la propuesta consiste en entregarle a una plantilla de agentes un shell, un navegador y tus claves de API, y luego aprobar lo que importe.
Esta auditoría lee los archivos del propio repositorio —el detector del sandbox, las etapas del Dockerfile, la excepción de licencia, la política de seguridad, el documento de niveles de aprobación— y de todos ellos sale el mismo número: la capa de contención son 2.108 líneas de código sin tests, y viene desactivada por defecto en todas partes menos en la nube de la empresa.
La forma de 89 días
| Métrica | Medido (2026-11-09) |
|---|---|
| Estrellas / watchers | 18.250 / 44 (0,24%) |
| Forks / forks por estrella | 2.534 / 13,9% |
| Creación → último push | 2026-08-11 → 2026-11-08 |
| Commits | 9.211 (103,5 al día) |
| Commits del autor principal | 5.304 (57,6%) |
| Versiones | 106 (la primera, 2026-09-01), etiquetas hasta v0.1.149 |
| Archivos adjuntos de las versiones | 2.188 archivos, 322,5 GB |
| Líneas de código (sin tests) | 558.362 en 3.275 archivos |
| Líneas de tests | 509.796 en 2.518 archivos (0,91:1) |
| Documentación | 251 archivos Markdown, 52.089 líneas |
| Issues abiertas / cerradas | 576 / 471 |
| PR abiertas / cerradas | 252 / 3.708 |
| Licencia | Apache-2.0, con una excepción en enterprise/ |
La numeración de etiquetas merece una nota. Las versiones se detienen en 106, pero la etiqueta de la última es v0.1.149. Cuarenta y tres números se los comieron compilaciones que nunca produjeron una versión: es lo que parece un pipeline de publicación cuando una sola persona publica varias veces al día y algunos intentos fallan. El instalador más grande de la última versión pesa 320.504.332 bytes (el .dmg para Apple silicon) y el .deb, 274.742.204 bytes. Entre las 106 versiones hay 2.188 archivos adjuntos que suman 322,5 GB.
Dos números no encajan en la historia habitual. El primero son los 44 watchers: el 0,24% de las estrellas. Un watcher es alguien que pidió que le avisaran; una estrella es alguien que hizo clic una vez. En las auditorías anteriores de este sitio esa proporción ha sido la señal más útil, y 0,24% está en el suelo del rango. El segundo son las 576 issues abiertas, presentadas a unas 24 por día en los primeros nueve días de noviembre. Los proyectos que solo acumulan marcadores no generan 24 peticiones de soporte diarias. Los dos hechos son ciertos a la vez y ninguno cancela al otro.
Si has visto citado «828 issues abiertas», esa cifra viene de open_issues_count de GitHub, que suma las pull requests abiertas a las issues. El reparto real es 576 issues y 252 PR.
Qué es exactamente el bot box
docs/bot-box.md describe la capa de contención sin marketing. En una máquina de MausBot Cloud, cada turno de un bot corre en un sandbox sin privilegios de bubblewrap:
el motor (Claude Code, Codex, Grok, OpenCode, los agentes ACP), cada comando de shell que ejecuta, los servidores MCP que arranca y los proxies auxiliares de OpenMausBot viven dentro de un único sandbox bubblewrap sin privilegios durante la vida de ese proceso. El servidor, su base de datos, su configuración, las carpetas de otros bots y los procesos de otros turnos no están dentro.
Dentro de la caja, /usr, /etc y /opt son de solo lectura; HOME es escribible para que los motores conserven sus sesiones; la carpeta de datos ~/.openmausbot se sustituye por «una carpeta privada vacía»; la carpeta de trabajo del turno y workspaces/<bot> vuelven a montarse en lectura-escritura; /tmp, /run, /dev y /proc son espacios de nombres privados. La red es un espacio de nombres solo con loopback y dos puentes: un proxy de salida en 127.0.0.1:3128 que rechaza por dirección esta máquina, la red local, link-local, el servicio de metadatos de la nube y la red privada de Fly, y una compuerta del harness que deja a la caja alcanzar solo /api/internal/ y responde 403 a todo lo demás por sí misma, sin preguntar al servidor.
La lista de capas es inusualmente concreta: espacio de nombres de montaje, de PID, las dos compuertas de red, una lista blanca de variables de entorno, un broker de credenciales, un filtro seccomp que bloquea 34 llamadas al sistema, hidepid=invisible en el /proc del host y un /.fly solo para root. La autocomprobación es de verdad: node dist-server/bot-box/box-check.js ejecuta box-probe.ts dentro de una caja viva sobre un fixture con forma de carpeta de datos, con un proceso canario y un servidor de prueba, y cuenta qué podría alcanzar todavía un bot hostil: 23 comprobaciones por defecto, 29 cuando se suman las seis del broker de credenciales.
Y entonces el documento hace algo que casi nadie hace: publica una tabla de lo que cada capa no detiene.
| Capa | Hueco admitido |
|---|---|
| Espacio de nombres de montaje | leer las sesiones de los motores en HOME (la identidad del propio motor); una ruta que un driver vuelve a poner a propósito |
| Espacio de nombres de PID | nada dentro de la misma caja |
| Red y compuertas | lo que permitan las rutas del harness con un bearer válido por turno; un destino público |
| Lista blanca de entorno | la configuración de los propios motores |
| Broker de credenciales | claves sin ajuste de URL base (las nombra el informe); sesiones de suscripción |
| seccomp | «todo lo que usan un motor, un shell, git, npm, python o Chrome: permitido» |
El documento también explica qué no se construyó y por qué: un usuario Linux separado por bot, porque «el servidor corre como maus bajo un supervisor root y no puede cambiar de uid», y reglas de nftables, porque «no añadirían nada a una caja con su propio espacio de nombres de red». Ese párrafo dice más del criterio de ingeniería que cualquier lista de funciones.
La capa entera es server/bot-box/: 3.953 líneas en 19 archivos contando tests, de las cuales 1.845 son tests. 2.108 líneas de código real, frente a 558.362 líneas de código en el repositorio. El sandbox es el 0,38% del código y es la pieza que decide si un agente puede borrar tus archivos.
El valor por defecto es «not-cloud»
server/bot-box/detect.ts tiene 90 líneas y lo decide todo:
export function detectBox(input: DetectInput): BoxDetection {
const wanted = boxWanted(input.env);
if (wanted === "off") return { box: "off", reason: "switched-off", tools: null };
if (wanted === "default" && !cloudRole(input.env)) return { box: "off", reason: "not-cloud", tools: null };
if ((input.platform ?? process.platform) !== "linux") return { box: "off", reason: "not-linux", tools: null };
const which = input.which ?? ((name) => whichOnPath(name, input.env));
const bwrap = which("bwrap");
if (!bwrap) return { box: "off", reason: "no-bwrap", tools: null };
if (!(input.probe ?? probeBwrap)(bwrap)) return { box: "off", reason: "userns-refused", tools: null };
return { box: "bwrap", reason: null, tools: { bwrap, socat: which("socat") } };
}
cloudRole solo es cierto cuando OMB_CLOUD_ROLE vale home o team. Con la variable sin definir —una instalación de escritorio, un servidor en un VPS arrancado con npx openmausbot serve, un contenedor Docker— la tercera línea devuelve {box: "off", reason: "not-cloud"} y nada de lo que sigue se ejecuta.
La documentación lo dice sin rodeos: «activada por defecto en una máquina Cloud (OMB_CLOUD_ROLE=home o team), desactivada en todo lo demás salvo OMB_BOT_BOX=1». Así que quien se autoaloja puede encenderla. Lo que ocurra después depende de un detalle del Dockerfile que cuesta más ver.
La imagen con la que te autoalojas no lleva bwrap
El repositorio tiene un Dockerfile con seis etapas. runtime (línea 72) instala las bibliotecas de Chrome, git, curl, fonts-noto-cjk y un binario de agent-browser con su Chrome fijado: y ningún bubblewrap. cloud-home (línea 129) es FROM runtime y los añade:
&& apt-get install -y --no-install-recommends python3 poppler-utils unzip bubblewrap socat \
server (línea 219) vuelve a ser FROM runtime, y es la última etapa del archivo, lo que la convierte en el objetivo de compilación por defecto. El flujo de CI ejecuta docker build -t openmausbot:ci . (sin --target), arranca ese contenedor y después lo etiqueta como ghcr.io/milind-soni/openmausbot:latest. La imagen sobre la que construye deploy/local/Dockerfile, la que usa compose.yaml, es FROM ${BASE_IMAGE} con ghcr.io/milind-soni/openmausbot:latest como base por defecto, y añade tres cosas: los CLI de los motores, Grok y USER maus. No añade bwrap.
La imagen de la nube se publica en otro repositorio distinto —ghcr.io/milind-soni/openmausbot-cloud-home, compilada con target: cloud-home, y el Admin de la nube la fija por digest—.
Junta los dos hechos y la ruta de autoalojamiento se resuelve así: activa OMB_BOT_BOX=1 en el despliegue de compose y whichOnPath("bwrap") no encuentra nada, de modo que detectBox devuelve {box: "off", reason: "no-bwrap"}. La variable está documentada, la ruta de código existe, y la imagen que te dijeron que ejecutaras no puede satisfacerla. Una instalación nativa en Linux con bubblewrap instalado desde la distribución es la configuración donde la caja puede funcionar, más un kernel que permita espacios de nombres de usuario sin privilegios.
Esta máquina, Debian 13 dentro de un contenedor, es un buen ejemplo de cómo falla la segunda condición:
$ bwrap --version
bash: bwrap: command not found
$ unshare -Ur true
unshare: unshare failed: Operation not permitted
probeBwrap ejecuta exactamente ese conjunto de espacios de nombres —--unshare-user --unshare-pid --unshare-net --unshare-ipc --unshare-uts más --ro-bind /usr /usr y /bin/true—, así que en un host como este la caja informa userns-refused incluso después de instalar bwrap. Las distribuciones que restringen los espacios de nombres de usuario sin privilegios por defecto (Ubuntu 24.04 y posteriores, entre ellas) dan la misma respuesta. La documentación también es honesta aquí: «nunca se activa sin un bubblewrap sin privilegios que funcione: si el kernel rechaza los espacios de nombres de usuario o la imagen no tiene bwrap, la caja informa off con el motivo».
Lo que ninguna documentación conecta es la distancia de cuatro pasos entre «aplicación local gratuita» y «la contención que tiene la nube». docs/self-hosting.md —más de 1.300 líneas sobre proxies inversos, emparejamiento, listas de acceso y el safety floor— no menciona ni una vez bot-box, OMB_BOT_BOX ni bubblewrap. El único archivo que documenta la caja es docs/bot-box.md, y solo lo enlazan otros dos (team-cloud.md y custom-mcp-servers.md), ninguno de los cuales es lo primero que lee quien se autoaloja.
Hay un efecto de segundo orden en el gestor de incidencias. La issue #4983 informa de que con OMB_BOT_BOX=1 y la VM local como ordenador del bot, una llamada de uso del ordenador falla con «MCP server exited», porque la caja no tiene /var/run/docker.sock y container-mcp.js ejecuta docker exec dentro del contenedor de la VM. La caja y la VM local son, en la práctica, mutuamente excluyentes. La segunda petición de quien la reporta es reveladora: «La limitación está documentada. docs/bot-box.md cubre MausBot Cloud pero no este caso».
La capa de consentimiento, leída con cuidado
El bot box no es la única protección, y OpenMausBot se esfuerza en distinguir las dos. El broker de permisos convierte las peticiones de herramientas en tarjetas de aprobación; el safety floor es «una lista corta de nunca» que ninguno de los dos puede responder. Ambas están documentadas con sus huecos, y los huecos son lo bastante grandes como para que convenga conocerlos antes de instalar.
El safety floor viene apagado. server/safety-floor-gate.ts lo dice en un comentario y lo aplica: return env.OMB_SAFETY_FLOOR?.trim() === "1" || cfg.safetyFloor?.enabled === true. server/config.ts repite la nota. Su lista es estrecha —borrado recursivo de /, de ~, de un directorio de sistema de primer nivel, mkfs sobre un dispositivo, diskutil eraseDisk, dd of=/dev/sda, una redirección hacia un dispositivo de disco, una fork bomb— y la documentación lo dice: «Crear un sistema de archivos en un archivo de imagen o en un dispositivo loop no está en la lista».
En Windows el floor no está apagado: es un no-op que acepta el ajuste.
Todavía no se aplica en un servidor Windows. Allí el ajuste se acepta y no hace nada: ningún comando se comprueba, se deniega ni se retiene, y cada aprobación se comporta como con el ajuste desactivado.
El servidor escribe una línea en el arranque e informa safetyFloor.enabled: false. El motivo es que no sabe distinguir cmd, PowerShell y Git Bash. Y el floor solo ve los comandos por los que alguien pregunta:
Un motor que corre en su propio modo sin preguntas nunca envía una petición, así que el floor no ve el comando: con acceso Full eso es Claude Code (
bypassPermissions), Codex (aprobaciones desactivadas) y los agentes ACP arrancados en su propio modo yolo. Trátalo como una red bajo comandos guardados y bots con clave de API, no como un sandbox.
El nivel de aprobación por defecto convierte esa frase en algo que sostiene peso. docs/approval-levels.md: «Cada bot y cada conversación empiezan en Full access, el mismo valor por defecto que usa T3 Code: cada motor corre en su modo más permisivo, y una pregunta real o una credencial que falte siguen llegándote». La constante es DEFAULT_APPROVAL_MODE en shared/approval-mode.ts. Full access «se aplica en el momento en que lo eliges: sin diálogo de confirmación, sin segundo paso», responde por ti las «peticiones de permiso nativas residuales» y se salta las peticiones de revisión entre pares dentro del ámbito del bot. El nivel de un Chief of Staff además «fluye hacia abajo» a cada bot al que delega, salto tras salto.
Así que la configuración por defecto en un portátil es: un bot en Full access, su motor en bypassPermissions, el safety floor apagado, ninguna caja porque reason: "not-cloud" en macOS y Windows sin importar nada, ninguna caja en Linux sin una variable de entorno y un espacio de nombres de usuario que funcione, y las claves de API guardadas «en texto plano, sin cifrar, en un config.json privado (0600 en Unix)».
Nada de eso es secreto. Son tres documentos distintos siendo precisos. También es, desde el punto de vista de quien lee, una configuración donde la frase «el broker de permisos convierte cada acción arriesgada en una decisión tuya» describe lo que pasa cuando el motor decide preguntar, no lo que pasa cuando no lo hace.
El riesgo que el proyecto escribió sobre sí mismo
El párrafo más valioso del repositorio está en SECURITY.md, bajo «Notas de alcance para investigadores»:
Conocido y documentado, todavía no cerrado: ese llamador conserva las rutas protegidas del worker de Slack, así que el shell de un bot puede publicar en un hilo con acceso Full ya existente, o abrir uno mientras el acceso Full compartido está activo, y conseguir trabajo con acceso Full sin tarjeta. Un token de retransmisión solo para el worker es la corrección prevista.
El comentario correspondiente en server/request-auth.ts es más largo y nombra el mecanismo: en un espacio de trabajo alojado o compartido, el loopback sin sesión obtiene confianza service y solo puede alcanzar SERVICE_ALLOW; pero «el shell de un bot también es un llamador de loopback, así que puede hacer todo lo que hace el worker de Slack: publicar en el hilo de cualquier bot por la ruta protegida, incluido un hilo con acceso Full existente, abrir hilos nuevos con acceso Full mientras el acceso Full compartido del operador está activo, detener una petición y rechazar una tarjeta».
Léase la cláusula secundaria, porque es la que importa: mientras el acceso Full compartido del operador está activo. La mitigación documentada es operativa, no técnica: activar el acceso Full compartido solo donde todos los usuarios puedan tener acceso Full. La corrección prevista es un token que solo tenga el worker de Slack. No hay fecha.
Pueden ser ciertas dos cosas a la vez. Un proyecto de tres meses y un millón de líneas que publica su propio fallo de frontera de privilegios sin arreglar, con el comentario de código nombrando las rutas exactas, es una práctica que la mayoría de los productos comerciales no sigue. Y quien decide dónde correr agentes no debería tratar una nota de «conocido y todavía no cerrado» como un elemento cerrado.
Dónde está de verdad la frontera de pago
Los proyectos open core suelen poner la mejor función detrás de la licencia. Este hace algo más estructural: la excepción es diminuta y el dinero está en otro sitio.
LICENSING.md es explícito. Todo lo que hay bajo enterprise/ está disponible como código bajo la OpenMausBot Enterprise License, no Apache-2.0: «Puedes leerlo, compilarlo y evaluarlo, y ejecutarlo libremente en desarrollo y pruebas. Ejecutar sus funciones en producción requiere una clave de licencia emitida para tu organización. Alojarlo para terceros o practicar white-labeling requiere un acuerdo de partner». Borra la carpeta y el servidor informa {"edition":"oss"}.
Ahora mide la carpeta. enterprise/ contiene 10 archivos y 957 líneas: el 0,17% del código. Su archivo FEATURES lista cuatro identificadores de derecho ya publicados: whitelabel (nombre de producto, eslogan, color, logo y enlace de soporte desde brand.json), admin (instalaciones y el adaptador de inicio de sesión alojado), budgets (un tope mensual de gasto por espacio de trabajo, «un tope por espacio, no por bot») y billing (precios de venta por modelo, una columna facturable en Usage y su CSV). Un quinto, sso, sigue en «planned», y el archivo avisa de que «las claves pueden llevar identificadores que aún no están publicados; los identificadores desconocidos no otorgan nada».
La regla de enrutamiento está mejor formulada que en la mayoría de las políticas open core: «¿podría quererlo cualquier usuario de código abierto? Entonces va al núcleo, como pull request pública. ¿Tiene sabor de organización, administración o nivel? Entonces vive en enterprise/ detrás de un derecho».
Así que el producto que venden no es el código. Es la máquina:
| Plan | Precio | Máquina | Horas de ordenador | Notas |
|---|---|---|---|---|
| Free | 0 $ | tu propio ordenador | — | Apache-2.0, todos los modelos con tu clave |
| Starter | 15 $/mes | 2 vCPU · 2 GB | 100 | 2.000 eventos de app al día, 20 GB |
| Pro | 49 $/mes | 4 vCPU · 4 GB | 300 | 10 $/mes de crédito Claude, 100 GB |
| Max | 99 $/mes | 8 vCPU · 8 GB | 800 | 20 $/mes de crédito Claude |
| Team | 169 $/mes | 8 vCPU · 8 GB + 4 GB swap | 1.000 | hasta 5 usuarios |
| Business | 599 $/mes | 8 vCPU · 8 GB + 4 GB swap | 3.000 | hasta 20 usuarios |
| Business self-hosted | 299 $/mes | tu hardware | trabajo de bots ilimitado | hasta 20 usuarios |
El exceso cuesta 0,05 $ por hora de ordenador, un ordenador pequeño cuenta como media hora, y el uso razonable limita a 15 ordenadores en la nube simultáneos. Las copias de seguridad se guardan 14 días en todos los niveles. La máquina de la nube es una app de Fly con una máquina, un volumen en /data y TLS en https://<app>.fly.dev: un cliente, una máquina, y por eso el sandbox puede estar activado por defecto allí y en ningún otro sitio.
Es un negocio coherente: no pagas por el código del sandbox, pagas por una máquina Linux donde el sandbox puede correr. El problema es puramente informativo. Quien descarga la aplicación gratuita lee «local first» y «tu propia máquina» y concluye razonablemente que la postura de seguridad es parecida. No es la misma postura: es otra ruta de código que devuelve otro motivo.
De dónde salen 18.250 estrellas
La explicación habitual —un lanzamiento que encontró público— no tiene aquí su evidencia. Hacker News tiene tres envíos de este proyecto, los días 28, 29 y 30 de octubre, con 2, 1 y 3 puntos y cero comentarios. Un proyecto con 18.250 estrellas, 44 watchers y ninguna discusión en portada no se está descubriendo como se descubren normalmente los proyectos de código abierto.
Lo medible es el sitio. La página de inicio lleva diecinueve testimonios, uno de ellos «He contribuido dos PR antes», y la de precios abre con «Un equipo de IA que trabaja mientras duermes». El README del repositorio abre con un aviso que casi ningún proyecto necesita:
Sin afiliación con ninguna criptomoneda. OpenMausBot no tiene token. Cualquier moneda que use el nombre OpenMausBot, Maus o SupaMaus no ha sido creada, respaldada ni afiliada a este proyecto ni a su mantenedor.
Un proyecto que tiene que decir eso se ha encontrado con internet. También es una explicación parcial plausible de un recuento de estrellas que va por delante de todas las demás señales: las comunidades de tokens se pegan a los nombres, y el repositorio se convierte en un punto de referencia lo ejecute alguien o no.
No estoy afirmando que las estrellas se compraran; no hay evidencia de eso, y el historial de commits, las 471 issues cerradas y las 3.708 PR cerradas no son obra de un proyecto de vanidad. Digo que las estrellas son la única métrica que no concuerda con el resto, y el resto está inusualmente bien instrumentado.
Qué dicen los números sobre la carga de soporte
Un ritmo de 24 incidencias diarias en un proyecto de 89 días es un problema de carga, y el gestor lo muestra.
| Medida | Valor |
|---|---|
| Issues abiertas / presentadas alguna vez | 576 / 1.047 (55% aún abiertas) |
| Issues abiertas de la muestra sin ningún comentario | 349 de 501 (69,7%) |
| Comentarios en 501 issues abiertas | 239 (mediana 0, máximo 14) |
| Antigüedad mediana de una issue abierta | 11,1 días (máximo 60) |
| Issues presentadas del 1 al 9 de noviembre | 217 |
Issues abiertas con la etiqueta bug | 32 de 576 |
| PR cerradas | 3.708 |
Cincuenta y dos issues en la primera página del gestor, diez comentarios entre todas. Los títulos son concretos y útiles —«openai-compat nunca reintenta un fallo transitorio: 7 de 8 llamadores de createOpenAIChatRuntime dejan retryScale sin definir», «El túnel del visor SSH sale de inmediato (exit 0) en despliegues Docker en el mismo host con Linux», «iOS: el teléfono puede autobloquearse durante una nota de voz, lo que detiene la grabación en silencio»— y la mayoría están sin respuesta. Las palabras clave de los títulos se inclinan hacia plataformas: 47 de 501 mencionan inicio de sesión, 43 iOS, 36 MCP o conectores, 33 Cloud, 31 cuelgues, 23 Windows, 22 Android, 16 macOS, 13 Linux.
Las etiquetas apenas se usan, así que «32 de 576 tienen bug» no mide densidad de errores sino triaje. Tres mil setecientas ocho PR cerradas frente a 471 issues cerradas es la otra mitad del cuadro: este proyecto fusiona cambios mucho más rápido de lo que responde preguntas. Para quien lee, eso cambia el cálculo de adoptarlo: la corrección que necesitas puede estar ya fusionada, y la pregunta que hagas puede no recibir nunca respuesta.
Guía de decisión según el perfil
Quieres probarlo en un portátil. Instálalo y haz dos cosas de inmediato: poner cada bot en «Ask for approval» y tratar la aplicación como una herramienta con todos los privilegios de tu usuario, porque eso es lo que tiene. En macOS y Windows no hay caja ni puede haberla; en Linux hay una si instalas bubblewrap y defines OMB_BOT_BOX=1, y si tu kernel permite espacios de nombres de usuario. No lo pongas en una máquina que guarde credenciales que no le darías a un script de shell.
Quieres autoalojar en un VPS y mantener a los agentes contenidos. Usa una distribución con bubblewrap disponible, define OMB_BOT_BOX=1, define OMB_LOOPBACK_TRUST=service si alguien más comparte la máquina, define OMB_SAFETY_FLOOR=1, y no uses la imagen oficial openmausbot:latest como base sin añadir tú mismo bubblewrap y socat: la imagen se compila desde la etapa server, que no los incluye. Después ejecuta la autocomprobación y cree a su informe, no a este artículo.
Eres un equipo. La frontera de pago es la honesta: el plan de nube es donde la caja está activada por defecto y donde existe la política de acceso Full compartido del operador. Si te autoalojas para un equipo, el hueco de las rutas del worker de Slack de SECURITY.md te afecta, y la mitigación documentada es mantener el acceso Full compartido apagado salvo que todos puedan tenerlo.
Compruébalo tú
Todo lo anterior se verifica en diez minutos, y las comprobaciones son la parte útil de este artículo:
- ¿Está el floor activo?
curl -s 127.0.0.1:8799/api/config | jq '.safetyFloor'—{"enabled": false}en una instalación nueva, y siempre false en un servidor Windows. - ¿Está la caja activa, y si no, por qué?
node dist-server/bot-box/box-check.jsimprime el tipo de caja, el código de motivo (not-cloud,no-bwrap,userns-refused,not-linux) y el número de comprobaciones.{"box": "off", "reason": "not-cloud"}es la respuesta en una instalación local sin variables. - ¿Puede este kernel ejecutarla?
bwrap --versionyunshare -Ur true. Un error de permisos significa queprobeBwrapdevolverá false digas lo que digas. - ¿Tu imagen trae el binario?
docker run --rm <imagen> sh -c 'command -v bwrap || echo MISSING'. Laopenmausbot:latestpublicada se compila desde la etapaserver; la que lo instala es la etapacloud-home. - ¿Qué edición ejecutas?
curl -s 127.0.0.1:8799/api/editiondevuelve{"edition":"oss"}cuandoenterprise/no está o no tiene licencia. - ¿Cuál es el nivel de aprobación por defecto de un bot nuevo? Crea uno y míralo antes de chatear. Debería decir Full access; si no, ya hay una política en vigor y conviene saber cuál.
- ¿Están cifradas tus claves? No.
ls -l ~/.openmausbot/config.jsondebería ser0600, y el archivo contiene claves en texto plano por diseño.
Preguntas frecuentes
¿OpenMausBot es realmente código abierto?
Sí, con una excepción. Apache-2.0 cubre todo menos enterprise/, que está disponible como código bajo una licencia que exige una clave para producción y un acuerdo de partner para alojarlo para terceros. Esa carpeta son 10 archivos y 957 líneas. Bórrala y el servidor informa la edición OSS.
¿El bot box es un contenedor o una máquina virtual?
Ninguno de los dos. Es un conjunto de espacios de nombres de Linux creados con bubblewrap, más un filtro seccomp, una lista blanca de entorno, un broker de credenciales y dos compuertas de loopback. No hay frontera de hipervisor, y la documentación no la reclama.
¿Por qué está apagado el sandbox en mi portátil?
Porque detectBox devuelve not-cloud cuando OMB_CLOUD_ROLE no está definida. En macOS y Windows devolvería not-linux incluso con la variable puesta, porque bubblewrap es solo de Linux. En Linux puedes activarlo con OMB_BOT_BOX=1 si bwrap existe y el kernel permite espacios de nombres de usuario sin privilegios.
Si me autoalojo con la imagen Docker, ¿tengo el sandbox?
No tal como viene. El objetivo de imagen por defecto es server, compilada FROM runtime, y runtime no instala bubblewrap. El objetivo cloud-home sí lo hace, y se publica aparte. Añade bubblewrap y socat a tu propia imagen, o ejecuta en un host que los tenga.
¿Full access significa que el bot puede hacer cualquier cosa?
Dentro de tu cuenta de usuario, en buena medida sí: pasa el modo permisivo del proveedor (bypassPermissions, aprobaciones desactivadas, yolo), responde por ti las peticiones residuales y se salta las de revisión entre pares. El safety floor es una lista aparte, apagada por defecto, que no ve los comandos de motores en esos modos sin preguntas.
¿Es fiable el número de 18.250 estrellas? Es lo que informa GitHub. También es la única métrica que no concuerda con las demás: 44 watchers, tres envíos a Hacker News con un máximo de 3 puntos y un párrafo del README que niega un token de criptomoneda. Trata las estrellas como descripción de atención, no de adopción.
La frontera es el modelo de negocio, y la documentación lo dice
La ingeniería no es el problema. Un sandbox de 2.108 líneas con una tabla publicada de «lo que no detiene», una autocomprobación de 29 verificaciones, una decisión documentada de no construir usuarios por bot, y una política de seguridad que nombra su propio fallo abierto de privilegios es más divulgación de la que producen la mayoría de los proyectos financiados en una década. La proporción de 0,91:1 entre tests y código y las 52.089 líneas de documentación no son obra de alguien que publica una demo.
El problema es un valor por defecto que ningún documento aislado declara en un solo lugar. Lee el README y tienes «local first» y un broker de permisos que «convierte cada acción arriesgada en una decisión tuya». Lee bot-box.md y tienes contención. Lee detect.ts y descubres que son configuraciones distintas, separadas por una variable de entorno, un binario que la imagen de autoalojamiento omite, un ajuste del kernel y una suscripción.
Si lo evalúas para un portátil, instálalo, ajusta los niveles de aprobación y asume que el shell es tuyo. Si lo evalúas para un equipo, decide de antemano si estás comprando la máquina: porque es el único lugar donde el aislamiento se diseñó para sostenerse, y por 15 $ al mes sale más barato que la ingeniería que harías para reproducirlo.
Fuentes: el repositorio milind-soni/OpenMausBot en su estado del 2026-11-08 (README.md, LICENSING.md, SECURITY.md, Dockerfile, compose.yaml, deploy/local/Dockerfile, docs/bot-box.md, docs/self-hosting.md, docs/approval-levels.md, server/bot-box/detect.ts, server/request-auth.ts, server/safety-floor-gate.ts, enterprise/FEATURES, .github/workflows/docker.yml), la API de GitHub leída el 2026-11-09 y openmausbot.com/pricing. Auditorías relacionadas en este sitio: Astryx de Meta, agent-desktop, gstack, Worktrunk y NVIDIA Auto-Ontology.