# Universal Mission Control CCC Built on OpenHands SDK

## Executive summary

A “universal mission control” desktop (CCC = Command / Control / Center) is a coherent product category: it is not just an agent UI, but a **control plane** for multiple agent runtimes plus multiple “surfaces” (terminal, files, browser, desktop GUI, previews, artifacts, logs) that remains usable as you swap where execution happens (host vs container vs remote sandbox) at runtime. The design goal you described—**native-feeling**, **configurable execution location at runtime**, and “stub agent on host while others are decided”—matches the newer generation of agent stacks that separate orchestration from execution and expose observable surfaces. citeturn7view4turn19view0turn19view1turn19view2

Using entity["organization","OpenHands","open source agent sdk"] SDK as the foundation is a strong choice for CCC because it already provides: (1) a **workspace abstraction** that spans local, Docker, and remote execution; (2) a **production agent server** with streaming events; (3) **interactive workspace surfaces** (VNC desktop, built-in Chromium browser view, VSCode Web) intended for human inspection/intervention; (4) event-sourced state, persistence, and deterministic replay semantics; and (5) built-in security analysis primitives (risk levels, confirmation policy hooks, audit trail in event history) plus secrets auto-masking. citeturn7view4turn19view0turn19view1turn6view2turn7view2turn14view0

However, when compared to entity["organization","Agent Zero","open source agent framework"], the gaps are specific and actionable: Agent Zero’s “core primitives” emphasize **file-first project scoping** (instructions/knowledge/memory/secrets per project), **dynamic tool creation and override** via filesystem conventions, and explicit **inter-agent comms and A2A** as a first-class interoperability layer; OpenHands covers parts of this via sub-agent delegation, MCP, and plugin packaging, but it does not (today) ship a CCC-grade **surface gateway/tunneling layer**, a unified **A2A router**, nor a tool/skill **marketplace pipeline** with supply-chain controls. citeturn12view0turn11view0turn5search1turn3search2turn19view5turn3search35

On the “broader interaction surface” axis, entity["organization","OpenClaw","open source agent assistant"] stands out: it is explicitly multi-channel (chat platforms) and multi-node (clients connect to a gateway control plane) and includes a public skills registry concept (ClawHub). That interaction breadth is a key inspiration for CCC even if you do not adopt its runtime model. citeturn8view0turn13search10turn13search0turn13search3

For the “remote sandbox computer” component choice between entity["company","Daytona","daytona sandboxes platform"] and entity["company","E2B","cloud sandbox provider"]: both can power a CCC runner, but Daytona is the more “control-plane native” pick for an initial integration because it ships **signed preview URLs** (a tunneling-like primitive with embedded auth), **org-level permissions/audit logs**, and explicit **network egress limiting** in its platform docs; E2B differentiates with a strong “computer use” desktop template and **pause/resume persistence** (including running processes) plus template snapshots designed for near-instant reuse. A pragmatic path is: start with Daytona as the first remote sandbox runner, keep E2B as a second runner once your runner API stabilizes. citeturn19view9turn9search1turn9search3turn17search0turn17search1turn18search2

## Scope, sources, and comparison legend

This report treats CCC as a **universal mission control layer** that can drive multiple independent runtimes and surfaces. The implementation language is **unspecified**, but interfaces below are sketched in TypeScript-style, as requested. citeturn7view4turn19view0turn19view6

Legend for tables (names expanded once here; tables use abbreviations):

