Cloud Harness MCP

Cloud Harness MCP is an MIT-licensed remote coding harness exposed through authenticated Streamable HTTP MCP. It opens an isolated clone in a TTL-limited Docker executor and gives a trusted owner or named mutually trusted operators structured workspace, file, code-intelligence, command, shell, session, dependency-task, Git, worktree, skill, hook, memory, and repository-defined deployment tools.

[!WARNING] This is a private service for one security domain. Its operators must trust one another because it is intentionally capable of arbitrary command execution inside a shared-kernel executor. Principal isolation is not a hostile multi-tenant sandbox. Read the security model before operating it.

The Managed OAuth MCP URL is:

https://harness.zuey.me/mcp

Static-header clients use dashboard-managed API keys at the separate gateway:

https://api.harness.zuey.me/mcp

Architecture

MCP is the northbound control protocol; the harness is the execution runtime. The split keeps Internet-facing request handling away from Docker authority and keeps repository credentials out of long-lived executors.

flowchart LR
  OAuthClient["Managed OAuth client"] -->|"Access OAuth"| Nginx["nginx + loopback ingress"]
  StaticClient["Static-header client"] -->|"managed API key"| Gateway["Cloudflare Worker gateway"]
  Gateway -->|"Access service assertion + API key"| Nginx

  subgraph Control["Trusted control plane"]
    Nginx --> API["Stateless MCP API"]
    API -->|"private authenticated RPC"| Runner["Runner · policy · lifecycle"]
    Runner --> Store[("SQLite workspace state")]
    Runner --> Docker["Docker authority"]
    Runner --> Broker["GitHub App broker"]
  end

  subgraph Execution["TTL-bound execution plane"]
    Docker --> Executor["Non-root workspace executor"]
    Docker --> GitHelper["Ephemeral Git transfer helper"]
    Executor --> Repo[("Isolated repository clone")]
  end

  Broker -->|"short-lived token over stdin"| GitHelper
  GitHelper -->|"validated HTTPS origin"| GitHub["GitHub repository"]
  Executor -.->|"no control-plane credential"| GitHub

The source of truth for these boundaries is compose.yaml, apps/runner/src/workspace-service.ts, and the security model.

Coding workflow

sequenceDiagram
  participant C as AI client
  participant A as MCP API
  participant R as Runner
  participant E as Isolated executor
  participant G as Ephemeral Git helper
  participant H as GitHub

  C->>A: workspace_open(repositoryUrl, idempotencyKey)
  A->>R: authenticated operation
  R->>G: constrained clone + optional short-lived token
  G->>H: credential-free or GitHub App HTTPS clone
  R->>E: start bounded workspace container
  R-->>C: opaque workspaceId
  C->>E: inspect, edit, test, session, task graph, commit
  C->>R: git_push(refspec, forceWithLease?, expectedRemoteOid?)
  R->>G: stage clean bare transfer + short-lived token
  G->>H: origin-only push
  G-->>R: bounded sanitized result
  R-->>C: structured MCP result
  C->>R: workspace_close(workspaceId)
  R->>E: terminate and remove

Remote fetch, pull, and push use a sibling transfer repository that the executor cannot see. Push requires a GitHub App installation with repository write access; clone/fetch/pull need read access. See configuration and MCP semantics.

Getting started

1. Read the security model, then configure one of the supported clients below with the owner token kept in local private configuration.
2. Ask the client to call workspace_open with a credential-free HTTPS repository URL and a fresh idempotency key. Keep the returned opaque workspaceId; do not derive it from a path or repository name.
3. Use the bounded tools in the existing workspace, then close shells, sessions, and unwanted tasks before calling workspace_close.

Start with the normal workflow in MCP usage for lifecycle, cursor, network, and Git-transfer semantics.

Local stdio workspace mode

In addition to the remote HTTP/Docker service, Cloud Harness MCP can operate directly against an explicitly selected project folder on your local machine over stdio transport.

# Start local stdio server for a project:
cloud-harness-mcp --transport stdio --workspace /path/to/project

In local mode:

• The configured folder behaves as an already-opened workspace (with an opaque workspaceId). workspace_open is not required.
• File operations, patches, grep search, symbol search, sessions, tasks, and local Git tools operate directly on the folder.
• workspace_close terminates owned child processes and tasks but never deletes your local project folder.
• Tool paths and working directories are strictly confined within the workspace root.
• Commands (exec_run, shells, tasks) execute with host-user permissions. File path confinement is not an OS sandbox.
• Network Git (git_fetch, git_pull) and Git push (git_push) are disabled by default and require explicit startup opt-in flags (--git-network, --git-push).
• v1 supports POSIX (Linux and macOS); Windows process semantics are a documented follow-up (use WSL on Windows).

