DECISION: skipped 2026-06-04 — revisit if/when we want chat-driven headless control; research preserved below.
Status: research + proposal (go/no-go) · Date: 2026-06-04 · Author: docs/scribe agent Decision owner: owner · Scope: evaluate OpenClaw as the runtime for a headless second MacBook that is never physically touched — it pulls work and reports via GitHub, and the owner steers it from a phone chat channel. Laptop 1 stays the interactive swarm; the two machines coordinate through GitHub, not a shared local bus.
All figures below were verified on 2026-06-04 against the live GitHub API and raw repo files (
gh api repos/..., LICENSE,.env.example,SECURITY.md,skills/,docs/), not marketing copy. Where a claim could not be verified it is marked (unverified).
Conditional GO for a tightly-scoped pilot. NO-GO for granting it production or 1Password-prod access on day one.
OpenClaw is a real, hyperactive, MIT-licensed, local-first agent gateway with exactly the primitives this idea needs: many chat channels (incl. iMessage/Telegram/WhatsApp/Slack for phone control), a headless gateway, multi-agent routing across "nodes", and first-class github + gh-issues skills that already "fetch issues → spawn background fix agents → open PRs." That gh-issues skill is the GitHub-as-the-channel wiring, off the shelf.
But its own SECURITY.md is explicit that it is "local-first agent infrastructure for trusted operators; it is not designed as a shared multi-tenant boundary" and that prompt injection without a further bypass is not even in scope as a vulnerability. For a PII shop under GDPR (auditPic photos, claimio claims, europeLogin/valideerleeftijd identity data), that threat-model gap is the whole ballgame. The safe path is: run it on a dedicated low-privilege machine, give it a fine-grained GitHub token scoped to one or two non-PII repos, no production 1Password vault, no VPS SSH key, staging-only, human-gated merges — and treat it as a worker host the existing manager dispatches to, not a replacement for the laptop-1 swarm.
Smallest safe pilot in §6.
Repo: openclaw/openclaw — tagline "Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞" (verified).
| Signal | Value (verified 2026-06-04) | Read |
|---|---|---|
| Stars | 376,761 | Genuinely huge / mainstream — not a toy. |
| Forks | 78,732 | Very large contributor/derivative base. |
| Open issues | 7,599 | Big active backlog (scale, not neglect). |
| Created | 2025-11-24 | ~6 months old → fast-moving, churny API surface. |
| Last commit | 2026-06-04 (today) | Daily-active development. |
| Latest release | v2026.6.1 (2026-06-03) | CalVer; ships stable/beta/dev channels. |
| Language | TypeScript | Node runtime; pnpm workspace, Docker image, fly.toml/render.yaml deploy targets present. |
| Copyright | OpenClaw Foundation (2026) | Foundation-governed; maintainers reportedly incl. engineers from NVIDIA and Tencent per SECURITY.md. |
License — important nuance. The GitHub API reports NOASSERTION / "Other", and the fast page-summary even guessed "MIT" without checking. The actual LICENSE file is standard MIT ("Copyright (c) 2026 OpenClaw Foundation") with one appended line pointing to THIRD_PARTY_NOTICES.md — that addendum is why GitHub's classifier won't assert a clean SPDX match. Net: it is MIT, but anyone doing license review should read LICENSE + THIRD_PARTY_NOTICES.md directly rather than trusting the badge. (verified by reading the raw LICENSE.)
Maturity verdict: mainstream adoption and daily commits, but young (6 months) and CalVer-churny — expect breaking changes release-to-release. Pin a version; don't track dev.
Enderfga/claw-orchestrator (the repo formerly named openclaw-claude-code; GitHub now redirects it to Enderfga/claw-orchestrator). "Run Claude Code, Codex, Gemini, Cursor Agent and custom coding CLIs as one unified runtime for claw-style agent systems. Runs standalone, with first-class OpenClaw plugin support." 489 stars, 78 forks, v4.1.2 (2026-06-03), MIT, TypeScript (91.7%). Wraps coding CLIs as persistent programmable headless sessions and registers as an OpenClaw plugin via ~/.openclaw/openclaw.json (its README claims a "55-tool API" — tool count unverified, plugin-registration mechanism verified by description).openclaw/acpx — "Headless CLI client for stateful Agent Client Protocol (ACP) sessions." 2,815 stars, 276 forks, v0.9.0 (2026-05-22), MIT, TypeScript. Agent-to-agent over a structured protocol (persistent multi-turn, named parallel sessions, prompt queuing, cooperative cancel); supports Claude/Codex/Gemini/OpenClaw and others. v0.9.0 = pre-1.0, treat as experimental.These two matter because they're how OpenClaw drives Claude Code specifically in headless mode — i.e. how our existing worker model (Claude Code) plugs into the gateway.
Recommendation: HOST, don't replace. Map it onto our roles deliberately.
Our current model (from SWARM.md / .swarm/): a thin orchestrator (human valve) → a manager (coordinates, dispatches) → ephemeral one-shot workers (do the work), liveness measured by bus activity, launched by start-claude.sh.
OpenClaw's relevant primitives (verified from skills/ and docs/):
docs/gateway/, OPENCLAW_GATEWAY_TOKEN) — the long-running headless daemon that receives messages and routes to agents.docs/channels/, skills/{slack,discord,imsg,...}) — chat front-ends incl. iMessage (imsg), Telegram, WhatsApp, Slack, Discord, Signal, Matrix, Teams (channel list verified from README + .env.example bot-token vars).docs/nodes/, skills/node-connect, node-inspect-debugger) — route a request to one of several agents / remote nodes.coding-agent skill + claw-orchestrator/acpx — run Claude Code etc. as the actual coding worker.Two architectures:
.swarm/ bus, watchdog/keepalive resilience, stuck-worker reaper, and sanity-rung discipline — all hard-won. Re-earning that maturity on a 6-month-old runtime is a poor trade.gh-issues/coding-agent skills, picks up GitHub issues labelled for it, runs Claude Code headless, opens PRs. The phone chat channel gives the owner a direct line to laptop-2 for steering/aborting — a feature laptop-1 doesn't have today. Coordination between the two machines is GitHub state (issues/PRs/labels), never a shared local bus — which is exactly the requested decoupling.So: OpenClaw earns its place as the phone-controllable headless worker host, not as a second brain.
This is OpenClaw's strongest fit. The gh-issues skill (verified, user-invocable: true, primaryEnv: GH_TOKEN, requires git+gh) is described verbatim as:
"Fetch GitHub issues, select candidates, spawn background fix agents, open PRs, and optionally process PR review comments."
That is the entire inbound/outbound loop out of the box. Combined with the github skill ("GitHub CLI for issues, PRs, CI/check logs, comments, reviews, releases, repos, and gh api queries", requires gh):
Work in: laptop-1 manager (or owner via phone) files/labels a GitHub issue (e.g. swarm:laptop2, on a permitted repo). Laptop-2 OpenClaw polls via gh-issues, claims candidates.
Work out: the coding-agent session does the work in a feature branch; gh-issues/github opens a PR, posts status comments, and can process review comments. CI runs as normal. Merges stay human/owner-gated (matches the standing staging-first, prod owner-gated policy).
Coordination = GitHub only. No cross-machine bus. The two swarms never share .swarm/; the contract is issue labels + PR state + comments. Idempotency/claim races are handled by an assignee/label convention (e.g. an issue is "claimed" by self-assigning before work starts) — (this convention is ours to define; OpenClaw provides the gh primitives, not the policy.)
Auth: the gh-issues skill reads GH_TOKEN — so the entire blast radius is whatever that one token can touch (see §5).
Verified building blocks: Docker image + docker-compose.yml, docs/vps.md (headless server deploy), docs/install/, docs/channels/, OPENCLAW_GATEWAY_TOKEN auth, OPENCLAW_AUTH_PROFILE_SECRET_DIR for at-rest key material. Steps below are the standard headless pattern; treat exact commands as to-be-confirmed against docs/install + docs/gateway at pilot time — the API is young.
imsg.caffeinate -dimsu under a LaunchDaemon, plus pmset (sleep 0, disablesleep 1, autorestart 1, womp 1 for wake-on-power-loss). Auto-login the dedicated user so a reboot returns to a working state unattended.v2026.6.1), not dev. Install gh + git (+ op only if §5 says so). gh auth login with the scoped token.OPENCLAW_GATEWAY_TOKEN and OPENCLAW_AUTH_PROFILE_SECRET_DIR outside the repo. Mirror our existing watchdog/keepalive pattern (launchd KeepAlive + a health tick) so a crashed gateway self-heals like the laptop-1 orchestrator does.TELEGRAM_BOT_TOKEN, simplest, locked to the owner's chat ID) or iMessage (imsg skill, needs the Mac signed into iMessage). Restrict the gateway to a single authorized sender. This is the "steer from a phone" surface: status, pause/abort, re-prioritize.github, gh-issues, coding-agent (+ the chosen chat channel). Disable everything else (shell-heavy, notes, browser, voice) for the pilot.swarm:laptop2 issues on the pilot repo → owner says "take #N" → bot branches, runs Claude Code, opens a PR, replies with the PR link. Done without touching the machine.Cross-ref: this same untouched 2nd Mac is also the natural home for the dedicated self-hosted CI runner discussed in docs/ops/ci-alternatives-proposal.md §3 "Fastest unblock: self-hosted runner" — that proposal currently assumes the runner lives in a Linux container on laptop 1. A forthcoming 2nd-Mac dedicated-runner runbook should cover moving that runner here too, so the machine does double duty (CI runner + OpenClaw worker host). Keep the two concerns isolated: the CI runner and the OpenClaw gateway should run as different OS users with different tokens — a CI runner with repo-write + GHCR push is a very different blast radius from the agent gateway, and they must not share credentials.
.env.example + skill metadata)| Credential | Where | Scope risk | Pilot stance |
|---|---|---|---|
| GH_TOKEN / gh auth | gh-issues (primaryEnv: GH_TOKEN), github skill | Highest — this is the work channel. A broad PAT = write to every repo, incl. PII repos. | Fine-grained PAT, 1–2 non-PII pilot repos only, contents+PR+issues write, no admin, no org, 30-day expiry. Never a classic PAT. |
| Model provider keys | ANTHROPIC_API_KEY (+ OPENAI/GEMINI/...), many *_API_KEY(S) vars | Medium — billing abuse if leaked. | Dedicated Anthropic key with a spend cap, separate from laptop-1's. |
| Chat-channel token | TELEGRAM_BOT_TOKEN / SLACK_BOT_TOKEN / imsg (Apple ID) | Medium — a leaked bot token lets an attacker command the agent. | One channel only; lock to owner's sender ID; rotate on suspicion. |
| OPENCLAW_GATEWAY_TOKEN / password | gateway auth | High if the gateway port is network-exposed. | Auto-generated; bind gateway to loopback / tailnet only — never public (their own docs warn against public exposure). |
| OPENCLAW_AUTH_PROFILE_SECRET_DIR | at-rest encryption key material | Local file theft. | On FileVault volume, outside any mounted/synced dir. |
| 1Password op | 1password skill (optional, requires op) | Catastrophic if prod vault — op can read every product secret. | DO NOT install the 1password skill for the pilot. If ever needed, a read-only service-account token scoped to a single staging vault, never the prod vaults or Employee vault. |
| VPS SSH key / kubeconfig | not required by OpenClaw | — | Never place on this machine. Deploys happen via CI/CD, per standing policy, not from the agent host. |
SECURITY.md (verified, quoted) states plainly:
Implications for us:
developer-portal, GloryLabs marketing site, or infra/docs repos) so the agent never processes special-category data (auditPic photos, claimio claims, identity docs). This keeps the pilot outside Art. 9 / DPIA-triggering territory.docs/logging.md, session-logs skill) on the encrypted volume.GO to pilot under architecture (B) host, not replace, with hard guardrails. NO-GO on: prod 1Password, VPS SSH key, PII repos, auto-merge, public gateway exposure, or replacing the laptop-1 swarm.
github, gh-issues, coding-agent, + Telegram only.developer-portal or the GloryLabs site), contents+issues+PR write, 30-day expiry. No op, no SSH key, no kubeconfig. Dedicated Anthropic key with spend cap.Only after a clean pilot consider: a second non-PII repo, a read-only staging 1Password service-account token (never prod), and folding in the self-hosted CI runner role (separate OS user/token — see §4 cross-ref).
The interactive laptop-1 swarm already covers the core need. OpenClaw's unique adds are (a) phone-chat control of a headless box and (b) a polished GitHub-issue→PR worker loop. If neither is worth the new attack surface and the maintenance of a 6-month-old runtime right now, defer and revisit when a product graduates to needing 24/7 unattended throughput.
gh api repos/openclaw/openclaw → 376,761★ / 78,732 forks / 7,599 open issues / created 2025-11-24 / pushed 2026-06-04 / lang TypeScript / license NOASSERTION.repos/openclaw/openclaw/releases/latest → v2026.6.1 (2026-06-03).LICENSE → MIT text, "OpenClaw Foundation 2026", + THIRD_PARTY_NOTICES.md reference (explains the NOASSERTION badge)..env.example → confirmed cred vars (OPENCLAW_GATEWAY_TOKEN, provider *_API_KEYs, channel bot tokens).SECURITY.md → trust-model quotes in §5.2 (trusted-operator, prompt-injection-out-of-scope, no bounty).skills/ → confirmed github, gh-issues (primaryEnv GH_TOKEN), 1password (requires op), coding-agent, node-connect, chat channels (imsg, slack, discord, voice-call, …).Enderfga/claw-orchestrator (ex-openclaw-claude-code) → 489★ / v4.1.2 (2026-06-03) / MIT / TS.openclaw/acpx → 2,815★ / v0.9.0 (2026-05-22) / MIT / TS (pre-1.0).docs/install + docs/gateway at pilot time).
Reacties