- **OH**: entity["organization","OpenHands","open source agent sdk"] SDK + agent server + “interactive workspace access” surfaces. citeturn7view4turn19view0turn14view0turn6view2turn19view1  
- **AZ**: entity["organization","Agent Zero","open source agent framework"] runtime framework + projects, memory, skills conventions. citeturn12view0turn11view0turn11view1turn5search7turn3search2  
- **CD**: Claude Code on desktop (vendor docs emphasize code-focused desktop UX, permission modes, parallel sessions, environments, and MCP extensions). citeturn5search2turn0search7turn0search34  
- **OC**: entity["organization","OpenClaw","open source agent assistant"] gateway + multi-channel clients + ClawHub skills + memory-in-files. citeturn8view0turn13search10turn13search0turn13search1  
- **AIS**: AIO Sandbox (agent-infra/sandbox): “browser + shell + files + MCP + VSCode server + VNC” in one container. citeturn8view2  
- **DYT**: entity["company","Daytona","daytona sandboxes platform"] sandboxes with VNC + preview URLs + egress controls + org tooling. citeturn19view7turn19view9turn9search1turn9search3  
- **E2B**: entity["company","E2B","cloud sandbox provider"] sandboxes + desktop template + sandbox persistence + internet access gating. citeturn19view8turn17search1turn18search2  
- **G**: goose (desktop + CLI; MCP-based extensions; computer controller). citeturn10search0turn10search2turn10search3  
- **OI**: entity["organization","Open Interpreter","open source desktop agent"] (desktop agent + local execution emphasis). citeturn2search0turn2search14turn2search3  
- **CR**: Crush (terminal coding agent with MCP extensibility and multi-session organization). citeturn2search1turn2search6  

## Feature inventory across inspirations

### Surface inventory and “built-in CCC” capabilities

The table below is intentionally strict: ✅ = explicitly built-in & documented; ◐ = achievable via documented extension/integration pattern; ❌ = not documented as a product capability; ? = unclear in public docs as of Feb 24, 2026.

| Feature / Surface (CCC-relevant) | OH | AZ | CD | OC | AIS | DYT | E2B | G | OI | CR |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| VNC desktop viewing + control in-browser | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| RDP viewing/control | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| Built-in “visible browser” surface | ✅ | ❌ | ◐ | ❌ | ✅ | ◐ | ◐ | ◐ | ◐ | ❌ |
| Browser automation via CDP-like tools | ◐ | ◐ | ❌ | ◐ | ◐ | ◐ | ◐ | ◐ | ◐ | ◐ |
| VSCode Web / code-server embedded | ✅ | ❌ | ❌ | ❌ | ✅ | ❌ | ◐ | ❌ | ❌ | ❌ |
| Terminal surface tied to same workspace | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Workspace file explorer semantics | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| “Asset display” (images, diffs, previews) as first-class UI | ◐ | ◐ | ✅ | ◐ | ◐ | ◐ | ◐ | ◐ | ✅ | ❌ |
| Session recorder / replay (UI + export) | ◐ | ◐ | ? | ? | ? | ? | ? | ? | ? | ? |
| Remote desktop takeover (human interrupts agent on same desktop) | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Tunneling / NAT traversal for surfaces | ◐ | ◐ | ◐ | ✅ | ◐ | ✅ | ? | ◐ | ❌ | ❌ |
| Session multiplexing (many parallel sessions) | ✅ | ✅ | ✅ | ✅ | ◐ | ✅ | ✅ | ◐ | ◐ | ✅ |
| Runner targets: host + container + remote | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |

Evidence anchors (selected, high-signal): OH interactive surfaces and bundled docker images (VNC/VSCode/Chromium) plus remote execution architecture are stated explicitly in its SDK paper and docs. citeturn7view4turn14view0turn19view0turn19view6 AIS explicitly documents VNC + VSCode server endpoints in one container and describes unified filesystem across browser/shell/file ops. citeturn8view2 DYT documents VNC access in-browser and signed preview URLs that embed auth tokens in the URL. citeturn19view7turn19view9 E2B documents a desktop template with Ubuntu+XFCE and VNC streaming plus sandbox persistence (pause/resume with processes) and outbound internet gating. citeturn19view8turn17search1turn18search2 CD highlights “visual diff review,” “live app preview,” “parallel sessions,” and local/SSH/cloud environments in its desktop docs; it also supports MCP extension installation via a directory and .mcpb packaging. citeturn5search2turn0search7turn0search34

### Coordination, tools/skills, governance, and “mission control primitives”

