Open Computer Use

Open Computer Use

Servidor MCP que le da a cualquier LLM su propia computadora: espacios de trabajo Docker gestionados con navegador en vivo, terminal, ejecución de código, habilidades de documentos y subagentes autónomos. Autohospedado, de código abierto, conectable a cualquier modelo.

Demo en línea: lab.widemoat.ai — Open WebUI con Computer Use ya configurado, inicia sesión con GitHub o Google. (Más formas de probarlo abajo.) La dirección anterior chat.yambr.com redirige aquí y seguirá haciéndolo.

Hacia dónde va este proyecto. Open Computer Use se propuso responder una pregunta: ¿se le puede dar a un LLM una computadora real con la seguridad suficiente para que sea útil? La respondió, y se usa en producción. Ese resultado nos llevó a otra parte: Wide Moat, una plataforma de IA empresarial que funciona dentro del perímetro de la propia empresa. Es un producto diferente, no una reescritura de este, y actualmente se desarrolla de forma privada.

En la práctica, para ti:

• Este repositorio sigue funcionando. Se mantiene: correcciones, actualizaciones de dependencias y seguridad, y soporte para las versiones de Open WebUI a las que apunta. No está abandonado ni obsoleto.
• El ritmo de nuevas funciones se ralentiza. Nuestra atención se ha trasladado a la plataforma, y es honesto decirlo de entrada en lugar de dejarte adivinando por las fechas de los commits.
• La promesa de licencia se mantiene. FSL-1.1-Apache-2.0: úsalo, hazle fork, autohospédalo, redistribúyelo — y cada versión se convierte a Apache-2.0 dos años después de su publicación, hagamos lo que hagamos después. Nada de esto puede quitártelo.

Vale la pena seguir esto si te gusta este proyecto: un sandbox integrado de forma nativa en Open WebUI, en lugar de acoplado mediante un filtro y una herramienta, es una de las cosas que se están construyendo en la plataforma. Prueba el laboratorio alojado en lab.widemoat.ai o lee más en widemoat.ai.

Si algo de esto te resulta útil, una ⭐ en el repositorio ayuda de verdad: ¡gracias!

¿Qué es esto?

Un servidor MCP que le da a cualquier LLM un sandbox de Ubuntu completamente equipado con contenedores Docker aislados. Piénsalo como la computadora de tu IA: puede hacer todo lo que un desarrollador puede hacer:

• Ejecutar código — bash, Python, Node.js, Java en contenedores aislados
• Crear documentos — Word, Excel, PowerPoint, PDF con estilo profesional mediante habilidades
• Navegar por la web — Playwright + navegador CDP en vivo (ves lo que la IA ve en tiempo real)
• Ejecutar Claude Code — subagente autónomo con terminal interactiva, servidores MCP configurados automáticamente
• Usar más de 13 habilidades — flujos de trabajo probados en batalla para creación de documentos, pruebas web, diseño y más

Diseñado para despliegues multi-usuario en producción. Probado con más de 1,000 MAU. Cada sesión de chat se ejecuta en su propio contenedor Docker aislado: la IA puede instalar paquetes, crear archivos, ejecutar servidores, y nada se filtra entre usuarios. Funciona sin problemas en todos los clientes MCP: empieza con Open WebUI hoy, cambia a Claude Desktop o n8n mañana — mismo backend, sin migración.

Diferenciadores clave

Característica	Open Computer Use	Claude.ai (Claude Code web)	open-terminal	OpenAI Operator
Autohospedado	Sí	No	Sí	No
Cualquier LLM	Sí (compatible con OpenAI)	Solo Claude	Cualquiera (vía Open WebUI)	Solo GPT
Ejecución de código	Sandbox Linux completo	Sandbox (Claude Code web)	Sandbox / metal desnudo	No
Navegador en vivo	Transmisión CDP (compartida, interactiva)	Basado en capturas	No	Basado en capturas
Terminal + Claude Code	ttyd + tmux + CLI de Claude Code	Claude Code web (integrado)	PTY + WebSocket	N/D
Sistema de habilidades	13 integradas (inyección automática) + personalizadas	Habilidades integradas + instrucciones personalizadas	Nativo de Open WebUI (solo texto)	N/D
Aislamiento de contenedores	Docker (runc), por chat	Docker (gVisor)	Contenedor compartido (usuarios a nivel de SO)	N/D

