Agent Trainer Checklist: 3 Things to Keep Clawdbot Running Stable (Device, Remote, Permissions)

Target Audience

You’ve managed to install Clawdbot, but you’re facing these real-world problems:

• Gateway crashes after a few days (or logs are hard to diagnose)
• Want external access but worry about exposing ports
• “Too many permissions” feels unsafe, want to self-check and tighten

This article compresses the key points into three tasks following a “trainer mindset”: device selection, remote access, permission self-check.

1) Device Selection: Prioritize Stability, Don’t Chase “Full Features” Initially

Treat the gateway as a long-running online service. Selection criteria should be prioritized:

1. Stable online presence (network and power)
2. You can maintain it anytime (SSH/remote desktop/logs)
3. Acceptable cost (don’t transfer complexity to yourself to save effort)

Common choices:

• A home always-on machine (e.g., macOS/Linux host): good maintenance experience, suitable for “personal primary gateway”
• Low-spec VPS: good for testing, but pay more attention to remote access and permission tightening
• Raspberry Pi: suitable as “low-power gateway,” but don’t expect it to run local LLMs (better for API models)

Related platform entries (mixed Chinese/English):

• Platform overview (Chinese): /en/docs/platforms/
• Raspberry Pi (Chinese): /en/docs/platforms/raspberry-pi/

2) Remote Access: Prioritize “Networking/Tunnels,” Don’t Expose Ports Directly

Recommended Option A: SSH Tunnel (Simplest)

Keep the gateway loopback-only, then tunnel from your computer:

ssh -N -L 18789:127.0.0.1:18789 user@host

Open http://127.0.0.1:18789/ in your browser.

Recommended Option B: Tailscale (Better Long-term Experience)

If you want “like LAN” communication between multiple devices, Tailscale usually provides a smoother experience (and reduces many “port/firewall” issues).

Tailscale: /en/docs/gateway/tailscale/

3) Permission Self-Check: Turn “Can Do” into “Controlled Can Do”

From a security perspective, the trainer’s job is to “draw clear boundaries”:

First Tighten Entry Points

• Start with just one channel (Telegram/WhatsApp choose one)
• DM defaults to pairing or allowlist (don’t start open)

Then Tighten Execution Surface

For high-risk tools like exec, prioritize:

• allowlist (only allow a small set of commands)
• ask (popup confirmation each time)

Related links:

• Exec approvals: /en/docs/tools/exec-approvals/
• Gateway security: /en/docs/gateway/security/

Finally Treat “Soul Files” as Configuration Management

Much of Clawdbot’s long-term experience depends on what “persistent constraints/habits” you’ve placed in your workspace.

In common personal assistant workflows, you’ll see similar guidance files (names may vary by configuration):

• Identity and style: IDENTITY.md / SOUL.md
• User preferences: USER.md
• Long-term memory: MEMORY.md + memory/
• Active checks (heartbeat): HEARTBEAT.md
• Tool usage constraints: TOOLS.md

The point isn’t “file names” but “you’ve written down the rules” and made them repeatedly executable and reviewable.

Minimal Acceptance (Recommended After Each Configuration Change)

clawdbot status
clawdbot health

If you’re deployed remotely, add: clawdbot logs --follow and watch for a while to confirm no repeated reconnections/authentication failures.

References and Extensions

• Platform selection (Chinese): /en/docs/platforms/
• Gateway overview (Chinese): /en/docs/gateway/

Source material: docs_doc/_docs/docs/clawdbot/2015330732756042216.md