Skills on NemoClaw — Install, Write & Configure OpenShell Policy Rules

How Skills Work Inside the Sandbox

When a skill is installed in NemoClaw (inside the OpenShell sandbox), it runs in an isolated execution environment. The sandbox has no outbound network access by default. This is what prevents a compromised skill from exfiltrating data or making unexpected API calls.

The result: skills that make network calls need two things in NemoClaw that they don't need in plain OpenClaw:

1. An OpenShell policy rule allowing the specific domain(s) the skill calls
2. The rule must be on the host (outside the sandbox), not inside it

Skills that only run shell commands or read/write files within the allowed workspace path work without any policy changes — they don't leave the sandbox boundary.

Installing Official Skills

Skill install commands are run inside the sandbox. Connect first:

# Connect to the NemoClaw sandbox
claw connect nemoclaw

# Install a skill (same command as OpenClaw)
openclaw skill install himalaya
openclaw skill verify himalaya   # verify signature

# Install multiple skills at once
openclaw skill install himalaya github weather daily-brief

The skill is now installed inside the sandbox. If it needs network access, continue to the next section to add the policy rule. If you skip this, the skill will appear to work but any network call it makes will fail with a cryptic connection error.

Skills That Don't Need Policy Changes

These official skills work immediately after install with no OpenShell changes required (they operate only within the sandbox filesystem or run shell commands):

• notes — reads and writes files in the workspace
• daily-brief — assembles a brief from local data (no external calls)
• memory-manager — manages MEMORY.md files
• skill-creator — writes new skill files using the LLM (no network calls from the skill itself)
• system-info — reads local system stats (CPU, disk, RAM)
• file-manager — file read/write/search within the allowed workspace path

Adding Policy Rules for Skills

For each skill that makes network requests, you need to add its domains to the OpenShell policy on the host. Exit the sandbox first:

# Exit the sandbox
exit   # or Ctrl+D

# You are now on the host — add policy rules here

GitHub Skill

cat >> ~/.openShell/policies/includes/github.yaml << 'EOF'
allow:
  - host: "api.github.com"
    ports: [443]
    comment: "GitHub REST API — github skill"
  - host: "github.com"
    ports: [443]
    comment: "GitHub main — git operations"
  - host: "raw.githubusercontent.com"
    ports: [443]
    comment: "GitHub raw file access"
EOF
openShell policy reload

Himalaya Email Skill

cat >> ~/.openShell/policies/includes/email.yaml << 'EOF'
allow:
  # Gmail
  - host: "imap.gmail.com"
    ports: [993]
  - host: "smtp.gmail.com"
    ports: [587]
  - host: "oauth2.googleapis.com"
    ports: [443]
  # Fastmail
  - host: "imap.fastmail.com"
    ports: [993]
  - host: "smtp.fastmail.com"
    ports: [587]
  # Add your provider's IMAP/SMTP hosts if different
EOF
openShell policy reload

Weather Skill

cat >> ~/.openShell/policies/includes/weather.yaml << 'EOF'
allow:
  - host: "api.open-meteo.com"
    ports: [443]
    comment: "Open-Meteo free weather API"
  - host: "geocoding-api.open-meteo.com"
    ports: [443]
    comment: "Open-Meteo geocoding"
EOF
openShell policy reload

Telegram Skill (for sending messages)

cat >> ~/.openShell/policies/includes/telegram.yaml << 'EOF'
allow:
  - host: "api.telegram.org"
    ports: [443]
    comment: "Telegram Bot API"
EOF
openShell policy reload

Web Search Skill

cat >> ~/.openShell/policies/includes/search.yaml << 'EOF'
allow:
  - host: "api.perplexity.ai"
    ports: [443]
    comment: "Perplexity Search API"
  # Or Brave Search:
  # - host: "api.search.brave.com"
  #   ports: [443]
EOF
openShell policy reload

After each reload, reconnect to the sandbox and test the skill:

claw connect nemoclaw
openclaw run "Check my GitHub notifications"

Writing Custom Skills in NemoClaw

Writing custom skills is identical to OpenClaw. Have your agent write the skill:

"Write me a skill that checks our server status page at status.example.com/api/v1/status and returns a one-line summary. Make it OpenClaw skill format."

The agent generates a SKILL.md file inside the sandbox. Install it:

# Inside the sandbox
openclaw skill install ./my-custom-skill/

# Verify it loaded
openclaw skill list | grep my-custom-skill

Then add its network domains to the policy on the host:

exit   # leave sandbox
cat >> ~/.openShell/policies/includes/custom.yaml << 'EOF'
allow:
  - host: "status.example.com"
    ports: [443]
    comment: "Custom status check skill"
EOF
openShell policy reload
claw connect nemoclaw

Full guide on writing skills from scratch: OpenClaw Skills Guide: Write Your Own — all steps are identical inside the NemoClaw sandbox.

Sandbox Scope — Skill Isolation

OpenShell's sandbox scope setting controls how much isolation skills get when they run. This is set in your OpenClaw config inside the sandbox:

# Inside the sandbox (claw connect nemoclaw)
# View current sandbox settings
openclaw config get agents.defaults.sandbox

# Example output:
# { "mode": "non-main", "scope": "agent" }

Keep the default agent scope for most setups. Switch to session if you're experimenting with unverified community skills.

Troubleshooting Skill Failures

In NemoClaw, most unexpected skill failures are policy denials. The error from inside the sandbox looks like a network timeout or "connection refused" — not a permission error. Don't spend time debugging the skill code until you've checked the policy log.

# On host — check what was blocked
openShell logs policy --denied --last 20

# Example useful output:
# [DENY] api.github.com:443 — sandbox: nemoclaw — trigger: github-skill — rule: network.default=deny

# Add the missing rule to your policy includes, then reload
openShell policy reload

# Back in the sandbox — retry
claw connect nemoclaw
openclaw run "Check my GitHub notifications"

Community Skills — Extra Caution in NemoClaw

The OpenShell policy sandbox provides a strong safety net, but it's not a reason to install community skills carelessly. A malicious skill could:

• Exfiltrate data to any domain you've allowed in your policy (e.g., the GitHub API endpoint could be used to send data, not just receive it)
• Persist code in the workspace directory (which is readable and writable by the sandbox)
• Abuse allowed shell commands to create backdoors in the workspace

The policy sandbox prevents these from reaching external destinations that aren't in your allow list. But it doesn't prevent abuse of domains that are allowed. Our recommendation for NemoClaw is the same as for OpenClaw: have your agent write skills from scratch rather than installing from the community registry.

If you must install a community skill, use scope: session in your sandbox config while testing, and audit the SKILL.md file before installing. See the 53 Official Skills Database for the only skills we endorse.