Open Computer Use

Open Computer Use

Servidor MCP que dá a qualquer LLM seu próprio computador — workspaces Docker gerenciados com navegador ao vivo, terminal, execução de código, habilidades de documentos e subagentes autônomos. Auto-hospedado, open-source, plugável em qualquer modelo.

Demonstração online: chat.yambr.com — Open WebUI com Computer Use já configurado, entre com GitHub ou Google. (Mais formas de experimentar abaixo.)

Transformação em andamento: o projeto está sendo reorganizado. O dashboard gerenciado, o endpoint MCP hospedado e o site de documentação hospedado estão offline e seus links foram removidos deste repositório. chat.yambr.com permanece ativo e pode sofrer interrupções enquanto a migração está em andamento.

Se algo disso parecer útil, uma ⭐ no repositório realmente ajuda — obrigado!

O que é isso?

Um servidor MCP que dá a qualquer LLM um sandbox Ubuntu totalmente equipado com contêineres Docker isolados. Pense nele como o computador da sua IA — ela pode fazer tudo que um desenvolvedor faz:

• Executar código — bash, Python, Node.js, Java em contêineres isolados
• Criar documentos — Word, Excel, PowerPoint, PDF com estilo profissional via habilidades
• Navegar na web — Playwright + navegador CDP ao vivo (você vê o que a IA vê em tempo real)
• Executar Claude Code — subagente autônomo com terminal interativo, servidores MCP configurados automaticamente
• Usar 13+ habilidades — fluxos de trabalho testados em batalha para criação de documentos, testes web, design e mais

Construído para implantações de produção multi-usuário. Testado com 1.000+ MAU. Cada sessão de chat roda em seu próprio contêiner Docker isolado — a IA pode instalar pacotes, criar arquivos, executar servidores, e nada vaza entre usuários. Funciona perfeitamente em clientes MCP: comece com Open WebUI hoje, mude para Claude Desktop ou n8n amanhã — mesmo backend, sem migração.

Principais diferenciais

Recurso	Open Computer Use	Claude.ai (Claude Code web)	open-terminal	OpenAI Operator
Auto-hospedado	Sim	Não	Sim	Não
Qualquer LLM	Sim (compatível com OpenAI)	Apenas Claude	Qualquer (via Open WebUI)	Apenas GPT
Execução de código	Sandbox Linux completo	Sandbox (Claude Code web)	Sandbox / bare metal	Não
Navegador ao vivo	Streaming CDP (compartilhado, interativo)	Baseado em capturas de tela	Não	Baseado em capturas de tela
Terminal + Claude Code	ttyd + tmux + Claude Code CLI	Claude Code web (integrado)	PTY + WebSocket	N/A
Sistema de habilidades	13 integradas (injeção automática) + personalizadas	Habilidades integradas + instruções personalizadas	Open WebUI nativo (somente texto)	N/A
Isolamento de contêiner	Docker (runc), por chat	Docker (gVisor)	Contêiner compartilhado (usuários em nível de SO)	N/A

Funciona com qualquer cliente compatível com MCP: Open WebUI, Claude Desktop, LiteLLM, n8n, ou sua própria integração. Veja docs/COMPARISON.md para uma comparação detalhada com alternativas.

Streaming de navegador ao vivo

Pré-visualização de arquivos com habilidades

Design de frontend — página de destino renderizada ao vivo na aba do navegador

Apresentações — sistema de design personalizado, não o modelo branco padrão

Crie suas próprias habilidades — empacote trabalhos recorrentes em funções reutilizáveis

Dados → gráfico com análise

Claude Code — terminal interativo na nuvem

Painel de subagentes — monitore e controle

Veja docs/FEATURES.md para detalhes de arquitetura e docs/SCREENSHOTS.md para todas as capturas de tela.

Dica profissional: Crie habilidades com Claude Code no terminal e depois use-as com qualquer modelo no chat. As habilidades são agnósticas de modelo — escreva uma vez, use em qualquer lugar.

Runtime de subagente multi-CLI (v0.9.2.1+): O despacho de subagentes suporta Claude Code (padrão), OpenAI Codex e OpenCode (com OpenRouter / qwen / DeepSeek / 75+ provedores). Alterne SUBAGENT_CLI=claude|codex|opencode em .env — veja docs/multi-cli.md para a receita completa com OpenCode + qwen3-coder + OpenRouter.

Arquitetura