To serve several persistent project folders from one process, register them in a versioned YAML/JSON file and pass --workspace-config instead of --workspace. It works over stdio, or over --transport http as an authenticated local endpoint that needs no Docker runner. Each folder keeps its own path confinement, processes, and stable workspaceId. See Several local workspaces from one server for the file format and client setup, and MCP usage for selection and failure semantics.

CLI options

Configuring local stdio in AI clients

Claude Desktop

In ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or ~/.config/Claude/claude_desktop_config.json (Linux):

{
  "mcpServers": {
    "cloud-harness-local": {
      "command": "node",
      "args": [
        "/path/to/cloud-harness-mcp/apps/api/dist/index.js",
        "--transport",
        "stdio",
        "--workspace",
        "/path/to/my-project"
      ]
    }
  }
}

Claude Code

claude mcp add cloud-harness-local --transport stdio -- node /path/to/cloud-harness-mcp/apps/api/dist/index.js --transport stdio --workspace /path/to/my-project

Cursor

In .cursor/mcp.json:

{
  "mcpServers": {
    "cloud-harness-local": {
      "command": "node",
      "args": [
        "/path/to/cloud-harness-mcp/apps/api/dist/index.js",
        "--transport",
        "stdio",
        "--workspace",
        "/path/to/my-project"
      ]
    }
  }
}

OpenAI Codex

In ~/.codex/config.toml:

[mcp_servers.cloud_harness_local]
command = "node"
args = ["/path/to/cloud-harness-mcp/apps/api/dist/index.js", "--transport", "stdio", "--workspace", "/path/to/my-project"]

MCP tools

The public tool names are owned by RunnerOperationSchema. Inputs, bounds, and approval annotations are owned by TOOL_SPECS; the API registers each of those specs in mcp-server.ts.

Workspace lifecycle

workspace_open, workspace_list, workspace_status, workspace_capabilities, workspace_lease_renew, workspace_recover, workspace_context, workspace_set_active, workspace_close, secrets_list

Files and code intelligence

files_list, files_read, files_write, files_write_batch, files_apply_patch, files_delete, files_move, files_mkdir, grep_search, symbols_search, symbols_references

Commands, shells, sessions, and tasks

exec_run, shell_open, shell_io, shell_close, sessions_list, sessions_open, sessions_io, sessions_close, tasks_list, tasks_run, tasks_status, tasks_cancel, tasks_graph, operation_status, operation_cancel, operation_wait

Git and worktrees

git_status, git_diff, git_log, git_branch, git_checkout, git_add, git_commit, git_identity_status, git_identity_set, workspace_finalize, git_fetch, git_pull, git_push, git_merge, git_rebase, worktrees_list, worktrees_create, worktrees_remove, github_action

Repository extensions

skills_list, skills_read, skills_run, hooks_list, hooks_run, memories_list, memories_read, memories_write, deployments_list, deployments_run

The HTTP endpoint also serves built-in and owner skills through the io.modelcontextprotocol/skills protocol extension (skills/list, skills/get, resources/read); see Skills over MCP extension.

Retained artifacts

artifacts_snapshot, artifacts_list, artifacts_read, artifacts_restore, artifacts_delete

Install the Cloud Harness skill

Install the self-contained cloudharness operating skill directly from this repository with the skills CLI:

npx skills add bestagentkits/cloud-harness-mcp --skill cloudharness

Use --global to install it for the current user instead of the current project. The skill includes detailed, portable references for every public operation, input bound, side effect, recovery path, and security boundary. It does not install credentials or connect the MCP endpoint; complete one of the client configurations below separately.

This repository also publishes the same skill as a plugin package for both Claude Code and OpenAI’s plugin format.

Connect from AI clients

The owner deployment exposes two remote Streamable HTTP MCP lanes:

Managed OAuth: https://harness.zuey.me/mcp
Static API key: https://api.harness.zuey.me/mcp

The owner deployment uses cloudflare-access: Managed OAuth clients connect to the first URL and complete GitHub or Google login in the browser. Cloudflare Access is the OAuth authorization server for that lane; Cloud Harness verifies the assertion Access forwards (see how the Managed OAuth lane works). Static-header clients use only the second URL with Authorization: Bearer . Its dashboard is https://harness.zuey.me/dashboard.

Create, list, and revoke API keys under Dashboard → API keys. A new key is shown once and cannot be recovered; store it only in the client’s private credential store. Keys expire after 1–3,650 days (approximately 10 years), and each identity may have at most 10 active keys. There are no per-tool scopes or rotation endpoint: replace a key by creating a new one and then revoking the old one. Every key has the creator’s full MCP authority, including arbitrary command execution in the executor. Revocation or expiry denies the next request.