| Feature / Primitive | OH | AZ | CD | OC | AIS | DYT | E2B | G | OI | CR |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| Sub-agent delegation / parallel agent instances | ✅ | ✅ | ◐ | ◐ | ❌ | ❌ | ❌ | ◐ | ◐ | ? |
| A2A protocol (agent-to-agent over network) | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| MCP tool discovery/interop | ✅ | ◐ | ✅ | ◐ | ✅ | ◐ | ◐ | ✅ | ◐ | ✅ |
| Dynamic tool creation (agent authors tools as code, not just uses tools) | ◐ | ✅ | ❌ | ◐ | ❌ | ❌ | ❌ | ❌ | ◐ | ◐ |
| Tool/skill package format + distribution mechanism | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ◐ | ✅ | ❌ | ◐ |
| Tool marketplace / directory UX | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ | ◐ | ❌ | ❌ |
| Permissioning / confirmations for risky actions | ✅ | ◐ | ✅ | ◐ | ❌ | ✅ | ◐ | ◐ | ◐ | ◐ |
| Audit logs / audit trail | ✅ | ◐ | ? | ◐ | ❌ | ✅ | ? | ? | ? | ? |
| Secrets management / masking | ✅ | ✅ | ◐ | ◐ | ❌ | ◐ | ◐ | ◐ | ◐ | ◐ |
| Conversation persistence / resume | ✅ | ✅ | ◐ | ✅ | ? | ✅ | ✅ | ◐ | ◐ | ✅ |
| Environment snapshot/restore (incl processes) | ◐ | ◐ | ❌ | ◐ | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Network egress controls | ◐ | ◐ | ❌ | ◐ | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ |

Evidence anchors (selected): OH sub-agent delegation is a documented SDK feature with spawn/delegate operations. citeturn19view2 OH’s security system explicitly includes risk assessment, confirmation policy, action validation, and an audit trail stored in event history; the tool schema can include a `security_risk` field. citeturn6view2turn3search8 OH supports dynamic tool integration via MCP, plus plugin packaging that bundles skills/hooks/MCP/agents/commands. citeturn19view4turn19view3 AZ explicitly claims persistent memory, hierarchical multi-agent cooperation, OS-as-tool, and an open SKILL.md standard in its README and extensibility docs, including per-project isolation directories with knowledge/memory/secrets. citeturn12view0turn11view0turn11view1 AZ’s public architecture page explicitly lists A2A support via FastA2A and MCP interoperability. citeturn3search2turn3search14 OC’s docs describe ClawHub as a public skills registry and describe memory as plain Markdown files in the workspace; the gateway protocol is explicitly a WebSocket control plane for multiple client roles. citeturn13search0turn13search1turn13search10 DYT documents audit log permissions/scopes, signed preview URLs, and network limits (egress controls). citeturn9search3turn19view9turn9search1 E2B documents sandbox persistence (pause/resume) and outbound internet disablement. citeturn17search1turn18search2

image_group{"layout":"carousel","aspect_ratio":"16:9","query":["OpenHands agent workspace VNC VSCode Web interface","Agent Zero web UI screenshot","Claude Code Desktop app Code tab screenshot","OpenClaw gateway UI canvas screenshot","Daytona sandbox VNC browser interface","E2B desktop sandbox noVNC xfce screenshot","Block Goose desktop app screenshot"],"num_per_query":1}

## Agent Zero primitives that OpenHands covers vs what is missing

### Agent Zero core primitives

From AZ’s README and extensibility/architecture docs, the “primitives” that matter for your CCC question can be summarized as:

- **Project-scoped workspace as the unit of isolation**, backed by a directory structure that includes instructions, knowledge, memory storage, and secrets files; projects can be backed up/restored by copying that directory. citeturn11view0turn11view1turn12view0  
- **Extensibility by filesystem conventions**: prompts, tools, and lifecycle extensions are discovered and overridden by directory precedence rules. citeturn11view0  
- **“Computer as tool” with dynamic tool creation**: minimal default tools; new capabilities are created by writing code/scripts and then invoking them; skills use `SKILL.md` for portable instruction bundles. citeturn12view0  
- **Multi-agent hierarchy and communication**, plus an explicit **A2A interoperability** surface (via FastA2A per their public architecture page). citeturn12view0turn3search2turn3search14  
- **Persistent memory** (including vector DB usage and UI management in their docs). citeturn5search1turn5search7  

### OpenHands equivalents and gaps

Below is a pragmatic mapping oriented toward “can I build AZ’s core behaviors with OH SDK,” and if not, what is missing.

