Open Computer Use

Open Computer Use

Servidor MCP que le da a cualquier LLM su propia computadora: espacios de trabajo Docker administrados 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: chat.yambr.com — Open WebUI con Computer Use ya configurado, inicia sesión con GitHub o Google. (Más formas de probarlo abajo.)

Transformación en curso: el proyecto se está reorganizando. El panel administrado, el endpoint MCP alojado y el sitio de documentación alojado están fuera de línea y sus enlaces se han eliminado de este repositorio. chat.yambr.com permanece activo y puede sufrir interrupciones mientras se realiza la migración.

Si algo de esto te resulta útil, ¡una ⭐ en el repositorio realmente ayuda — 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: comienza 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 (auto-inyectadas) + personalizadas	Habilidades integradas + instrucciones personalizadas	Open WebUI nativo (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 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 con 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	chat.yambr.com	Inicio de sesión con GitHub o Google	Probarlo de principio a fin en 30 segundos
Autohospedado	Inicio rápido abajo	Docker, ~15 min primera compilación	Control total, aislado, uso intensivo

Solo OAuth — sin correo/contraseña, sin SMS. En chat.yambr.com los modelos se incluyen como 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 Computer Use) y docker-compose.webui.yml (Open WebUI). Se comunican a través de 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, rellenar 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 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 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 a través de .env:

Variable	Predeterminado	Descripción
OPENAI_API_KEY	—	Clave 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 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 establecer = permisivo
PUBLIC_BASE_URL	http://computer-use-server:8081	URL accesible desde el navegador del servidor Computer Use. Incorporada en /system-prompt y devuelta 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 de habilidades por usuario 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 repos/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 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 autohospedada	Estado
Open WebUI	Stack de Docker Compose incluido, auto-configurado	Probado en producción
Claude Desktop	http://localhost:8081/mcp — consulta docs/MCP.md	Funciona
n8n	Nodo de herramienta MCP → http://computer-use-server:8081/mcp	Funciona
LiteLLM	Configuración de proxy MCP — consulta docs/MCP.md	Funciona
Cliente personalizado	Cualquier cliente HTTP con MCP JSON-RPC — consulta ejemplos de curl en docs/MCP.md	Funciona

Integración con Open WebUI

Open WebUI es una interfaz de IA extensible y autohospedada. Lo usamos como frontend principal porque admite llamadas de 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? Intencionalmente no hicimos un fork de Open WebUI. En su lugar, todo se acopla mediante la API oficial de plugins (herramientas + funciones) y parches en tiempo de compilación para características faltantes. Esto significa que puedes usar el Open WebUI estándar 0.11.0 con esta compilación (la versión que coinciden los primeros 3 segmentos de nuestra versión de compilación v0.11.0.X) — solo instala la herramienta y el filtro. Los parches se aplican en el momento de la compilación de Docker; muy recomendado — 4 de ellos afectan la experiencia de usuario visible (panel de artefactos, iframe de vista previa, banners de error, manejo de resultados grandes de herramientas). Extraer ghcr.io/open-webui/open-webui directamente omite todos ellos — consulta Configuración requerida al incrustar Open WebUI para la lista completa.

¿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 de cliente MCP (proxy delgado hacia Computer Use Server). 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 UX.
• init.sh — Instala automáticamente la herramienta + filtro en el primer inicio. Opcional — puedes instalarlo manualmente a través de la interfaz de Workspace.
• Dockerfile — Construye una imagen de Open WebUI parcheada con auto-inicialización. Opcional — usa Open WebUI estándar + configuración manual si lo prefieres.

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 Computer Use mediante POST /api/v1/tools/create
3. Instala el filtro Computer Use mediante 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 Valves)
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 espacio de trabajo
6. Marca el filtro como activo y global (dos interruptores separados: /toggle y /toggle/global) — activo pero no global es silenciosamente inerte y es un error común en la configuración manual
7. Fusiona {function_calling: "native", stream_response: true} en DEFAULT_MODEL_PARAMS mediante POST /api/v1/configs/models — cada modelo obtiene los valores predeterminados correctos sin necesidad de hacer clic en Parámetros Avanzados por modelo

Un archivo marcador (.computer-use-initialized) evita que se vuelva a ejecutar en inicios 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, debes hacer manualmente:

1. Ve a Workspace > Tools → Crear nueva herramienta → pega el contenido de openwebui/tools/computer_use_tools.py
2. Establece Tool ID a ai_computer_use (requerido para que el filtro funcione)
3. Configura Valves: ORCHESTRATOR_URL = URL interna de tu Computer Use Server (http://computer-use-server:8081 para Docker compose)
4. Abre el menú ⋯ → Share de la herramienta y establece el acceso a Public (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: alterna Active y alterna Global en la lista de Functions — 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 — Construye la imagen desde openwebui/Dockerfile, no extraigas la imagen upstream

Extraer ghcr.io/open-webui/open-webui:vX.Y.Z te da una imagen estándar sin ninguno de los parches de este repositorio. Cuatro de ellos son críticos para la UX:

Parche	Sin él
fix_artifacts_auto_show	El HTML/iframe se renderiza como texto sin formato en el cuerpo del chat en lugar del panel de artefactos
fix_preview_url_detection	El iframe de vista previa nunca se inserta automáticamente después de los enlaces de archivos
fix_tool_loop_errors	Excepciones sin procesar en lugar de banners; MCP call failed: Session terminated aparece sin envolver
fix_large_tool_results	TOOL_RESULT_MAX_CHARS deja de truncar y la ruta de carga de resultados grandes (a través de ORCHESTRATOR_URL) se convierte en un no-op; las salidas grandes arruinan el contexto del modelo

Solo CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS sigue funcionando en una imagen upstream (es una variable de entorno estándar de Open WebUI) — lo que crea una falsa sensación de "todo está configurado".

Usa build: en tu compose descendente, reflejando docker-compose.webui.yml:11-15:

services:
  open-webui:
    build:
      context: ./openwebui   # path into this repo
      dockerfile: Dockerfile
      args:
        OPENWEBUI_VERSION: "0.11.0"
    image: open-webui-with-cu-patches:latest   # local tag, do not pull

Verifica que los parches estén integrados en el contenedor en ejecución:

docker exec open-webui bash -c \
  'grep -rl "FIX_ARTIFACTS_AUTO_SHOW" /app/build/_app/immutable/chunks/ >/dev/null \
   && echo "patches applied" || echo "MISSING — you are on upstream image"'

El marcador de comentario JS FIX_ARTIFACTS_AUTO_SHOW se inyecta mediante fix_artifacts_auto_show.py en tiempo de compilación como un identificador estable de versión — no depende de nombres de variables Svelte minificadas, que cambian con cada versión de Open WebUI.

Paso 2 — No se requiere build-arg para la detección de URL de vista previa (agnóstico de host desde v0.9.2.0)

fix_preview_url_detection ahora es completamente agnóstico de host. El JS inyectado lee el origen directamente de la URL coincidente en tiempo de ejecución (_pm[1] captura el prefijo completo https://host:port), por lo que el parche no requiere configuración de host en tiempo de compilación. El build-arg COMPUTER_USE_SERVER_URL se ha eliminado de openwebui/Dockerfile.

No se requiere acción — el parche funciona automáticamente independientemente de si usas localhost:8081, un dominio público o DNS interno de Docker. El src del iframe de vista previa siempre se reconstruye a partir de la URL que el modelo escribió en el mensaje, que a su vez proviene de la variable de entorno PUBLIC_BASE_URL del servidor.

Verifica que el parche esté aplicado:

docker exec open-webui bash -c \
  'grep -rl "FIX_PREVIEW_URL_DETECTION" /app/build/_app/immutable/chunks/ >/dev/null \
   && echo "patches applied" || echo "MISSING — fix_preview_url_detection not baked in"'
# → should print "patches applied"

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

v4.0.0: el antiguo problema de "tres FILE_SERVER_URL lugares que deben coincidir" ha desaparecido. Ahora solo hay dos lugares y dos roles distintos — público (accesible desde el navegador) vs interno (local de Docker). El build-arg COMPUTER_USE_SERVER_URL se eliminó en v0.9.2.0 — fix_preview_url_detection ahora es agnóstico de host (ver Paso 2).

Dónde	Rol	Quién lo lee	Producción (con dominio)	Desarrollo local (Docker Desktop)
Variable de entorno PUBLIC_BASE_URL en el contenedor computer-use-server (docker-compose.yml / .env)	PÚBLICO — integrado en los enlaces /system-prompt + devuelto al filtro mediante el encabezado de respuesta X-Public-Base-URL	Servidor (fuente única de verdad para la URL pública)	https://cu.your-domain.com	http://localhost:8081
Valves de Filtro y Herramienta ORCHESTRATOR_URL (sembradas por init.sh desde la variable de entorno ORCHESTRATOR_URL en el contenedor open-webui)	INTERNO — fetch 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 va entonces 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 Valve 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: del 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	Sembrada en ambas Valves de Herramienta y Filtro por init.sh, y leída por el parche fix_large_tool_results como destino de subida. Si está vacía, los resultados sobredimensionados se truncan silenciosamente — el modelo pierde los datos.

Nota: las últimas tres son no-ops si la imagen es upstream ghcr.io — 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 → alternar Active + alternar 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 → ⋯ → Share → Public	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 "Public" 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. Image has patches (marker-based — version-stable across Open WebUI releases):
docker exec open-webui bash -c \
  'grep -rl "FIX_ARTIFACTS_AUTO_SHOW" /app/build/_app/immutable/chunks/ >/dev/null \
   && echo OK || echo MISSING'

# 2. Preview URL detection is host-agnostic (no build-arg needed since v0.9.2.0):
docker exec open-webui bash -c \
  'grep -rl "FIX_PREVIEW_URL_DETECTION" /app/build/_app/immutable/chunks/ >/dev/null \
   && echo "patches applied" || echo "MISSING — fix_preview_url_detection not baked in"'
# → should print "patches applied"

# 3. 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 ...> sin procesar en el chat	1 (imagen upstream, falta fix_artifacts_auto_show)
La autoinserción del iframe de vista previa no ocurre para enlaces de archivos	1 (falta fix_preview_url_detection) o PUBLIC_BASE_URL inaccesible desde el navegador
MCP call failed: Session terminated en cada llamada de herramienta	3 (la válvula de la herramienta apunta al dominio público)
El bucle de herramientas se corta temprano; banner "Modelo temporalmente no disponible"	4 (CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS no configurado)
Salidas grandes de herramientas silenciosamente ...(truncated); el modelo toma decisiones incorrectas	4 (ORCHESTRATOR_URL no configurado o inaccesible) O 1 (falta fix_large_tool_results)
Errores del bucle de herramientas muestran excepción cruda de Python	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 interfaz pero el iframe de vista previa / botón de archivo nunca aparecen	5 (filtro is_global=false — solo se cambió 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 cacheó el 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, ver la hoja de ruta de endurecimiento a continuación.

Modelo actual

• Socket de Docker: El servidor necesita acceso al socket de Docker para gestionar contenedores sandbox. Esto otorga acceso significativo al host — ejecutar solo en un entorno confiable.
• MCP_API_KEY: Configurar una clave aleatoria fuerte en producción. Sin ella, cualquiera con acceso de red al puerto 8081 puede ejecutar comandos arbitrarios en contenedores.
• Aislamiento del sandbox: Cada sesión de chat se ejecuta en un contenedor separado con límites de recursos (2GB RAM, 1 CPU). En Docker Compose, los contenedores usan el runtime estándar (runc) y comparten el kernel del host. Para un aislamiento más fuerte, ejecutar el gráfico Helm de Kubernetes con Kata Containers (grado hipervisor, disponible hoy) — o, en Compose, cambiar a gVisor (ver hoja de ruta). Los contenedores tienen acceso de red por defecto.
• POSTGRES_PASSWORD: Cambiar 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 IDs de chat son UUIDs (difíciles de adivinar pero no una frontera 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) es pasada por el cliente pero no verificada en el servidor.
• Credenciales en cabeceras HTTP: Las claves API (GitLab, Anthropic, tokens MCP) se pasan como cabeceras HTTP del cliente al servidor. Seguro dentro de la red Docker, pero usar HTTPS si se expone externamente.
• Credenciales de administrador predeterminadas: admin@open-computer-use.dev / admin — cambiar inmediatamente 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 del 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 acceso a archivos
• Políticas de red para contenedores sandbox (restringir salida por defecto)
• Gestión de secretos — mover credenciales de cabeceras 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? Ver 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

Ver CONTRIBUTING.md. ¡PRs bienvenidos!

Comunidad

• Demo en línea gratuita: chat.yambr.com — 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 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: ver archivos LICENSE.txt individuales o fuentes originales.

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

Ver NOTICE para detalles. Para licencias de dependencias de terceros (PyMuPDF AGPL, Licencia de Habilidad Anthropic, paquetes Apache 2.0, etc.), ver THIRD-PARTY-LICENSES.md.