Funciona con cualquier cliente compatible con MCP: Open WebUI, Claude Desktop, LiteLLM, n8n, o tu propia integración. Consulta docs/COMPARISON.md para una comparación detallada con alternativas.

Transmisión de navegador en vivo

Vista previa de archivos con habilidades

Diseño de frontend — página de aterrizaje renderizada en vivo en la pestaña del navegador

Presentaciones — sistema de diseño personalizado, no la plantilla blanca predeterminada

Crea tus propias habilidades — empaqueta trabajo recurrente en funciones reutilizables

Datos → gráfico con análisis

Claude Code — terminal interactiva en la nube

Panel de subagentes — monitorea y controla

Consulta docs/FEATURES.md para detalles de arquitectura y docs/SCREENSHOTS.md para todas las capturas de pantalla.

Consejo profesional: Crea habilidades con Claude Code en la terminal y luego úsalas con cualquier modelo en el chat. Las habilidades son independientes del modelo: escríbelas una vez, úsalas en todas partes.

Runtime de subagente multi-CLI (v0.9.2.1+): El despacho de subagentes admite Claude Code (predeterminado), OpenAI Codex y OpenCode (con OpenRouter / qwen / DeepSeek / más de 75 proveedores). Cambia SUBAGENT_CLI=claude|codex|opencode en .env — consulta docs/multi-cli.md para la receta completa de OpenCode + qwen3-coder + OpenRouter.

Arquitectura

Mirando hacia adelante: se está diseñando una arquitectura compatible con Kubernetes con datos de usuario respaldados por almacenamiento de objetos y habilidades empaquetadas en squashfs en docs/future-architecture/. Docker Compose sigue siendo la ruta principal compatible.

Formas de probarlo

Ruta	URL	Qué necesitas	Mejor para
Demo en línea gratuita — Open WebUI + Computer Use, modelos incluidos	lab.widemoat.ai	Inicio de sesión con GitHub o Google	Probarlo de principio a fin en 30 segundos
Autohospedado	Inicio rápido abajo	Docker, ~15 min la primera compilación	Control total, aislado, uso intensivo

Solo OAuth — sin correo/contraseña, sin SMS. En lab.widemoat.ai los modelos se incluyen como una conveniencia gratuita. El endpoint MCP alojado está fuera de línea durante la transformación; consulta docs/CLOUD.md.

Inicio rápido

git clone https://github.com/Wide-Moat/open-computer-use.git
cd open-computer-use
cp .env.example .env
# Edit .env — set OPENAI_API_KEY (or any OpenAI-compatible provider)

# 1. Start Computer Use Server (builds workspace image on first run, ~15 min)
docker compose up --build

# 2. Start Open WebUI (in another terminal)
docker compose -f docker-compose.webui.yml up --build

Abre http://localhost:3000 — Open WebUI con Computer Use listo para usar.

Nota: Dos archivos docker-compose separados: docker-compose.yml (Servidor de Computer Use) y docker-compose.webui.yml (Open WebUI). Se comunican vía localhost:8081. Esto refleja despliegues reales donde el servidor y la interfaz se ejecutan en hosts diferentes.

Configuración del modelo (¡importante!)

Después de agregar un modelo en Open WebUI, ve a Configuración del modelo y establece:

Configuración	Valor	Por qué
Llamada de funciones	Native	Requerido para que funcionen las herramientas de Computer Use
Transmisión de respuesta del chat	On	Habilita la transmisión de salida en tiempo real

Sin Function Calling: Native, el modelo no invocará las herramientas de Computer Use.

Qué hay dentro del sandbox

Categoría	Herramientas
Lenguajes	Python 3.12, Node.js 22, Java 21, Bun
Documentos	LibreOffice, Pandoc, python-docx, python-pptx, openpyxl
PDF	pypdf, pdf-lib, reportlab, tabula-py, ghostscript
Imágenes	Pillow, OpenCV, ImageMagick, sharp, librsvg
Web	Playwright (Chromium), CLI de Mermaid
IA	CLI de Claude Code, Playwright MCP
OCR	Tesseract (idiomas configurables)
Medios	FFmpeg
Diagramas	Graphviz, Mermaid
Desarrollo	TypeScript, tsx, git