| AZ primitive | What OH already covers | Gap / what you’d build in CCC |
|---|---|---|
| Project-scoped workspace (files + secrets + knowledge + memory) | OH has a workspace abstraction and supports local/Docker/remote workspaces; it also has conversation state persistence/resume and an event log architecture. citeturn19view0turn19view1turn15search3 | OH does not standardize an AZ-like on-disk “project bundle” structure (instructions/knowledge/memory/secrets as conventional directories) as the primary UX object; CCC should define a portable “Mission Project” format and adapters (import/export) that can hydrate OH workspace + tools + skill context. citeturn11view0turn19view0turn19view1 |
| Extensibility by directory precedence (override prompts/tools/extensions) | OH supports custom tools, MCP integration, and plugin packaging (skills/hooks/MCP/agents/commands). citeturn15search17turn19view4turn19view3 | OH tool registration becomes tricky when running remote workspaces: there is an open issue noting that users cannot register custom tools when the conversation runs on the remote agent server, because the workflow is undocumented/missing. citeturn19view5 CCC needs a “remote tool distribution” mechanism (signed bundles) and a runtime loader on the agent server side. |
| “Computer as tool” + dynamic tool creation | OH gives a robust sandboxed execution environment (Docker), terminal/file tools, and interactive IDE/desktop/browser surfaces; agents can also be paused/resumed. citeturn14view0turn19view6turn7view4turn19view1 | OH does not make “agent-authored tools” a first-class discoverable tool lifecycle the way AZ does. In CCC, you can approximate with (a) a generic “run script” tool + (b) a tooling pipeline that can mint new tool schemas and register them (locally) or publish them (remotely) via MCP or plugin bundles. citeturn19view4turn19view3turn19view5 |
| Multi-agent delegation / hierarchy | OH has a documented sub-agent delegation tool that spawns multiple sub-agents with independent context and consolidates results. citeturn19view2 | OH delegation is “in-process / in-workspace,” not A2A network interoperability. CCC needs an A2A layer for cross-runtime and cross-vendor coordination. citeturn3search3turn3search25turn3search7 |
| Persistent memory + memory UI | OH supports persistence of conversation state/events and context condensation; it also has secrets masking and a security system that records decisions in event history. citeturn19view1turn15search3turn6view2turn14view0 | OH does not ship an AZ-style “memory dashboard” and does not (in core docs) standardize vector-memory semantics the way AZ describes (FAISS hybrid memory, memory UI). CCC should implement a memory packaging layer (event log + optional semantic store) and a UI browser/editor. citeturn5search7turn5search1turn15search3 |

## Required CCC components and interface sketches

This section defines the components you would add “above” OH to achieve a native-feeling universal mission control layer with runtime-configurable execution placement.

### Responsibilities table

| Component | Primary responsibility | Why it’s needed (tied to gaps) |
|---|---|---|
| Control Plane (CCC core) | Session lifecycle, agent configs, runner selection at runtime, surface registry, policy decisions | OH provides powerful execution/surfaces, but CCC needs multi-runner orchestration and a unified UX that is runtime-location agnostic. citeturn19view0turn7view4 |
| Runner Plugin API | Standard interface to start/stop/pause/resume sessions and expose surfaces across OH/DYT/E2B/host/VM | Enables “stub agent on host but others decided” by swapping execution backends without rewriting UI. citeturn19view0turn14view0turn19view9turn17search1 |
| Surface Gateway + Tunnel | Normalize access to VNC/term/file/preview/browser/CDP; NAT traversal; session multiplex | Daytona’s signed preview URLs show why tunneling must be productized; OH/AIS/E2B VNC endpoints need consistent auth + routing. citeturn19view9turn7view4turn8view2turn19view8 |
| A2A Protocol Layer | Agent discovery (agent cards), cross-runtime delegation, streaming, auth | A2A is explicitly designed for inter-agent interoperability; AZ claims A2A support, CCC should not remain single-vendor. citeturn3search3turn3search11turn3search25turn3search2 |
| Skills/Tool authoring pipeline | Build, sign, scan, distribute tool/skill packages; integrate MCP servers | Needed to safely support a “marketplace” model without repeating the supply chain failures seen in open skill registries. citeturn19view3turn13search0turn13news37turn13search17 |
| Memory packaging | Define a portable “Mission Project” format: instructions, knowledge, memory, secrets refs, artifacts | Unifies AZ-style file-first memory and OH event logs; enables export/import and cross-runner portability. citeturn13search1turn19view1turn15search3 |
| Policy engine + audit | Tool permissioning, confirmations, provenance labels, audit records across runners | Prompt-injection and tool-abuse require enforcement at tool/API layer, not in prompts alone; OH provides core primitives to build on. citeturn6view2turn4search0turn4search4turn4search15 |
| Snapshot/restore + recorder/replay | Environment snapshot hooks, deterministic event replay, VNC/terminal recording, session playback | OH event-sourcing + persistence helps; DYT snapshots and E2B pause/resume show what a “session” means operationally. citeturn19view1turn9search3turn17search1turn15search3 |

