Terminal Helper — a runbook for OpenClaw exec

This skill is not a “generic terminal tips” template. It’s a concrete runbook for how to use OpenClaw’s exec tool effectively in a real workspace (like your /Users/.../clawd workspace), with attention to:

• sandbox vs host execution
• predictable working directories
• long-running processes
• permissions on macOS (Peekaboo, screen recording, UI automation)
• avoiding “accidental shell scripting” disasters

OpenClaw skills are loaded from bundled skills, ~/.openclaw/skills, and <workspace>/skills with workspace taking precedence. :contentReference[oaicite:12]{index=12}

Operating principles (what I will do every time)

1) State the intent + the exact command before running it

Before calling exec, I will say:

• what the command is intended to do
• what directory it will run in
• what files it might read/write
• what output I expect (so we can spot anomalies)

2) Default to read-only exploration

When debugging or orienting:

• pwd, ls -la, git status, rg, cat, head, tail
• only escalate to writes/installs after we know what’s going on

3) Prefer sandboxed execution for untrusted or high-churn work

Use the sandbox for:

• tests, builds, dependency installs
• exploring unknown repos
• running scripts from third-party sources

Important nuance: If a session is sandboxed, the sandbox does not inherit host process.env. Global env and skills.entries.<skill>.env/apiKey apply to host runs only; sandbox env must be set separately. :contentReference[oaicite:13]{index=13}

4) Explicit confirmation for anything risky

I will require the user to confirm before:

• deleting or overwriting files
• installing system-level packages
• touching ~/.ssh, keychains, browser profiles
• changing network/system settings
• running privileged commands (sudo, launchctl changes)

Execution patterns (the “how”)

A) Choose a working directory deliberately

When diagnosing OpenClaw itself, I’ll work inside your workspace (example: /Users/proman/clawd) and be explicit about it.

Typical commands:

• check skills:
  • ls -la ./skills
  • find ./skills -maxdepth 2 -name SKILL.md -print
• check git state:
  • git status (if the workspace is a git repo)
• verify binaries:
  • which peekaboo || echo "peekaboo not on PATH"

B) Keep commands single-purpose

Prefer multiple small commands over one “do everything” pipeline. This makes it easier to review and safer to approve.

C) Long-running commands: background + poll

When supported, run with a short yield and then poll a process session.

Examples you can adapt:

• start a long build:
  • exec: make test (with a short yield)
• poll until completion:
  • process: poll (using the returned session id)

(Exact parameter names depend on your tool surface, but the pattern is: yield → poll.)

Practical playbooks