Habilidades

13 habilidades públicas integradas + 14 ejemplos:

Habilidad	Descripción
pptx	Crear/editar presentaciones de PowerPoint con html2pptx
docx	Crear/editar documentos de Word con cambios rastreados
xlsx	Crear/editar hojas de cálculo de Excel con fórmulas
pdf	Crear, completar formularios, extraer, fusionar PDFs
sub-agente	Delegar tareas complejas a Claude Code
playwright-cli	Automatización de navegador y raspado web
describe-image	Análisis de imágenes con API de visión
frontend-design	Construir interfaces de usuario de nivel de producción
webapp-testing	Probar aplicaciones web con Playwright
doc-coauthoring	Flujo de trabajo estructurado de coautoría de documentos
test-driven-development	Aplicación de metodología TDD
skill-creator	Crear habilidades personalizadas
gitlab-explorer	Explorar repositorios de GitLab

14 habilidades de ejemplo: web-artifacts-builder, copy-editing, social-content, canvas-design, algorithmic-art, theme-factory, mcp-builder, y más.

Consulta docs/SKILLS.md para más detalles.

Integración MCP

El servidor habla MCP estándar sobre Streamable HTTP. Apunta cualquier cliente MCP a tu propio despliegue.

• Autohospedado: http://localhost:8081/mcp. Verificación rápida de sanidad:

  curl -X POST http://localhost:8081/mcp \
    -H "Content-Type: application/json" \
    -H "X-Chat-Id: test" \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
  

  Guía completa de integración autohospedada (LiteLLM, Claude Desktop, clientes personalizados): docs/MCP.md. El prompt del sistema por chat viaja por seis canales nativos de MCP redundantes (descripciones de herramientas, /home/assistant/README.md en el sandbox, InitializeResult.instructions, resources/list para archivos subidos, más un endpoint HTTP /system-prompt para integraciones heredadas) — mapa completo en docs/system-prompt.md.

Configuración

Todos los ajustes vía .env:

Variable	Predeterminado	Descripción
OPENAI_API_KEY	—	Clave de API del LLM (cualquier compatible con OpenAI)
OPENAI_API_BASE_URL	—	URL base de API personalizada (OpenRouter, etc.)
MCP_API_KEY	—	Token Bearer para el endpoint MCP
DOCKER_IMAGE	open-computer-use:latest	Imagen del contenedor del sandbox
COMMAND_TIMEOUT	120	Tiempo de espera de la herramienta bash (segundos)
SUB_AGENT_TIMEOUT	3600	Tiempo de espera del subagente (segundos)
SINGLE_USER_MODE	—	true = un contenedor, sin necesidad de ID de chat; false = requerir X-Chat-Id; sin definir = permisivo
PUBLIC_BASE_URL	http://computer-use-server:8081	URL del servidor de Computer Use accesible desde el navegador. Se incorpora en /system-prompt y se devuelve al filtro de Open WebUI en el encabezado de respuesta X-Public-Base-URL — fuente única de verdad para la URL pública. Requisitos de URL del filtro de Open WebUI.
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS, ORCHESTRATOR_URL, TOOL_RESULT_MAX_CHARS, TOOL_RESULT_PREVIEW_CHARS	—	Configuración en el contenedor open-webui (no en el servidor CU). Requerido al incrustar — consulta Configuración requerida al incrustar Open WebUI.
POSTGRES_PASSWORD	openwebui	Contraseña de PostgreSQL
VISION_API_KEY	—	Clave de API de visión (para describe-image)
ANTHROPIC_AUTH_TOKEN	—	Clave de Anthropic (para el subagente Claude Code)
MCP_TOKENS_URL	—	URL del Settings Wrapper (opcional, ver abajo)
MCP_TOKENS_API_KEY	—	Clave de autenticación del Settings Wrapper

Habilidades personalizadas y gestión de tokens (opcional)

