Skip to main content

​
Big picture

Open Computer Use architecture
Three moving parts:
  1. MCP client — Open WebUI, Claude Desktop, LiteLLM, n8n, or anything that speaks MCP over Streamable HTTP.
  2. Computer Use Server (the orchestrator) — stateless HTTP service that routes MCP requests to per-chat sandbox containers, serves the system prompt, exposes the live browser/terminal, and hosts file previews.
  3. Sandbox container — one Docker container per X-Chat-Id. Full Ubuntu userspace with the tools listed in Introduction.

​
Data flow

Data flow from chat to sandbox
Each MCP request carries X-Chat-Id (mandatory in strict multi-user mode). The orchestrator creates the sandbox lazily on first use and tears it down after CONTAINER_MAX_AGE_HOURS. Everything is isolated — the AI can install packages, create files, run servers, and nothing leaks between users.

​
Sandbox contents

What's inside each sandbox container

​
The live browser

Shared CDP browser between the model and the user
Each sandbox runs Chromium with the Chrome DevTools Protocol exposed. The orchestrator bridges CDP over WebSocket, so the user sees exactly what the model is doing — and can click through if needed. See Live browser.

​
The terminal tab

ttyd + tmux + Claude Code CLI in the terminal tab
Open WebUI gets a dedicated terminal tab backed by ttyd + tmux. The sub-agent tool launches Claude Code CLI inside a named tmux session — you can attach, watch, or take over. See Terminal.

​
File pipeline

File upload, sandbox, preview pipeline
Uploads land on the orchestrator, get mounted into /home/assistant/uploads/{chat_id}/ inside the sandbox, and are re-exposed as MCP resources/list entries. Files the model creates are served back through the same public endpoint (cu.yambr.com/files/... in managed Yambr; http://localhost:8081/files/... self-hosted) and auto-previewed in Open WebUI’s artifacts panel. See File preview.

​
The system prompt — six redundant channels

The per-chat system prompt isn’t just pasted into a single field. It’s delivered through six MCP-native and HTTP channels so the model can recover its environment even if a client strips one of them:
  1. Tool descriptions (every MCP tool includes context)
  2. /home/assistant/README.md inside the sandbox (readable by the view tool)
  3. InitializeResult.instructions (MCP handshake)
  4. resources/list + resources/read (uploaded files)
  5. HTTP GET /system-prompt (legacy integrations)
  6. HTTP GET /skill-list (for sub-agent delegation)
Full map: System prompt reference.

​
Session isolation

Controlled by SINGLE_USER_MODE:
ModeX-Chat-IdBehavior
unsetYesIsolated container per chat ID
unsetNoShared default container + warning in every tool response
trueanyAlways one default container; header ignored
falseYesStrict: isolated container per chat ID
falseNoRejected with error
Managed Yambr runs strict multi-user mode. See MCP API reference for header details.