### Interface sketches

Below are deliberately “thin waist” interfaces: keep CCC stable while runners evolve. (TypeScript-style sketch; not tied to any specific implementation language.)

```ts
// Core IDs
type SessionId = string;
type RunnerId = string;
type SurfaceId = string;

// Where execution happens (dynamic at runtime)
type RunnerKind = "openhands" | "daytona" | "e2b" | "host" | "vm" | "remote-api";

// What a surface is (CCC embeds these: terminal, VNC, browser, VSCode, file tree, previews)
type SurfaceKind =
  | "terminal"
  | "vnc"
  | "rdp"
  | "browser"
  | "cdp"
  | "vscode-web"
  | "files"
  | "artifact-viewer"
  | "preview-url";

interface SurfaceDescriptor {
  id: SurfaceId;
  kind: SurfaceKind;
  title: string;

  // How CCC can connect (often via Surface Gateway)
  endpoint: {
    url: string;                 // may be a local proxy URL
    protocol: "ws" | "wss" | "https";
    auth: "session-token" | "signed-url" | "oauth2" | "none";
    expiresAt?: string;          // ISO datetime
  };

  // Capabilities CCC can toggle
  capabilities?: {
    readOnly?: boolean;
    userTakeover?: boolean;
    recordable?: boolean;
    multiplexKey?: string;       // for gateway routing
  };
}

interface RunnerSessionHandle {
  runnerId: RunnerId;
  sessionId: SessionId;
  surfaces: SurfaceDescriptor[];
}

interface Runner {
  id: RunnerId;
  kind: RunnerKind;
  label: string;

  // Create and start a session
  createSession(input: {
    projectRef: string;            // CCC “Mission Project” reference
    agentProfile: string;          // per-session agent config
    executionPolicyRef: string;    // policy profile
    resources?: { cpu?: number; memMB?: number; diskGB?: number };
    network?: { egressMode: "denyAll" | "allowList" | "open"; allowList?: string[] };
  }): Promise<RunnerSessionHandle>;

  pauseSession(sessionId: SessionId): Promise<void>;
  resumeSession(sessionId: SessionId): Promise<void>;
  terminateSession(sessionId: SessionId): Promise<void>;

  // Snapshot semantics vary; runner can implement or no-op
  snapshot(sessionId: SessionId, name: string): Promise<{ snapshotRef: string }>;
  restore(sessionId: SessionId, snapshotRef: string): Promise<void>;
}

// Policy + audit are centralized in CCC (runners report events; CCC decides)
type Risk = "LOW" | "MEDIUM" | "HIGH" | "UNKNOWN";

interface PolicyDecision {
  allow: boolean;
  requireHumanApproval?: boolean;
  redactions?: string[];          // secret paths/tokens to redact in UI
  reason: string;
}

interface AuditRecord {
  at: string;
  sessionId: SessionId;
  actor: { type: "user" | "agent" | "system"; id: string };
  action: { kind: string; summary: string; risk: Risk };
  decision: PolicyDecision;
  provenance?: { source: "tool" | "a2a" | "mcp" | "ui"; ref?: string };
}
```

These signatures are directly motivated by: OH’s clear separation of workspace implementations (local/docker/remote) and its event/audit-friendly security system; DYT’s signed preview URL mechanism; and E2B’s explicit lifecycle and pause/resume semantics. citeturn19view0turn6view2turn19view9turn17search1turn18search2