De forma predeterminada, las 13 habilidades integradas están disponibles para todos. Para acceso por usuario a habilidades y habilidades personalizadas, despliega el Settings Wrapper — consulta settings-wrapper/README.md.

Tokens de acceso personal (PATs): El settings wrapper también puede almacenar PATs cifrados por usuario para servicios externos (GitLab, Confluence, Jira, etc.). El servidor los obtiene por correo electrónico del usuario y los inyecta en el sandbox — así la IA de cada usuario tiene acceso a sus repositorios/documentos sin compartir credenciales. El código del lado del servidor para la inyección de tokens está implementado (docker_manager.py), pero la herramienta de Open WebUI aún no pasa los encabezados requeridos. Esto está en la hoja de ruta — si necesitas gestión de PATs, abre un issue.

Integraciones de clientes MCP

El servidor de Computer Use habla MCP estándar sobre Streamable HTTP — cualquier cliente compatible con MCP puede conectarse. Open WebUI es el frontend principal probado, pero no la única opción.

Cliente	URL autoalojada	Estado
Open WebUI	Stack de Docker Compose incluido, auto-configurado	Probado en producción
Claude Desktop	http://localhost:8081/mcp — ver docs/MCP.md	Funciona
n8n	Nodo de herramienta MCP → http://computer-use-server:8081/mcp	Funciona
LiteLLM	Configuración de proxy MCP — ver docs/MCP.md	Funciona
Cliente personalizado	Cualquier cliente HTTP con MCP JSON-RPC — ver ejemplos de curl en docs/MCP.md	Funciona

Integración con Open WebUI

Open WebUI es una interfaz de IA autoalojada y extensible. Lo usamos como frontend principal porque admite llamadas a herramientas, filtros de funciones y artefactos — todo lo necesario para Computer Use.

Compatibilidad: Esta compilación está estrictamente construida y verificada contra Open WebUI 0.11.0. Los primeros 3 segmentos de nuestra versión de compilación (v0.11.0.X) siempre coinciden con la versión base de Open WebUI a la que apunta. Si ejecutas una versión diferente de Open WebUI, elige la compilación de Open Computer Use cuyos primeros 3 segmentos de versión coincidan con los tuyos — por ejemplo, para Open WebUI 0.8.12 usa una compilación v0.8.12.Y.

¿Por qué no un fork? Computer Use en sí no es un fork: se acopla a través de la API oficial de plugins — herramientas y funciones — por lo que Open WebUI estándar funciona con solo instalar la herramienta y el filtro. (Existe un fork separado para cambios que no pueden expresarse como plugins, pero nada en este repositorio depende de él).

¿Ejecutando Claude Code a través de una puerta de enlace corporativa (LiteLLM, Azure, Bedrock)? Consulta docs/claude-code-gateway.md para la receta de operador de tres rutas.

El directorio openwebui/ contiene:

• tools/ — Herramienta cliente MCP (proxy delgado al Servidor de Computer Use). Requerido — este es el puente entre Open WebUI y el sandbox.
• functions/ — Inyector de prompt del sistema + reescritor de enlaces de archivos + botón de archivo. Requerido — sin él, el modelo no conoce las habilidades ni las URLs de archivos.
• patches/ — Correcciones en tiempo de compilación para artefactos, manejo de errores, vista previa de archivos. Opcional pero recomendado — mejora significativamente la experiencia de usuario.
• init.sh — Auto-instala herramienta + filtro en el primer arranque. Opcional — puedes instalarlo manualmente a través de la interfaz de Workspace.
• init.sh — Instala la herramienta y el filtro en el primer arranque y configura sus válvulas.

Cómo funciona la auto-inicialización

En el primer docker compose up, el script de inicialización automáticamente:

1. Crea un usuario administrador (admin@open-computer-use.dev / admin)
2. Instala la herramienta de Computer Use vía POST /api/v1/tools/create
3. Instala el filtro de Computer Use vía POST /api/v1/functions/create
4. Configura las válvulas de herramienta y filtro (ORCHESTRATOR_URL=http://computer-use-server:8081 — URL interna para servidor↔servidor, sembrada en ambas válvulas)
5. Marca la herramienta como lectura pública (concesiones de acceso para ambos comodines group:* y user:*) — para que los usuarios no administradores vean la herramienta en su workspace
6. Marca el filtro como activo y global (dos interruptores separados: /toggle y /toggle/global) — activo-pero-no-global es silenciosamente inerte y un error común en la configuración manual
7. Fusiona {function_calling: "native", stream_response: true} en DEFAULT_MODEL_PARAMS vía POST /api/v1/configs/models — cada modelo obtiene los valores predeterminados correctos sin clics en Parámetros Avanzados por modelo

Un archivo marcador (.computer-use-initialized) evita que se vuelva a ejecutar en arranques posteriores.

Nota: Open WebUI no admite herramientas preinstaladas desde el sistema de archivos — deben cargarse a través de la API REST. El script de inicialización automatiza esto para que no tengas que hacerlo manualmente.

Configuración manual (si no usas docker-compose)

Si ejecutas Open WebUI por separado, necesitas hacer manualmente:

1. Ve a Workspace > Tools → Crear nueva herramienta → pega el contenido de openwebui/tools/computer_use_tools.py
2. Establece el ID de herramienta a ai_computer_use (requerido para que el filtro funcione)
3. Configura las Válvulas: ORCHESTRATOR_URL = URL interna de tu Servidor de Computer Use (http://computer-use-server:8081 para Docker compose)
4. Abre el menú ⋯ → Compartir de la herramienta y establece el acceso a Público (concede lectura a ambos comodines group:* y user:*) — de lo contrario, solo tu cuenta de administrador ve la herramienta y los usuarios no administradores obtienen una lista de herramientas vacía sin error
5. Ve a Workspace > Functions → Crear nueva función → pega openwebui/functions/computer_link_filter.py
6. Habilita el filtro: activa Activo y activa Global en la lista de Funciones — son dos interruptores separados, y activo-pero-no-global significa que el filtro se carga pero nunca se aplica a los chats
7. En la configuración de tu modelo, establece Function Calling = Native y Stream Chat Response = On. O establécelos globalmente una vez en Admin → Settings → Models → Advanced Params (function_calling: native, stream_response: true) — eso se convierte en DEFAULT_MODEL_PARAMS para cada modelo.

El stack de docker-compose maneja todo esto automáticamente.

Configuración requerida al incrustar Open WebUI en tu propio stack

Si ejecutas Open WebUI fuera del docker-compose.webui.yml estándar — tu propio compose, Kubernetes, Portainer, o un repositorio descendente — hay cuatro trampas que romperán silenciosamente Computer Use. Las cuatro nos afectaron en producción. Verifica en este orden.

Paso 1 — Una imagen upstream estándar es todo lo que este repositorio necesita

Instala la herramienta y el filtro y Computer Use funciona contra ghcr.io/open-webui/open-webui tal como se publica. Nada aquí necesita ser reconstruido.

Esto solía ser lo contrario: el repositorio llevaba ocho scripts de parche y un Dockerfile que los aplicaba a una imagen ya construida, y extraer upstream silenciosamente omitía todos ellos. Esos parches han desaparecido. Tres de los problemas que abordaban se han corregido upstream desde entonces; el resto vive como commits fuente en un fork, que es una preocupación separada de ejecutar esta integración.

La detección de URL de vista previa tampoco necesita configuración de host en tiempo de compilación — el origen del iframe se lee de la URL que escribió el modelo, que proviene del PUBLIC_BASE_URL del servidor.

Paso 3 — Dos configuraciones de URL, dos roles (público vs interno)

v4.0.0: el antiguo "tres FILE_SERVER_URL lugares que deben coincidir" ya no existe. Ahora solo hay dos lugares y dos roles distintos — público (accesible desde el navegador) vs interno (local a Docker). El argumento de compilación COMPUTER_USE_SERVER_URL se eliminó en v0.9.2.0 — fix_preview_url_detection ahora es agnóstico al host (ver Paso 2).

Dónde	Rol	Quién lo lee	Producción (con dominio)	Desarrollo local (Docker Desktop)
Env PUBLIC_BASE_URL en el contenedor computer-use-server (docker-compose.yml / .env)	PÚBLICO — incrustado en enlaces /system-prompt + devuelto al filtro vía encabezado de respuesta X-Public-Base-URL	Servidor (fuente única de verdad para URL pública)	https://cu.your-domain.com	http://localhost:8081
Válvulas de Filtro + Herramienta ORCHESTRATOR_URL (sembradas por init.sh desde env ORCHESTRATOR_URL en el contenedor open-webui)	INTERNO — búsqueda servidor↔servidor de /system-prompt; reenvío de MCP tools/call	Filtro y herramienta (red Docker)	http://computer-use-server:8081	http://computer-use-server:8081

⚠️ NO apuntes ORCHESTRATOR_URL a tu dominio público. Técnicamente funciona, pero cada solicitud MCP entonces va navegador→CDN→Traefik→contenedor. Cualquier contratiempo en esa cadena mata el stream a mitad de la llamada de herramienta y el usuario ve MCP call failed: Session terminated. Mantente dentro de la red Docker.

El filtro ya no tiene una válvula de URL pública — lee la URL pública del encabezado de respuesta X-Public-Base-URL del servidor y la almacena en caché junto con el prompt. Una perilla pública, una perilla interna.

Ver también docs/openwebui-filter.md.

Paso 4 — Cuatro variables de entorno en el contenedor open-webui

Copia y pega en tu bloque environment: de compose descendente:

services:
  open-webui:
    environment:
      # --- Computer Use required env vars (read by build-time patches) ---
      - CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS=200
      - TOOL_RESULT_MAX_CHARS=50000
      - TOOL_RESULT_PREVIEW_CHARS=2000
      # Internal URL of the Computer Use server — seeded by init.sh into both
      # Tool and Filter Valves, and read by the fix_large_tool_results patch.
      # Same Docker network: use the service DNS name.
      - ORCHESTRATOR_URL=http://computer-use-server:8081

Variable	Valor predeterminado si no se establece	Efecto cuando se configura correctamente
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS	256 (upstream)	Límite de llamadas de herramienta por turno; el repositorio estándar establece 200, -1 desactiva el límite. Open WebUI lee el nombre pre-0.10 CHAT_RESPONSE_MAX_TOOL_CALL_RETRIES como respaldo.
TOOL_RESULT_MAX_CHARS	50000 (parche integrado)	Umbral de truncamiento por encima del cual un resultado de herramienta se trunca o se sube. 0 lo desactiva.
TOOL_RESULT_PREVIEW_CHARS	2000 (parche integrado)	Tamaño de vista previa que el modelo ve después del truncamiento o la subida.
ORCHESTRATOR_URL	vacío	Sembrado en ambas válvulas de Herramienta y Filtro por init.sh, y leído por el parche fix_large_tool_results como destino de subida. Si está vacío, los resultados sobredimensionados se truncan silenciosamente — el modelo pierde los datos.

Nota: los últimos tres son inoperantes si la imagen es ghcr.io upstream — necesitan fix_large_tool_results del Paso 1.

Paso 5 — El filtro debe ser global, la herramienta debe ser de lectura pública

Open WebUI tiene dos interruptores separados para cada función (is_active y is_global) y dos concesiones requeridas para cada herramienta (group:* + user:*). El init.sh estándar hace esto por ti; las implementaciones manuales / personalizadas comúnmente omiten un lado y luego pasan horas preguntándose por qué "todo está instalado pero nada funciona."

Recurso	Qué cambiar	Ruta de UI	Endpoint	Por qué
Filtro computer_use_filter	is_active = true Y is_global = true	Admin → Functions → computer_use_filter → activa Activo + activa Global	POST /api/v1/functions/id/computer_use_filter/toggle + .../toggle/global	is_active solo carga la función; is_global realmente la aplica a cada chat. Activo-pero-no-global es silenciosamente inerte sin línea de registro.
Herramienta ai_computer_use	access_grants para group:* Y user:*, permission: read	Workspace → Tools → ai_computer_use → ⋯ → Compartir → Público	POST /api/v1/tools/id/ai_computer_use/access/update con {"access_grants":[{"principal_type":"group","principal_id":"*","permission":"read"},{"principal_type":"user","principal_id":"*","permission":"read"}]}	Sin concesiones, solo la cuenta de administrador que creó la herramienta la ve. Los usuarios no administradores obtienen una lista de herramientas vacía y sin error. El interruptor "Público" de la UI escribe ambos comodines; escribir solo uno deja la herramienta visible para algunos usuarios e invisible para otros dependiendo de la versión de Open WebUI.

Verifica contra la base de datos (Postgres usado por el stack estándar; ver docker-compose.webui.yml:53):

# Filter flags — expect (t, t):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"

# Tool grants — expect TWO rows (group|* and user|*, both 'read'):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"

Para implementaciones de Open WebUI respaldadas por SQLite, intercambia psql por sqlite3 /app/backend/data/webui.db con el mismo SQL.

Paso 6 — Verifica todo a la vez

# 1. Env vars reached the container:
docker exec open-webui env | grep -E 'CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS|TOOL_RESULT_|ORCHESTRATOR_URL'

# 4. Tool+Filter Valve (Session-terminated trap) — Admin UI is simplest:
#    Workspace → Tools → ai_computer_use → Valves → ORCHESTRATOR_URL
#    Admin → Functions → computer_link_filter → Valves → ORCHESTRATOR_URL
#    → both must be http://computer-use-server:8081 (internal URL, Docker service DNS),
#      NOT your public domain.

# 5. Server env (baked into system prompt AND returned to filter via header):
docker exec computer-use-server env | grep ^PUBLIC_BASE_URL=
# → must be a URL your browser can reach (e.g. http://localhost:8081 for local dev).

# 7. Filter is ACTIVE *and* GLOBAL (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"
# → expect (t, t). Two 't's, not one.

# 8. Tool is public-read with both wildcards (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"
# → expect TWO rows: (group, *, read) and (user, *, read).

Después de reconstruir la imagen, haz una recarga forzada en el navegador (Cmd+Shift+R / Ctrl+Shift+R). De lo contrario, mantiene los fragmentos JS antiguos en caché y pensarás que la corrección no funcionó.

Síntoma → qué paso está mal

Síntoma	Paso
El artefacto HTML se renderiza como texto <iframe ...> crudo en el chat	1 (imagen upstream, falta fix_artifacts_auto_show)
La auto-inserción del iframe de vista previa no ocurre para enlaces de archivos	1 (falta fix_preview_url_detection) o PUBLIC_BASE_URL inalcanzable desde el navegador
MCP call failed: Session terminated en cada llamada de herramienta	3 (la válvula de herramienta apunta al dominio público)
El bucle de herramienta se corta temprano; banner "Modelo temporalmente no disponible"	4 (CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS no establecido)
Salidas grandes de herramienta silenciosamente ...(truncated); el modelo toma decisiones incorrectas	4 (ORCHESTRATOR_URL no establecido o inalcanzable) O 1 (falta fix_large_tool_results)
Los errores del bucle de herramienta muestran excepción Python cruda	1 (falta fix_tool_loop_errors)
La lista de herramientas está vacía para usuarios no administradores (el administrador la ve)	5 (a la herramienta le faltan access_grants — no es de lectura pública)
El filtro se ve "Activo" en la UI pero el iframe de vista previa / botón de archivo nunca aparecen	5 (filtro is_global=false — solo se activó is_active=true)
Los enlaces de archivos en el chat van a 404 / pantalla blanca	PUBLIC_BASE_URL en el servidor no coincide con lo que el navegador puede alcanzar — ver docs/openwebui-filter.md
El nuevo comportamiento no apareció incluso después de reconstruir	El navegador almacenó en caché JS antiguo — recarga forzada

Notas de Seguridad

Probado en producción con más de 1000 usuarios en Open WebUI en un entorno autoalojado. Para implementaciones orientadas al público, consulta la hoja de ruta de endurecimiento a continuación.

Modelo actual

• Socket de Docker: El servidor necesita acceso al socket de Docker para gestionar los contenedores de sandbox. Esto otorga un acceso significativo al host: ejecútalo solo en un entorno de confianza.
• MCP_API_KEY: Establece una clave aleatoria fuerte en producción. Sin ella, cualquier persona con acceso de red al puerto 8081 puede ejecutar comandos arbitrarios en los contenedores.
• Aislamiento del sandbox: Cada sesión de chat se ejecuta en un contenedor separado con límites de recursos (2 GB de RAM, 1 CPU). En Docker Compose, los contenedores usan el runtime estándar (runc) y comparten el kernel del host. El gráfico de Helm de Kubernetes usa por defecto Podman sin root: espacios de nombres de usuario más AppArmor, y sin contenedor privilegiado, y puede optar por Kata Containers para un límite de nivel hipervisor. En Compose, cambia a gVisor (ver hoja de ruta). Los contenedores tienen acceso de red por defecto.
• POSTGRES_PASSWORD: Cambia la contraseña predeterminada en .env para producción.

Limitaciones conocidas

• Endpoints de archivos/vista previa sin autenticación: /files/{chat_id}/, /api/outputs/{chat_id}, /browser/{chat_id}/, /terminal/{chat_id}/: accesibles para cualquiera que conozca el ID del chat. Los ID de chat son UUID (difíciles de adivinar, pero no son un límite de seguridad real).
• Sin autenticación por usuario en el servidor: El servidor MCP confía en quien envía un MCP_API_KEY válido. La identidad del usuario (X-User-Email) la pasa el cliente, pero no se verifica en el servidor.
• Credenciales en encabezados HTTP: Las claves de API (GitLab, Anthropic, tokens MCP) se pasan como encabezados HTTP del cliente al servidor. Es seguro dentro de la red de Docker, pero usa HTTPS si lo expones externamente.
• Credenciales de administrador predeterminadas: admin@open-computer-use.dev / admin: cámbialas de inmediato en configuraciones multiusuario.

Hoja de ruta de seguridad

Planeamos abordar estos puntos en futuras versiones:

• Tokens firmados por sesión para endpoints de archivos/vista previa/terminal (reemplazar el ID de chat como autenticación)
• Verificación de usuario en el servidor mediante validación JWT de Open WebUI
• Soporte HTTPS con certificados TLS automáticos
• Registro de auditoría para todas las llamadas de herramientas y accesos a archivos
• Políticas de red para contenedores de sandbox (restringir el tráfico saliente por defecto)
• Gestión de secretos: mover credenciales de encabezados a almacenamiento cifrado en el servidor
• Runtime gVisor (runsc): sandboxing de contenedores opcional para un aislamiento más fuerte (como Claude.ai)

¿Ideas? Abre un Issue de GitHub. ¿Quieres contribuir? Consulta CONTRIBUTING.md o escribe a developer@widemoat.ai.

Desarrollo

# Build workspace image locally
docker build --platform linux/amd64 -t open-computer-use:latest .

# Run tests
./tests/test-docker-image.sh open-computer-use:latest
./tests/test-no-corporate.sh
./tests/test-project-structure.sh

# Build and run full stack
docker compose up --build

Contribuciones

Consulta CONTRIBUTING.md. ¡Se aceptan PRs!

Comunidad

• Demo en línea gratuita: lab.widemoat.ai — alojada por los mantenedores
• Issues e ideas: Issues de GitHub
• Contacto: developer@widemoat.ai

Licencia

Este proyecto usa un modelo de licencias múltiples:

• Núcleo (computer-use-server/, openwebui/, settings-wrapper/, configuraciones de Docker): Licencia de Fuente Funcional, Versión 1.1, Licencia Futura Apache 2.0 (FSL-1.1-Apache-2.0). Libre de usar, modificar, bifurcar, redistribuir y autoalojar internamente. Cada versión se convierte automáticamente a Apache 2.0 dos años después de su publicación. Ofrecer un servicio alojado o integrado que compita con nuestras versiones de pago requiere un acuerdo comercial.
• Nuestras habilidades (skills/public/describe-image, skills/public/sub-agent): MIT
• Habilidades de terceros: consulta los archivos LICENSE.txt individuales o las fuentes originales.

Atribución requerida: incluye "Open Computer Use" y un enlace a este repositorio.

Consulta NOTICE para más detalles. Para licencias de dependencias de terceros (PyMuPDF AGPL, Licencia de Habilidades de Anthropic, paquetes Apache 2.0, etc.), consulta THIRD-PARTY-LICENSES.md.