协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
zopenclaw【开发与工程】Install and run OpenClaw on Zo Computer with Tailscale private networking, browser Control UI, and Zo MCP tools via mcporter. Use this skill whenever the user wants to set up OpenClaw on their Zo, install OpenClaw, run OpenClaw, host OpenClaw, or asks about getting OpenClaw running on Zo. Also use when the user mentions "openclaw", "open claw", "pers…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Install OpenClaw on Zo Computer with Tailscale private networking.
register_user_service patterntools.profile reverting, port conflicts, reprovision issues, or workspace size limitsThere are six steps. Steps 1 and 3 require user action. Steps 2, 4, 5, and 6 are automated by Zo.
TAILSCALE_AUTHKEY, value = the key (starts with tskey-auth-)bash /home/workspace/Skills/zopenclaw/scripts/install.sh
This script:
TAILSCALE_AUTHKEY exists in environment/usr/local/bin/start-tailscale.sh)~/.zo_secretsAfter the script completes, Zo registers Tailscale as a Zo User Service:
register_user_service(
label="tailscale",
protocol="tcp",
local_port=41641,
entrypoint="/usr/local/bin/start-tailscale.sh",
workdir="/root"
)
Wait for Tailscale to connect (~10 seconds), then verify:
tailscale status
Important: Enable Tailscale Serve (user action). Serve must be enabled for this node before the Control UI will work over HTTPS. Get the node ID and give the user the enablement link:
tailscale status --json | jq -r '.Self.ID'
Tell the user to open:
https://login.tailscale.com/f/serve?node=<node-id>
If Serve is not enabled, the Control UI will fail with "requires device identity" because only insecure origins will reach the gateway. Do not proceed to Step 3 until the user confirms Serve is enabled.
The user opens Zo's terminal panel and runs:
openclaw onboard
This is interactive -- the user picks their LLM provider, model, and messaging channel. Do NOT try to automate this. Do NOT use --install-daemon (we use register_user_service instead).
Wait for the user to confirm onboarding is complete before proceeding.
bash /home/workspace/Skills/zopenclaw/scripts/bootstrap.sh
This script:
tools.profile to fullgateway.bind, gateway.tailscale.mode, gateway.auth.mode, gateway.controlUi.enabled) and removes deprecated keys (host, tailscaleServe, tokenAuth, enableControlUI)gateway.auth.allowTailscale = true (allows Tailscale-authenticated browser access)gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback = true (fixes "requires device identity" error through Tailscale Serve)gateway.tailscale.resetOnExit = false (prevents Serve reset when gateway stops, since we manage Serve separately)trustedProxies (needed for two-phase bootstrap)~/.zo_secretsAfter the script completes, Zo performs the bootstrap sequence:
Phase 1 -- Start gateway WITHOUT trustedProxies:
register_user_service(
label="openclaw-gateway",
protocol="tcp",
local_port=18789,
entrypoint="bash -c 'cd /root/.openclaw && exec openclaw gateway run'",
workdir="/root/.openclaw"
)
Wait for readiness (poll instead of fixed sleep), then pair the local device:
for i in $(seq 1 20); do
if openclaw gateway status 2>&1 | grep -qE 'RPC probe: ok|Listening:'; then
break
fi
sleep 1
done
openclaw devices list
If there is a pending request, approve it:
/home/workspace/Skills/zopenclaw/scripts/pairing-helper.sh device <request-id>
Phase 2 -- Add trustedProxies and restart:
jq '.gateway.trustedProxies = ["127.0.0.1/32"]' ~/.openclaw/openclaw.json > /tmp/oc.json && mv /tmp/oc.json ~/.openclaw/openclaw.json
supervisorctl -s http://127.0.0.1:29011 restart openclaw-gateway
Phase 3 -- Verify Tailscale Serve HTTPS (bootstrap.sh already attempts this, but verify/fix here):
tailscale serve status --json | jq .
If the serve mapping is missing or wrong, reset and re-publish:
tailscale serve reset
tailscale serve --bg --yes 18789
tailscale serve status --json | jq .
Expected proxy target:
https://<tailscale-hostname>/ -> http://127.0.0.1:18789
If you see 127.0.0.1:3000 (or any other port), reset and re-run the commands above.
Phase 4 -- Provision HTTPS certificate:
TS_HOST=$(tailscale status --json | jq -r '.Self.DNSName' | sed 's/\.$//')
tailscale cert "$TS_HOST"
bash /home/workspace/Skills/zopenclaw/scripts/verify.sh
On success:
https://<tailscale-hostname>http://<tailscale-ip>:18789 or any non-HTTPS proxy URLIf the UI says "pairing required", approve pending requests:
openclaw devices list
openclaw devices approve <request-id>
If Telegram asks for pairing code:
/home/workspace/Skills/zopenclaw/scripts/pairing-helper.sh telegram <PAIRING_CODE>
OpenClaw does not have native MCP client support (it's an open feature request). mcporter bridges MCP servers into OpenClaw's tool system, giving your agent access to Zo's 50+ tools (web search, Gmail, Calendar, Drive, media generation, etc.).
Prerequisites: The user needs a Zo access token.
ZO_ACCESS_TOKEN in the Secrets area on the same pageConfigure mcporter (Zo runs):
mcporter was installed by the install script in Step 2. Add Zo's MCP server:
source /root/.zo_secrets
mcporter config add zo https://api.zo.computer/mcp \
--header "Authorization: Bearer $ZO_ACCESS_TOKEN" \
--scope home
Verify the connection:
mcporter list
mcporter call zo.web_search --args '{"query": "test", "time_range": "day"}'
If mcporter list shows the zo server and the test call returns results, the bridge is working.
Restart the gateway so OpenClaw picks up the new tools:
supervisorctl -s http://127.0.0.1:29011 restart openclaw-gateway
The user can now ask their OpenClaw agent to use Zo tools (search the web, check email, manage calendar, generate images, etc.) via the mcporter bridge.
If OpenClaw warns:
channels.telegram.groupPolicy is "allowlist" but groupAllowFrom is empty
then group chats will be silently dropped. Fix one of these:
channels.telegram.groupAllowFrom (or channels.telegram.allowFrom)channels.telegram.groupPolicy to openIf any checks fail, read references/troubleshooting.md for diagnosis and fixes.