Olhando para o futuro: uma arquitetura amigável ao Kubernetes com dados de usuário armazenados em object storage e habilidades empacotadas em squashfs está sendo projetada em docs/future-architecture/. Docker Compose continua sendo o caminho principal suportado.

Formas de experimentar

Caminho	URL	O que você precisa	Melhor para
Demonstração online gratuita — Open WebUI + Computer Use, modelos incluídos	chat.yambr.com	Login com GitHub ou Google	Experimentar de ponta a ponta em 30 segundos
Auto-hospedagem	Início Rápido abaixo	Docker, ~15 min na primeira compilação	Controle total, ambiente isolado, uso intenso

Somente OAuth — sem e-mail/senha, sem SMS. Em chat.yambr.com os modelos são incluídos como conveniência gratuita. O endpoint MCP hospedado está offline durante a transformação; veja docs/CLOUD.md.

Início 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

Abra http://localhost:3000 — Open WebUI com Computer Use pronto para uso.

Nota: Dois arquivos docker-compose separados: docker-compose.yml (Computer Use Server) e docker-compose.webui.yml (Open WebUI). Eles se comunicam via localhost:8081. Isso reflete implantações reais onde o servidor e a interface rodam em hosts diferentes.

Configurações do Modelo (importante!)

Após adicionar um modelo no Open WebUI, vá para Configurações do Modelo e defina:

Configuração	Valor	Por quê
Function Calling	Native	Necessário para as ferramentas do Computer Use funcionarem
Stream Chat Response	On	Habilita streaming de saída em tempo real

Sem Function Calling: Native, o modelo não invocará as ferramentas do Computer Use.

O que há dentro do Sandbox

Categoria	Ferramentas
Linguagens	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
Imagens	Pillow, OpenCV, ImageMagick, sharp, librsvg
Web	Playwright (Chromium), Mermaid CLI
IA	Claude Code CLI, Playwright MCP
OCR	Tesseract (idiomas configuráveis)
Mídia	FFmpeg
Diagramas	Graphviz, Mermaid
Dev	TypeScript, tsx, git

Habilidades

13 habilidades públicas integradas + 14 exemplos:

Habilidade	Descrição
pptx	Criar/editar apresentações PowerPoint com html2pptx
docx	Criar/editar documentos Word com controle de alterações
xlsx	Criar/editar planilhas Excel com fórmulas
pdf	Criar, preencher formulários, extrair, mesclar PDFs
sub-agent	Delegar tarefas complexas ao Claude Code
playwright-cli	Automação de navegador e raspagem web
describe-image	Análise de imagens com API de visão
frontend-design	Construir interfaces de produção
webapp-testing	Testar aplicações web com Playwright
doc-coauthoring	Fluxo de trabalho estruturado de coautoria de documentos
test-driven-development	Aplicação da metodologia TDD
skill-creator	Criar habilidades personalizadas
gitlab-explorer	Explorar repositórios GitLab

14 habilidades de exemplo: web-artifacts-builder, copy-editing, social-content, canvas-design, algorithmic-art, theme-factory, mcp-builder e mais.

Veja docs/SKILLS.md para detalhes.

Integração MCP

O servidor fala MCP padrão sobre Streamable HTTP. Aponte qualquer cliente MCP para sua própria implantação.

• Auto-hospedado: http://localhost:8081/mcp. Verificação rápida de sanidade:

  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"}}}'
  

  Guia completo de integração auto-hospedada (LiteLLM, Claude Desktop, clientes personalizados): docs/MCP.md. O prompt de sistema por chat usa seis canais MCP-nativos redundantes (descrições de ferramentas, /home/assistant/README.md no sandbox, InitializeResult.instructions, resources/list para arquivos enviados, além de um endpoint HTTP /system-prompt para integrações legadas) — mapa completo em docs/system-prompt.md.

Configuração

Todas as configurações via .env:

Variável	Padrão	Descrição
OPENAI_API_KEY	—	Chave de API LLM (qualquer compatível com OpenAI)
OPENAI_API_BASE_URL	—	URL base de API personalizada (OpenRouter, etc.)
MCP_API_KEY	—	Token Bearer para o endpoint MCP
DOCKER_IMAGE	open-computer-use:latest	Imagem do contêiner sandbox
COMMAND_TIMEOUT	120	Timeout da ferramenta bash (segundos)
SUB_AGENT_TIMEOUT	3600	Timeout do subagente (segundos)
SINGLE_USER_MODE	—	true = um contêiner, sem necessidade de ID de chat; false = exigir X-Chat-Id; não definido = tolerante
PUBLIC_BASE_URL	http://computer-use-server:8081	URL acessível pelo navegador do servidor Computer Use. Incorporada em /system-prompt e retornada ao filtro do Open WebUI no cabeçalho de resposta X-Public-Base-URL — fonte única de verdade para a URL pública. Requisitos de URL do filtro Open WebUI.
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS, ORCHESTRATOR_URL, TOOL_RESULT_MAX_CHARS, TOOL_RESULT_PREVIEW_CHARS	—	Configurações no contêiner open-webui (não no CU-server). Necessárias ao incorporar — veja Configuração necessária ao incorporar Open WebUI.
POSTGRES_PASSWORD	openwebui	Senha do PostgreSQL
VISION_API_KEY	—	Chave de API de visão (para describe-image)
ANTHROPIC_AUTH_TOKEN	—	Chave Anthropic (para subagente Claude Code)
MCP_TOKENS_URL	—	URL do Settings Wrapper (opcional, veja abaixo)
MCP_TOKENS_API_KEY	—	Chave de autenticação do Settings Wrapper

Habilidades Personalizadas e Gerenciamento de Tokens (opcional)

Por padrão, todas as 13 habilidades integradas estão disponíveis para todos. Para acesso por usuário e habilidades personalizadas, implante o Settings Wrapper — veja settings-wrapper/README.md.

Tokens de Acesso Pessoal (PATs): O settings wrapper também pode armazenar PATs criptografados por usuário para serviços externos (GitLab, Confluence, Jira, etc.). O servidor os busca pelo e-mail do usuário e os injeta no sandbox — assim, a IA de cada usuário tem acesso aos seus repositórios/documentos sem compartilhar credenciais. O código no lado do servidor para injeção de tokens está implementado (docker_manager.py), mas a ferramenta do Open WebUI ainda não passa os cabeçalhos necessários. Isso está no roadmap — se você precisar de gerenciamento de PATs, abra uma issue.

Integrações com Clientes MCP

O Computer Use Server fala MCP padrão sobre Streamable HTTP — qualquer cliente compatível com MCP pode se conectar. Open WebUI é o frontend principal testado, mas não a única opção.

Cliente	URL auto-hospedada	Status
Open WebUI	Stack Docker Compose incluída, auto-configurada	Testado em produção
Claude Desktop	http://localhost:8081/mcp — veja docs/MCP.md	Funciona
n8n	Nó de ferramenta MCP → http://computer-use-server:8081/mcp	Funciona
LiteLLM	Configuração de proxy MCP — veja docs/MCP.md	Funciona
Cliente personalizado	Qualquer cliente HTTP com MCP JSON-RPC — veja exemplos curl em docs/MCP.md	Funciona

Integração com Open WebUI

Open WebUI é uma interface de IA auto-hospedada e extensível. Nós a usamos como frontend principal porque suporta chamada de ferramentas, filtros de função e artefatos — tudo o que é necessário para o Computer Use. Compatibilidade: Este build é estritamente compilado e verificado contra o Open WebUI 0.11.0. Os primeiros 3 segmentos da nossa versão de build (v0.11.0.X) sempre correspondem à versão base do Open WebUI que ele visa. Se você executar uma versão diferente do Open WebUI, escolha o build do Open Computer Use cujos primeiros 3 segmentos de versão correspondam aos seus — por exemplo, para Open WebUI 0.8.12 use um build v0.8.12.Y.

Por que não um fork? Nós intencionalmente não fizemos fork do Open WebUI. Em vez disso, tudo é acoplado via API oficial de plugins (ferramentas + funções) e patches em tempo de build para funcionalidades ausentes. Isso significa que você pode usar o Open WebUI 0.11.0 padrão com este build (a versão que os primeiros 3 segmentos da nossa versão de build v0.11.0.X correspondem) — basta instalar a ferramenta e o filtro. Os patches são aplicados no momento do build do Docker; fortemente recomendado — 4 deles afetam a UX visível ao usuário (painel de artefatos, iframe de pré-visualização, banners de erro, manipulação de resultados grandes de ferramentas). Puxar ghcr.io/open-webui/open-webui diretamente ignora todos eles — veja Configuração necessária ao incorporar o Open WebUI para a lista de verificação completa.