The API-key gateway is not an alternate dashboard login and does not accept Managed OAuth. Conversely, https://harness.zuey.me/mcp does not accept a dashboard-managed API key. See the security model for the independent Worker/Access/key checks.

owner-bearer remains the software default for separate private deployments. The direct-header examples below use CLOUD_HARNESS_MCP_TOKEN. For this owner deployment, set it to a dashboard-managed key and use https://api.harness.zuey.me/mcp. For a separate owner-bearer deployment, use the owner-provided token and https:///mcp. Keep the credential and URL in client-local private configuration; never put the token in a repository, prompt, or shared project configuration.

Other operators may deploy cloudflare-access on an eligible hostname in an owned Cloudflare zone. Access provides Managed OAuth and GitHub/Google SSO; Cloud Harness verifies the forwarded assertion and exposes the dashboard at /dashboard. Treat client login as supported only after the exact client, Access policy, discovery, refresh, and revocation flow has been verified live. Implementation, merge, and Cloudflare configuration are separate evidence states. See configuration and deployment.

Granting either form of access grants remote execution authority. Read the security model before connecting it.

Start by asking a connected client to call workspace_open with a credential-free HTTPS repository URL and a new idempotency key. Reuse the returned opaque workspaceId for later calls and finish with workspace_close. See MCP usage for the workflow and important semantics.

Run locally

Prerequisites are Node.js 24+, npm, Docker Engine, and Docker Compose v2.

npm ci
cp .env.example .env
# Replace every change-me value in .env with an independent random secret.
docker compose --profile images build executor-image api runner
docker compose up -d runner api ingress
curl --fail http://127.0.0.1:3100/readyz

Local Compose publishes only a credential-free TCP ingress proxy on host loopback. The API and runner remain on separate internal networks; only the runner has Docker authority. Local Compose does not configure TLS. Stop it with:

docker compose down

Configure environment variables

The local setup command above creates an ignored runtime environment file from the maintained template. Generate two independent secrets, then replace the two placeholder values in that runtime file:

openssl rand -hex 32 # MCP_BEARER_TOKEN
openssl rand -hex 32 # RUNNER_TOKEN

Both tokens must contain 32–512 characters. Never commit the runtime file or paste either value into prompts, logs, or shared project configuration. When a direct secret and its _FILE alternative are both set, the file value takes precedence.

The server-side MCP_BEARER_TOKEN is the owner credential accepted by /mcp. The client examples above store that same value under the client-local name CLOUD_HARNESS_MCP_TOKEN. RUNNER_TOKEN is a separate, internal API-to-runner credential and must never be given to an MCP client.

Required and common settings

The values below are runtime defaults when a variable is omitted. The maintained template may prefill the current public host and browser origin; replace those entries with the hostname and origins of your deployment.

The maintained template contains every setting needed for the normal local Compose workflow. The following limits are optional; omit them to use their validated defaults.

Resource and request limits

Optional private GitHub repositories

Public repositories need no additional credential. For private clone, fetch, pull, or push, configure all three GitHub App values together:

The App needs Contents read permission for clone, fetch, and pull; push needs Contents read and write. Production Compose mounts the root-owned host directory /etc/cloud-harness-mcp read-only at /run/cloud-harness-secrets, so the maintained container path is /run/cloud-harness-secrets/github-app-private-key.pem. Prefer the file form instead of placing a private key directly in an environment variable. Follow the private GitHub repository setup guide for App creation, least-privilege permissions, installation, key handling, verification, troubleshooting, and rotation.

Compose overrides

Compose fixes API_HOST=0.0.0.0, API_PORT=3000, RUNNER_HOST=0.0.0.0, RUNNER_PORT=3001, and RUNNER_URL=http://runner:3001 on its private networks. Those variables are available when starting the Node.js processes directly, but changing them in the Compose runtime file has no effect because the service definition owns the wiring. Keep the API and runner private and publish only the loopback ingress.

For production file ownership, key mounts, and TLS setup, use the deployment guide. Exact validation rules and defaults remain owned by packages/contracts/src/config.ts, with operational rationale in the configuration guide.

Documentation

• Installable cloudharness operating skill
• Cloud Harness support
• Privacy policy and terms of service
• System architecture
• MCP usage and tool semantics
• Configuration
• GitHub App setup for private repositories
• Security model
• Development and testing
• Operations, backup, rollback, and cleanup
• VPS deployment with nginx and Certbot
• Cloudflare Pages landing page
• Troubleshooting

The repository is public at bestagentkits/cloud-harness-mcp and licensed under the MIT License.