ワンクリックで
openclaw-on-surface
OpenClaw v2026.4.21 setup and management on Surface Pro 3 — gateway, config, channels, and known issues.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
OpenClaw v2026.4.21 setup and management on Surface Pro 3 — gateway, config, channels, and known issues.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Diagnose and fix Hermes messaging gateway connectivity issues (Telegram/Discord down, stale locks, PM2 problems)
Backup Hermes agent to GitHub and restore on a new VPS. Covers what to include/exclude, GitHub token requirements, and restore steps. Includes automated scripts.
GitHub auth setup: HTTPS tokens, SSH keys, gh CLI login.
Clone, create, fork, configure, and manage GitHub repositories. Manage remotes, secrets, releases, and workflows. Works with gh CLI or falls back to git + GitHub REST API via curl.
Fetch YouTube video transcripts and transform them into structured content (chapters, summaries, threads, blog posts). Use when the user shares a YouTube URL or video link, asks to summarize a video, requests a transcript, or wants to extract and reformat content from any YouTube video.
Manage Linear issues, projects, and teams via the GraphQL API. Create, update, search, and organize issues. Uses API key auth (no OAuth needed). All operations via curl — no dependencies.
| name | openclaw-on-surface |
| description | OpenClaw v2026.4.21 setup and management on Surface Pro 3 — gateway, config, channels, and known issues. |
OpenClaw v2026.4.21 is installed on the Surface Pro 3 (this machine) at /home/marco/.openclaw/.
It runs as a systemd user service (openclaw-gateway.service), managed via systemctl --user.
# Check if gateway is running
systemctl --user status openclaw-gateway
# Restart gateway
systemctl --user restart openclaw-gateway
# View recent logs
journalctl --user -u openclaw-gateway -n 20
# Check gateway health (port 18789)
curl http://localhost:18789/health
# View live logs
journalctl --user -u openclaw-gateway -f
The default model is set via agents.defaults.model in ~/.openclaw/openclaw.json, NOT via settings.json.
settings.json is NOT read by the gateway for model defaults — it only works for some agent-level overrides.
Correct ~/.openclaw/openclaw.json:
{
"channels": { ... },
"gateway": { ... },
"agents": {
"defaults": {
"model": "minimax/MiniMax-M2.7-highspeed"
}
}
}
Format must be provider/model (e.g. minimax/MiniMax-M2.7-highspeed). Without the provider prefix, OpenClaw falls back to openai/<model> and logs: Model "X" specified without provider. Falling back to "openai/X".
The gateway log (journalctl --user -u openclaw-gateway) shows agent model: minimax/MiniMax-M2.7-highspeed when correctly configured.
~/.openclaw/openclaw.json ← edit this for model/agent config~/.openclaw/agents/main/agent/auth-profiles.json (API keys for providers)~/.openclaw/agents/main/agent/models.json (available models per provider)~/.openclaw/agents/main/agent/settings.json (NOT read by gateway for defaults)/tmp/openclaw/openclaw-YYYY-MM-DD.log~/.openclaw/credentials/telegram-pairing.json, telegram-allowFrom.jsonThe API key sk-cp-...Sd-Q is stored in ~/.openclaw/agents/main/agent/auth-profiles.json under the minimax:global profile.
Telegram bot token is set via TELEGRAM_BOT_TOKEN env var in the systemd service file.
When a user first messages the bot, OpenClaw checks ~/.openclaw/credentials/telegram-allowFrom.json and telegram-pairing.json.
allowFrom.json → access grantedopenclaw pairing approve telegram <CODE> (CLI times out — edit files directly instead)If CLI times out, edit the credentials files directly:
~/.openclaw/credentials/telegram-allowFrom.json — add user ID to entries array~/.openclaw/credentials/telegram-pairing.json — remove the pending request entry (or leave it — allowFrom is sufficient)User's Telegram ID: 8177017832 (Marco Olivero)
@OpenClaw_LeonSurf_bot (token in service file: TELEGRAM_BOT_TOKEN=***MASKED***)8177017832@Leo (ID 1496854698790228039)DISCORD_BOT_TOKEN env var (see systemd service)DISCORD_BOT_TOKEN env var in systemd service filedmPolicy: "open", allowFrom: ["*"]If the bot shows "Discord Message Content Intent is limited", enable it at: https://discord.com/developers/applications → Bot → Privileged Intents → Message Content Intent ✅
OpenClaw and Hermes are independent programs with separate configurations, bot tokens, and data directories.
| OpenClaw | Hermes | |
|---|---|---|
| Bot | @OpenClaw_LeonSurf_bot | @Hermes_surfer_bot |
| Telegram Token | ***MASKED*** | ***MASKED*** |
| Discord Token | ***MASKED*** (in OpenClaw service) | ***MASKED*** (in Hermes config) |
| Config dir | ~/.openclaw/ | ~/.hermes/ |
| Gateway port | 18789 | separate process |
Never confuse the tokens — All real tokens are stored in /home/Obsidian-Vault/Secure/CREDENTIALS.md
openclaw config set, openclaw pairing approve, etc.) — do NOT use CLI. Edit config files directly.ready (N plugins: acpx, browser, ...) — only then is the gateway fully operational.curl http://localhost:18789/health) may return failure even when the process is running normally, because it doesn't respond until startup is complete. Check journalctl --user -u openclaw-gateway -n 5 instead to see actual startup progress.journalctl --user -u openclaw-gateway for config errors.curl to api.telegram.org works but OpenClaw logs show fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH), the Node.js process has a network issue distinct from system curl. This is a known problem with Node's native HTTP client behind certain proxies/firewalls. The polling will retry automatically. The bot can send outgoing messages but won't receive incoming ones while in this state — a service restart may be needed to recover.token_mismatch ErrorWhen an external client (e.g. AionUI) fails to connect to the gateway with token_mismatch in the logs:
Symptoms:
[ws] closed before connect conn=... reason=connect failed
[gateway] token_mismatch
Root cause: The device token stored in ~/.openclaw/devices/paired.json does not match the gateway auth token in ~/.openclaw/openclaw.json.
Fix — manually sync the tokens:
Get the gateway token:
cat ~/.openclaw/openclaw.json | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['gateway']['auth']['token'])"
Get the device ID and current token:
cat ~/.openclaw/devices/paired.json
# Find the device (e.g. "displayName": "AionUI") and its token under tokens.operator.token
Update the device token to match the gateway token:
python3 -c "
import json
d = json.load(open('/home/marco/.openclaw/devices/paired.json'))
device_id = '<device-id-from-above>'
gw_token = '<token-from-gateway>'
d[device_id]['tokens']['operator']['token'] = gw_token
d[device_id]['tokens']['operator']['scopes'] = ['operator.read', 'operator.admin']
d[device_id]['scopes'] = ['operator.read', 'operator.admin']
d[device_id]['approvedScopes'] = ['operator.read', 'operator.admin']
json.dump(d, open('/home/marco/.openclaw/devices/paired.json', 'w'), indent=2)
print('Done')
"
Restart the gateway:
systemctl --user restart openclaw-gateway
Alternative: If the above doesn't work, try clearing ~/.openclaw/devices/pending.json (set to {}) before restarting, to force a fresh pairing handshake.
When the bot appears offline on Discord despite the gateway being "ready":
journalctl --user -u openclaw-gateway -n 20 | grep -E "ERROR|ready|crash"channels.telegram: invalid config: must NOT have additional properties — this means the Telegram channel config in openclaw.json has keys that aren't allowed. Fix the channels.telegram section to only contain valid keys (enabled, allowFrom).ready (7 plugins: ...discord...) which means Discord plugin is loaded. It may NOT show a new "logged in to discord" message on every restart — absence of an error is a good sign.journalctl --user -u openclaw-gateway | grep -i "discord\|logged" to check Discord connection status across all processes.journalctl --user -u openclaw-gateway | grep -i "error\|fail\|api" for API or model errors.OpenClaw skills installed: ~/.openclaw/skills/