Executando o Claude Code através de um gateway corporativo (LiteLLM, Azure, Bedrock)? Veja docs/claude-code-gateway.md para a receita de operador de três caminhos.

O diretório openwebui/ contém:

• tools/ — Ferramenta de cliente MCP (proxy fino para o Computer Use Server). Obrigatório — esta é a ponte entre o Open WebUI e o sandbox.
• functions/ — Injetor de prompt de sistema + reescritor de links de arquivos + botão de arquivamento. Obrigatório — sem ele, o modelo não conhece as habilidades e URLs de arquivos.
• patches/ — Correções em tempo de build para artefatos, tratamento de erros, pré-visualização de arquivos. Opcional, mas recomendado — melhora significativamente a UX.
• init.sh — Instala automaticamente a ferramenta + filtro no primeiro início. Opcional — você pode instalar manualmente via Interface do Workspace.
• Dockerfile — Constrói uma imagem Open WebUI corrigida com auto-inicialização. Opcional — use o Open WebUI padrão + configuração manual se preferir.

Como funciona a auto-inicialização

No primeiro docker compose up, o script de inicialização automaticamente:

1. Cria um usuário administrador (admin@open-computer-use.dev / admin)
2. Instala a ferramenta Computer Use via POST /api/v1/tools/create
3. Instala o filtro Computer Use via POST /api/v1/functions/create
4. Configura as válvulas da ferramenta e do filtro (ORCHESTRATOR_URL=http://computer-use-server:8081 — URL interna para servidor↔servidor, propagada em ambas as Válvulas)
5. Marca a ferramenta como leitura pública (concessões de acesso para ambos os curingas group:* e user:*) — para que usuários não administradores vejam a ferramenta em seu workspace
6. Marca o filtro como ativo e global (dois interruptores separados: /toggle e /toggle/global) — ativo-mas-não-global é silenciosamente inerte e um erro comum de configuração manual
7. Mescla {function_calling: "native", stream_response: true} em DEFAULT_MODEL_PARAMS via POST /api/v1/configs/models — cada modelo obtém os padrões corretos sem cliques em Parâmetros Avançados por modelo

Um arquivo marcador (.computer-use-initialized) impede a reexecução em inícios subsequentes.

Nota: O Open WebUI não suporta ferramentas pré-instaladas do sistema de arquivos — elas devem ser carregadas via API REST. O script de inicialização automatiza isso para que você não precise fazer manualmente.

Configuração manual (se não usar docker-compose)

Se você executar o Open WebUI separadamente, precisará manualmente:

1. Vá para Workspace > Ferramentas → Criar nova ferramenta → cole o conteúdo de openwebui/tools/computer_use_tools.py
2. Defina o ID da Ferramenta como ai_computer_use (necessário para o filtro funcionar)
3. Configure as Válvulas: ORCHESTRATOR_URL = URL interna do seu Computer Use Server (http://computer-use-server:8081 para Docker compose)
4. Abra o menu ⋯ → Compartilhar da ferramenta e defina o acesso como Público (concede leitura para ambos os curingas group:* e user:*) — caso contrário, apenas sua conta de administrador vê a ferramenta e usuários não administradores obtêm uma lista de ferramentas vazia sem erro
5. Vá para Workspace > Funções → Criar nova função → cole openwebui/functions/computer_link_filter.py
6. Habilite o filtro: alterne Ativo e alterne Global na lista de Funções — são dois interruptores separados, e ativo-mas-não-global significa que o filtro carrega, mas nunca é aplicado aos chats
7. Nas configurações do seu modelo, defina Chamada de Função = Native e Resposta de Chat em Fluxo = On. Ou defina-os globalmente uma vez em Admin → Configurações → Modelos → Parâmetros Avançados (function_calling: native, stream_response: true) — isso se torna DEFAULT_MODEL_PARAMS para cada modelo.

A pilha docker-compose lida com tudo isso automaticamente.

Configuração necessária ao incorporar o Open WebUI em sua própria pilha

Se você executar o Open WebUI fora do docker-compose.webui.yml padrão — seu próprio compose, Kubernetes, Portainer ou um repositório downstream — há quatro armadilhas que quebrarão silenciosamente o Computer Use. Todas as quatro nos atingiram em produção. Verifique nesta ordem.

Etapa 1 — Construa a imagem a partir de openwebui/Dockerfile, não puxe upstream

Puxar ghcr.io/open-webui/open-webui:vX.Y.Z fornece uma imagem padrão sem nenhum dos patches deste repositório. Quatro deles são críticos para a UX:

Patch	Sem ele
fix_artifacts_auto_show	HTML/iframe renderiza como texto bruto no corpo do chat em vez do painel de artefatos
fix_preview_url_detection	O iframe de pré-visualização nunca é inserido automaticamente após links de arquivos
fix_tool_loop_errors	Exceções brutas em vez de banners; MCP call failed: Session terminated aparece sem envoltório
fix_large_tool_results	TOOL_RESULT_MAX_CHARS para de truncar e o caminho de upload de resultados grandes (via ORCHESTRATOR_URL) torna-se um no-op; saídas grandes destroem o contexto do modelo

Apenas CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS continua funcionando em uma imagem upstream (é um env padrão do Open WebUI) — o que cria uma falsa sensação de "tudo está configurado".

Use build: em seu compose downstream, espelhando 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

Verifique se os patches estão incorporados no contêiner em execução:

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"'

O marcador de comentário JS FIX_ARTIFACTS_AUTO_SHOW é injetado por fix_artifacts_auto_show.py no momento do build como um identificador estável de versão — ele não depende de nomes de variáveis Svelte minificadas, que mudam a cada lançamento do Open WebUI.

Etapa 2 — Nenhum build-arg necessário para detecção de URL de pré-visualização (agnóstico de host desde v0.9.2.0)

fix_preview_url_detection agora é totalmente agnóstico de host. O JS injetado lê a origem diretamente da URL correspondente em tempo de execução (_pm[1] captura o prefixo completo https://host:port), então o patch não requer configuração de host em tempo de build. O build-arg COMPUTER_USE_SERVER_URL foi removido de openwebui/Dockerfile.

Nenhuma ação necessária — o patch funciona automaticamente independentemente de você usar localhost:8081, um domínio público ou DNS interno do Docker. O src do iframe de pré-visualização é sempre reconstruído a partir da URL que o modelo escreveu na mensagem, que por sua vez vem da variável de ambiente PUBLIC_BASE_URL do servidor.

Verifique se o patch 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"

Etapa 3 — Duas configurações de URL, dois papéis (público vs interno)

v4.0.0: a antiga "três FILE_SERVER_URL lugares que devem corresponder" é coisa do passado. Agora existem apenas dois lugares e dois papéis distintos — público (acessível pelo navegador) vs interno (local ao Docker). O build-arg COMPUTER_USE_SERVER_URL foi removido na v0.9.2.0 — fix_preview_url_detection agora é agnóstico de host (veja a Etapa 2).

Onde	Papel	Quem lê	Produção (com domínio)	Dev local (Docker Desktop)
Env PUBLIC_BASE_URL no contêiner computer-use-server (docker-compose.yml / .env)	PÚBLICO — incorporado nos links /system-prompt + retornado ao filtro via cabeçalho de resposta X-Public-Base-URL	Servidor (fonte única de verdade para URL pública)	https://cu.your-domain.com	http://localhost:8081
Válvulas do Filtro e da Ferramenta ORCHESTRATOR_URL (propagadas por init.sh a partir do env ORCHESTRATOR_URL no contêiner open-webui)	INTERNO — busca servidor↔servidor de /system-prompt; encaminhamento MCP tools/call	Filtro e ferramenta (rede Docker)	http://computer-use-server:8081	http://computer-use-server:8081

⚠️ NÃO aponte ORCHESTRATOR_URL para seu domínio público. Tecnicamente funciona, mas cada solicitação MCP então vai navegador→CDN→Traefik→contêiner. Qualquer soluço nessa cadeia mata o fluxo no meio da chamada de ferramenta e o usuário vê MCP call failed: Session terminated. Permaneça dentro da rede Docker.

O filtro não tem mais uma Válvula de URL pública — ele lê a URL pública do cabeçalho de resposta X-Public-Base-URL do servidor e a armazena em cache junto com o prompt. Um botão público, um botão interno.

Veja também docs/openwebui-filter.md.

Etapa 4 — Quatro variáveis de ambiente no contêiner open-webui

Copie e cole no bloco environment: do seu compose downstream:

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

Variável	Padrão se não definida	Efeito quando configurada corretamente
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS	256 (upstream)	Limite de chamadas de ferramenta por turno; repositório padrão define 200, -1 desativa o limite. O Open WebUI lê o nome pré-0.10 CHAT_RESPONSE_MAX_TOOL_CALL_RETRIES como fallback.
TOOL_RESULT_MAX_CHARS	50000 (patch embutido)	Limite de truncamento acima do qual um resultado de ferramenta é truncado ou enviado. 0 desativa.
TOOL_RESULT_PREVIEW_CHARS	2000 (patch embutido)	Tamanho da pré-visualização que o modelo vê após truncamento ou upload.
ORCHESTRATOR_URL	vazio	Propagado em ambas as Válvulas de Ferramenta e Filtro por init.sh, e lido pelo patch fix_large_tool_results como destino de upload. Se vazio, resultados superdimensionados são silenciosamente truncados — o modelo perde os dados.

Nota: os três últimos são no-ops se a imagem for upstream ghcr.io — eles precisam de fix_large_tool_results da Etapa 1.

Etapa 5 — O filtro deve ser global, a ferramenta deve ser de leitura pública

O Open WebUI tem dois interruptores separados para cada função (is_active e is_global) e duas concessões necessárias para cada ferramenta (group:* + user:*). O init.sh padrão faz isso por você; implantações manuais / personalizadas comumente perdem um lado e depois passam horas se perguntando por que "tudo está instalado, mas nada funciona."

Recurso	O que alternar	Caminho da UI	Endpoint	Por quê
Filtro computer_use_filter	is_active = true E is_global = true	Admin → Funções → computer_use_filter → alterne Ativo + alterne Global	POST /api/v1/functions/id/computer_use_filter/toggle + .../toggle/global	is_active apenas carrega a função; is_global realmente a aplica a cada chat. Ativo-mas-não-global é silenciosamente inerte sem linha de log.
Ferramenta ai_computer_use	access_grants para group:* E user:*, permission: read	Workspace → Ferramentas → ai_computer_use → ⋯ → Compartilhar → Público	POST /api/v1/tools/id/ai_computer_use/access/update com {"access_grants":[{"principal_type":"group","principal_id":"*","permission":"read"},{"principal_type":"user","principal_id":"*","permission":"read"}]}	Sem concessões, apenas a conta de administrador que criou a ferramenta a vê. Usuários não administradores obtêm uma lista de ferramentas vazia e nenhum erro. O alternador "Público" da UI grava ambos os curingas; gravar apenas um deixa a ferramenta visível para alguns usuários e invisível para outros, dependendo da versão do Open WebUI.

Verifique contra o banco de dados (Postgres usado pela pilha padrão; veja 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 implantações Open WebUI com SQLite, troque psql por sqlite3 /app/backend/data/webui.db com o mesmo SQL.

Etapa 6 — Verifique tudo de uma 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).

Após reconstruir a imagem, faça um recarregamento forçado no navegador (Cmd+Shift+R / Ctrl+Shift+R). Caso contrário, ele mantém os chunks JS antigos em cache e você pensará que a correção não funcionou.

Sintoma → qual etapa está errada

Sintoma	Passo
Artefato HTML é renderizado como texto <iframe ...> bruto no chat	1 (imagem upstream, fix_artifacts_auto_show ausente)
A inserção automática do iframe de pré-visualização não ocorre para links de arquivos	1 (fix_preview_url_detection ausente) ou PUBLIC_BASE_URL inacessível pelo navegador
MCP call failed: Session terminated em cada chamada de ferramenta	3 (a válvula da ferramenta aponta para domínio público)
O loop de ferramentas é interrompido antes do fim; banner "Modelo temporariamente indisponível"	4 (CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS não definido)
Saídas grandes de ferramentas são silenciosamente ...(truncated); o modelo toma decisões erradas	4 (ORCHESTRATOR_URL não definido ou inacessível) OU 1 (fix_large_tool_results ausente)
Erros no loop de ferramentas mostram exceção Python bruta	1 (fix_tool_loop_errors ausente)
A lista de ferramentas está vazia para usuários não administradores (o administrador a vê)	5 (ferramenta sem access_grants — não é leitura pública)
O filtro aparece "Ativo" na interface, mas o iframe de pré-visualização / botão de arquivo nunca aparecem	5 (filtro is_global=false — apenas is_active=true foi alterado)
Links de arquivos no chat levam a 404 / tela branca	PUBLIC_BASE_URL no servidor não corresponde ao que o navegador consegue acessar — veja docs/openwebui-filter.md
O novo comportamento não apareceu mesmo após o rebuild	Navegador com cache antigo de JS — recarregue com força

Notas de Segurança

Testado em produção com mais de 1000 usuários no Open WebUI em ambiente auto-hospedado. Para implantações voltadas ao público, veja o roteiro de endurecimento abaixo.

Modelo atual

• Socket Docker: O servidor precisa de acesso ao socket Docker para gerenciar contêineres de sandbox. Isso concede acesso significativo ao host — execute apenas em ambiente confiável.
• MCP_API_KEY: Defina uma chave aleatória forte em produção. Sem ela, qualquer pessoa com acesso à rede na porta 8081 pode executar comandos arbitrários nos contêineres.
• Isolamento de sandbox: Cada sessão de chat roda em um contêiner separado com limites de recursos (2GB de RAM, 1 CPU). No Docker Compose, os contêineres usam o runtime padrão (runc) e compartilham o kernel do host. Para isolamento mais forte, execute o gráfico Helm do Kubernetes com Kata Containers (grau de hipervisor, disponível hoje) — ou, no Compose, mude para gVisor (veja o roteiro). Os contêineres têm acesso à rede por padrão.
• POSTGRES_PASSWORD: Altere a senha padrão em .env para produção.

Limitações conhecidas

• Endpoints de arquivo/pré-visualização sem autenticação: /files/{chat_id}/, /api/outputs/{chat_id}, /browser/{chat_id}/, /terminal/{chat_id}/ — acessíveis a qualquer pessoa que conheça o ID do chat. IDs de chat são UUIDs (difíceis de adivinhar, mas não são uma fronteira de segurança real).
• Sem autenticação por usuário no servidor: O servidor MCP confia em quem enviar um MCP_API_KEY válido. A identidade do usuário (X-User-Email) é passada pelo cliente, mas não verificada no lado do servidor.
• Credenciais em cabeçalhos HTTP: Chaves de API (GitLab, Anthropic, tokens MCP) são passadas como cabeçalhos HTTP do cliente para o servidor. Seguro dentro da rede Docker, mas use HTTPS se expor externamente.
• Credenciais de administrador padrão: admin@open-computer-use.dev / admin — altere imediatamente em configurações multiusuário.

Roteiro de segurança

Planejamos abordar estes pontos em versões futuras:

• Tokens assinados por sessão para endpoints de arquivo/pré-visualização/terminal (substituir o ID do chat como autenticação)
• Verificação de usuário no lado do servidor via validação JWT do Open WebUI
• Suporte a HTTPS com certificados TLS automáticos
• Registro de auditoria para todas as chamadas de ferramentas e acessos a arquivos
• Políticas de rede para contêineres de sandbox (restringir saída por padrão)
• Gerenciamento de segredos — mover credenciais de cabeçalhos para armazenamento criptografado no servidor
• Runtime gVisor (runsc) — sandbox de contêiner opcional para isolamento mais forte (como Claude.ai)

Tem ideias? Abra uma Issue no GitHub. Quer contribuir? Veja CONTRIBUTING.md ou envie e-mail para developer@widemoat.ai.

Desenvolvimento

# 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

Contribuindo

Veja CONTRIBUTING.md. PRs são bem-vindos!

Comunidade

• Demo online gratuita: chat.yambr.com — hospedada pelos mantenedores
• Issues e Ideias: Issues no GitHub
• Contato: developer@widemoat.ai

Licença

Este projeto usa um modelo de múltiplas licenças:

• Núcleo (computer-use-server/, openwebui/, settings-wrapper/, configurações Docker): Functional Source License, Versão 1.1, Apache 2.0 Future License (FSL-1.1-Apache-2.0). Livre para usar, modificar, bifurcar, redistribuir e auto-hospedar internamente. Cada versão converte automaticamente para Apache 2.0 dois anos após a publicação. Oferecer um serviço hospedado ou incorporado que concorra com nossas versões pagas exige um acordo comercial.
• Nossas skills (skills/public/describe-image, skills/public/sub-agent): MIT
• Skills de terceiros: veja os arquivos LICENSE.txt individuais ou as fontes originais.

Atribuição necessária: inclua "Open Computer Use" e um link para este repositório.

Veja NOTICE para detalhes. Para licenças de dependências de terceiros (PyMuPDF AGPL, Anthropic Skill License, pacotes Apache 2.0, etc.), veja THIRD-PARTY-LICENSES.md.