## Phased roadmap with effort and security risks

Effort here is relative (low/medium/high). Dates are omitted intentionally because feasibility depends heavily on your chosen desktop stack and how much you reuse versus re-implement.

### MVP

Deliverables (goal: a usable “mission control” for one user, one primary runner):

- CCC desktop shell with **session list**, **runner selector**, and **surface tabs** (terminal + files + VNC + VSCode Web + visible browser where available). OH makes this unusually achievable because those surfaces are already part of its “interactive workspace access” concept. citeturn14view0turn7view4  
- OpenHands Runner adapter using OH agent server and workspace options (local/docker first; remote API optional). citeturn19view0turn19view6turn7view4  
- Policy engine v0: integrate OH risk levels/confirmation policies and audit trail surfaced in CCC (even if single-user). citeturn6view2turn3search8  
- Conversation persistence and restore using OH persistence guide (session resumption). citeturn19view1turn15search3  

Effort: **medium** (most heavy lifting is UI + runner abstraction, not low-level execution).  
Primary risks: prompt injection into tool actions; secrets leakage; unsafe tool defaults. The OWASP Top 10 calls prompt injection a first-class risk; therefore, enforce permissions at the tool/policy boundary rather than relying on prompts. citeturn4search0turn4search4turn6view2

### v1

Deliverables (goal: “universal” across at least one remote sandbox and with tunneling):

- Add **Surface Gateway** with session multiplexing, uniform auth, and optional recording hooks. (Start with VNC + terminal websockets; expand later.) The objective is to make “where it runs” invisible to CCC. citeturn7view4turn19view9  
- Add remote sandbox runner (recommended first: **DYT**), primarily because signed preview URLs and org controls reduce custom tunneling/auth work. citeturn19view9turn9search3turn9search1  
- Add a “Mission Project” portable format (import/export) that can hydrate either OH workspaces or DYT sandboxes, inspired by AZ projects and OC file-first memory. citeturn11view0turn13search1turn19view0  
- Tool/skill packaging pipeline v1: internal registry + signing + basic static scanning; treat text-based skills as **supply chain artifacts**. This is not theoretical: public reporting shows malware and prompt-injection patterns in skill marketplaces for local agents. citeturn13news37turn13search17turn4news38  

Effort: **high** (tunneling, auth, multi-runner semantics, artifact pipeline).  
Primary risks: extension supply-chain risk; cross-surface auth confusion; accidental exposure of preview links or VNC endpoints; egress misconfiguration. citeturn13news37turn19view9turn9search1

### v2

Deliverables (goal: “deep” multi-agent coordination, cross-runtime interoperability):

- Implement **A2A layer**: agent discovery (agent card), JSON-RPC endpoint, auth, and streaming; integrate with CCC so a session can delegate to other sessions (remote or local) using A2A rather than only intra-runner delegation. Google’s published A2A materials and third-party security analysis emphasize both interoperability and the need for careful transport/auth hardening. citeturn3search3turn3search7turn3search25turn3search37  
- Build “federated runner graph”: CCC as control plane, multiple runners as execution backends, A2A as the cross-runner coordination fabric. citeturn3search11turn19view0turn19view9turn17search1  
- Enterprise-grade governance: multi-user RBAC, audit export, policy-as-code, secret vault integration, default-deny egress, and strong provenance UI (explicit labels for untrusted retrieved content). citeturn6view2turn9search3turn4search0turn2academia40  

Effort: **high**.  
Primary risks: protocol-level vulnerabilities and privilege escalation across agents (A2A + MCP); “indirect prompt injection” through retrieved tool descriptions or web content; credential theft via extensions. citeturn2academia40turn4search2turn4search15turn13search12

## Integration patterns and diagrams

### Control plane ↔ runners ↔ surfaces

