Cloud-Local Bridge

实现云端 OpenClaw 与本地 OpenClaw 之间的双向通信桥接。支持自然语言配对、命令执行、文件同步。

Security Scan

功能与描述大体一致, 但代码 exposes powerful capabilities (remote shell execution, arbitrary file read/write, and outbound callbacks) and includes pairing flows that can leak tokens — these require explicit trust and careful deployment.

Purpose & Capability

The name/description (bridge between cloud and local, pairing, command exec, file sync) matches the included code: server, client, pairing, sync and installer. Asking the user to run a local server with a token is coherent. However some implemented behaviors (automatic sharing of server+token during pairing, ability to read arbitrary local paths, and sending results to arbitrary callback URLs) are more powerful than the simple 'pairing' UX implies and should be considered high-risk by users.

Instruction Scope

SKILL.md instructs running the local server and examples show cloud-side scripts calling /execute and /file. The runtime code allows arbitrary shell commands (subprocess.run with shell=True), arbitrary file reads/writes/uploads/downloads, and will POST callbacks to attacker-controlled URLs (reply_to). The pairing handlers also automatically include the local server URL and token in pairing messages/state, which can leak credentials out-of-band. The instructions do not sufficiently warn about these powerful actions.

Install Mechanism

There is no registry install spec, but an included installer script will pip-install 'requests' and 'psutil' (typical PyPI packages). Using pip in the installer is expected for a Python skill, but installing packages without cryptographic verification is moderate risk. The installer also auto-generates tokens and writes config files in the user home. No remote binary downloads or obscure URLs were found.

Credentials

The skill requests no external environment variables or cloud credentials in metadata, which is proportionate. However the code creates and stores tokens/configs in ~/.openclaw and the pairing flow can expose those tokens to other parties (the QQ/qq_handler and pairing_core propagate server/token into pairing state and messages). The skill itself does not ask for unrelated credentials, but it does enable automatic disclosure of the local token to peers if pairing is completed carelessly.

Persistence & Privilege

always is false and the skill does not request system-wide privileges. It writes config and state into ~/.openclaw (persistent presence). Combined with autonomous invocation (platform default), the skill could be invoked to execute remote commands and access files; while this aligns with its purpose, it increases blast radius and requires the user to limit where the service runs and who receives pairing codes/tokens.

What to consider before installing

This skill does what it says (bridge that lets cloud instruct a local OpenClaw), but it grants very powerful local rights: remote execution (subprocess.run with shell=True), arbitrary file read/write, and the ability to send execution results to arbitrary URLs (reply_to). Before installing/run: - Only run this on machines you fully control and are willing to expose to a trusted cloud peer. Do NOT run on servers with sensitive data or elevated permissions. - Treat the generated token as highly sensitive. Do not share pairing codes/tokens over untrusted channels. Inspect pairing messages to ensure the token is not being leaked to third parties. - Restrict network access (bind to localhost or firewall to only allow specific IPs); prefer running behind VPN or SSH tunnel and use HTTPS where possible. - Consider running the bridge inside a sandbox/container or a dedicated low-privilege user account to limit damage from malicious commands. - Review the code yourself (or have a trusted party do so): look for any unwanted callbacks, unexpected endpoints, or additional behavior in truncated files. - If you need more constrained behavior, modify the server to whitelist allowed commands and restrict file path access, or remove the 'reply_to' callback feature. Given these findings, treat the skill as high-risk: usable for intended scenarios but only with strong operational controls and mutual trust between paired parties.

让云端和本地 OpenClaw 实例无缝协同，支持自然语言配对、文件互通、命令远程执行。

核心特性

✅ 自然语言配对 - 不用记指令，像聊天一样说"我想连接云端" ✅ 跨通道配对 - QQ/微信/Telegram/邮件都能完成配对 ✅ 2步完成 - 像添加微信好友一样简单

⚡ 自然语言配对

直接发送自然语言

你发送	机器人回应
配对	收到配对码
我想连接云端	收到配对码
添加设备	收到配对码
配对 847291	配对成功
查看配对	显示已连接设备
帮助配对	显示帮助

支持的自然语言

发起配对：

• 配对、我要配对、想配对
• 连接、连接云端、连接本地
• 添加设备、添加云端、添加好友
• 关联设备、互相关联
• pair、connect

确认配对：

• 配对 123456

查看状态：

• 查看配对、配对状态
• 我的设备、设备列表

取消：

• 取消配对、删除设备

📱 配对流程

用户 A（本地）                    用户 B（云端）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 发送「我想连接云端」          (等待)
   ↓
2. 收到配对码: 847291
   ↓
3. 发送配给 B                  (接收配对码)
   ↓                          4. B 发送「配对 847291」
                                   ↓
5. ✅ 配对成功!                ✅ 配对成功!

🚀 快速启动

cd /root/.openclaw/workspace/skills/cloud-local-bridge/scripts

# 启动 Bridge 服务
python3 bridge_server.py --port 8080 --token "xxx"

🔧 组件说明

文件	说明
qq_handler.py	自然语言配对处理器
bridge_server.py	Bridge 服务端
bridge_client.py	Bridge 客户端
sync_files.py	文件同步

💡 使用场景

场景1：QQ 配对

你：我想连接云端
机器人：📱 发起配对成功！配对码：847291

（你把配对码发给云端用户）

云端用户：配对 847291
机器人：🎉 配对成功！已连接本地电脑

场景2：跨平台配对

本地（QQ）：配对 → 收到 582391 → 通过 QQ 发送给云端
云端（Telegram）：发送配对请求到 API → 配对成功

📁 文件结构

cloud-local-bridge/
├── SKILL.md
├── scripts/
│   ├── qq_handler.py        # 🆕 自然语言处理器
│   ├── bridge_server.py     # 服务端
│   ├── bridge_client.py    # 客户端
│   └── sync_files.py       # 文件同步
└── references/
    └── EXAMPLES.md

⚠️ 注意事项

• 配对码 10 分钟后过期
• 配对状态保存在 ~/.openclaw/bridge_pairing_state.json
• 确保网络互通