```mermaid
flowchart LR
  subgraph CCC["CCC Desktop + Control Plane"]
    UI["Native-feeling UI\nSessions • Surfaces • Artifacts"]
    POL["Policy Engine\n(confirm/deny/audit)"]
    MEM["Memory + Project Packaging\n(import/export)"]
    A2A["A2A Router\n(agent cards + JSON-RPC)"]
    GW["Surface Gateway\n(auth + multiplex + record)"]
  end

  subgraph Runners
    OH["Runner: OpenHands\n(local/docker/remote API)"]
    DYT["Runner: Daytona\n(remote sandbox)"]
    E2B["Runner: E2B\n(remote sandbox)"]
    HOST["Runner: Host\n(local tools)"]
  end

  subgraph Surfaces
    VNC["VNC/noVNC"]
    TERM["Terminal / PTY"]
    FILES["Workspace FS"]
    BROWSE["Visible Browser / CDP"]
    VSC["VSCode Web"]
    PREV["Preview URLs"]
  end

  UI --> POL
  UI --> MEM
  UI --> A2A
  UI --> GW

  POL --> Runners
  A2A --> Runners
  MEM --> Runners

  OH --> GW
  DYT --> GW
  E2B --> GW
  HOST --> GW

  GW --> VNC
  GW --> TERM
  GW --> FILES
  GW --> BROWSE
  GW --> VSC
  GW --> PREV
```

This diagram mirrors the core idea in OH: separate agent logic, tools, conversation state, and workspace execution so that UIs can observe and intervene through surfaces; CCC generalizes that idea to multiple runner backends and adds tunneling, policy, and inter-agent routing. citeturn7view4turn19view0turn14view0turn19view9

### Roadmap timeline sketch

```mermaid
gantt
  title CCC roadmap (relative)
  dateFormat  YYYY-MM-DD

  section MVP
  CCC shell + OH runner + core surfaces :a1, 2026-03-01, 30d
  Policy v0 + audit trail UI           :a2, 2026-03-10, 25d
  Persistence/resume integration       :a3, 2026-03-15, 20d

  section v1
  Surface Gateway + multiplex/auth     :b1, 2026-04-01, 45d
  Remote runner (Daytona recommended)  :b2, 2026-04-10, 40d
  Mission Project packaging v1         :b3, 2026-04-15, 35d
  Tool/skill pipeline v1 (sign/scan)   :b4, 2026-04-20, 45d

  section v2
  A2A router + federation              :c1, 2026-06-01, 60d
  Recorder/replay + provenance UX      :c2, 2026-06-15, 60d
  Enterprise governance hardening      :c3, 2026-07-01, 75d
```

Dates are placeholders only; the true dependency is: **runner API + surface gateway** must stabilize before you can safely add A2A federation and a tool marketplace. citeturn3search3turn6view2turn19view9turn13news37

## Choosing Daytona vs E2B as the first remote sandbox runner

Both DYT and E2B can be plugged into CCC as “remote computer” runners. The decision is less about raw capability (both can host interactive desktops) and more about which one reduces the amount of custom control-plane infrastructure you must build.

### When Daytona is the better first choice

Pick DYT first if CCC’s priorities include:

- **Built-in shareable surface links with embedded auth** (signed preview URLs). This is close to the “tunneling/NAT traversal” primitive CCC needs for remote surfaces without forcing every consumer to set custom headers. citeturn19view9  
- **Org-level governance primitives**: permissions/scopes and audit logs are explicitly documented in its reference materials. citeturn9search3  
- **Network egress limiting** as a platform feature (critical for agent containment). citeturn9search1  
- Human oversight surfaces like VNC (documented as in-browser desktop). citeturn19view7  

### When E2B is the better first choice

Pick E2B first if CCC’s priorities include:

- A “computer use” **desktop template** that is explicitly positioned for GUI agents (Ubuntu + XFCE + VNC streaming) and includes common automation tools for GUI control. citeturn19view8turn17search0  
- **Pause/resume persistence** that preserves running processes, memory, filesystem state (useful for long “agent shifts” and reproducible debugging). citeturn17search1  
- Simple **internet access gating** at sandbox creation time for containment (deny outbound). citeturn18search2  

### Recommendation for a CCC path

If you must choose **one** first: choose **DYT** as runner #2 (after OH local/docker), because CCC’s hardest missing capability is not “can I run a desktop,” but “can I safely expose and route surfaces across networks with sane auth, audit, and egress defaults.” DYT’s signed preview URLs and org primitives reduce bespoke tunnel + auth + audit work and align with CCC’s mission-control focus. E2B becomes an excellent additional runner once your gateway abstraction is stable. citeturn19view9turn9search3turn9search1turn19view8turn17search1

## Security notes for a CCC that supports skills, tunneling, and deep coordination

A CCC “mission control” that can run code, control browsers/desktops, install skills, and interconnect agents is inherently high-risk. The goal is not perfect safety; it is **controlled blast radius** with strong auditing and explicit trust boundaries.

Key risk themes and concrete mitigations:

- **Prompt injection is a first-class vulnerability** for tool-using agents. The OWASP guidance describes prompt injection as manipulating model behavior via inputs, including bypassing controls. Therefore, CCC must enforce authorization at the tool/surface boundary, not via “better prompts.” citeturn4search0turn4search4  
- **Tool description mismatch / misleading tool UX** is an emerging MCP ecosystem risk: research highlights that description–implementation inconsistency can shape agent decisions and enable privileged actions. CCC should label tool provenance (trusted vs untrusted), require signing for tool packages, and add automated audits/scans. citeturn2academia40  
- **Skill marketplaces become software supply chains**. Public reporting on skill registries for local agents describes malware distribution and prompt-injection-as-install-path patterns; treat skills like executable packages: require signatures, sandbox evaluation, and deny-by-default capabilities. citeturn13news37turn13search17turn13search15turn4news38  
- **Secrets and logs**: OH’s auto-masking and secret injection patterns are a strong baseline; extend CCC so that secrets are never rendered into UI logs, and are injected only at execution time with strict scoping. citeturn7view2turn6view2  
- **Network egress**: default-deny egress is a practical containment lever. DYT explicitly supports network limits; E2B supports disabling internet access at sandbox creation; CCC policy should choose deny-by-default unless a task explicitly requires outbound calls. citeturn9search1turn18search2  
- **A2A expands the attack surface**: cross-agent delegation can become cross-privilege escalation if a less-trusted agent can coerce a more-trusted agent. Use strict auth, per-agent identity, least privilege, and explicit approval boundaries for handoffs; security guides emphasize careful binding choices and testing. citeturn3search25turn3search37turn4news42  

### Source index (direct links in code)

```text
OpenHands SDK docs:           https://docs.openhands.dev/sdk
OpenHands SDK paper (HTML):   https://arxiv.org/html/2511.03690v1
OpenHands persistence guide:  https://docs.openhands.dev/sdk/guides/convo-persistence
OpenHands delegation guide:   https://docs.openhands.dev/sdk/guides/agent-delegation

Agent Zero repo:              https://github.com/agent0ai/agent-zero
Agent Zero extensibility doc: https://raw.githubusercontent.com/agent0ai/agent-zero/main/docs/extensibility.md

Claude Desktop MCP support:   https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop
Claude Code Desktop docs:     https://code.claude.com/docs/en/desktop
Anthropic desktop extensions: https://www.anthropic.com/engineering/desktop-extensions

OpenClaw repo + docs:         https://github.com/openclaw/openclaw
OpenClaw gateway protocol:    https://docs.openclaw.ai/gateway/protocol
OpenClaw ClawHub docs:        https://docs.openclaw.ai/tools/clawhub
OpenClaw memory docs:         https://docs.openclaw.ai/concepts/memory

AIO Sandbox repo:             https://github.com/agent-infra/sandbox

Daytona docs:                 https://www.daytona.io/docs/en/
Daytona preview URLs:         https://www.daytona.io/docs/en/preview/
Daytona VNC access:           https://www.daytona.io/docs/en/vnc-access/

E2B desktop template:         https://e2b.dev/docs/template/examples/desktop
E2B sandbox persistence:      https://e2b.dev/docs/sandbox/persistence
E2B internet access control:  https://e2b.dev/docs/sandbox/internet-access

A2A protocol (Google blog):   https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
A2A codelab:                  https://codelabs.developers.google.com/intro-a2a-purchasing-concierge
A2A security guide:           https://semgrep.dev/blog/2025/a-security-engineers-guide-to-the-a2a-protocol

OWASP LLM Prompt Injection:   https://genai.owasp.org/llmrisk/llm01-prompt-injection/
OWASP Top 10 for LLM Apps:    https://owasp.org/www-project-top-10-for-large-language-model-applications/
```