Common NemoClaw Integration Policy Examples

Use these examples when a sandbox is already installed and an integration needs network access. This page covers only integrations that NemoClaw currently ships as maintained policy preset YAML under nemoclaw-blueprint/policies/presets/. For complete blueprint examples that combine a model, agent harness, OpenShell policy, and integration workflow, refer to Community Solutions. Integration setup usually has two separate parts:

• Configure the integration itself, such as a bot token, OAuth credential, or agent plugin setting.
• Allow the sandbox to reach the integration’s network endpoints through NemoClaw and OpenShell policy.

Use NemoClaw commands for policy changes that should be tracked with the sandbox. Use OpenShell directly when you need to inspect blocked requests or approve a one-off request in the TUI.

Before You Start

Replace my-assistant with your sandbox name in the examples.

Check the current policy state first:

$
nemoclaw my-assistant policy list

For a live view of blocked requests, open the OpenShell TUI in a separate host terminal:

$
openshell term

When the agent reaches an endpoint that is not in the policy, the TUI shows the host, port, requesting binary, method, and path when available. Approve a request only when you understand why the integration needs it. An approval updates the running policy, but it does not create a reviewable NemoClaw preset entry that policy add can replay.

Supported Integration Presets

NemoClaw ships maintained policy presets for common services in nemoclaw-blueprint/policies/presets/. Messaging channel presets are scoped to the sandbox’s active agent; if an agent does not have a matching channel policy, that channel preset is omitted from policy list and policy add <preset> reports it as unknown.

Preview the endpoints before applying:

$
nemoclaw my-assistant policy add outlook --dry-run

NemoClaw generates the preview from the preset policy YAML that policy add would apply. It lists hosts, ports, access, protocol, TLS, and enforcement settings, HTTP methods and paths, and the binary allowlist.

Apply the preset:

$
nemoclaw my-assistant policy add outlook --yes

Remove it later if the sandbox no longer needs that access:

$
nemoclaw my-assistant policy remove outlook --yes

Email and Calendar With Microsoft 365

Use the outlook preset for Microsoft 365 email and calendar workflows that use Microsoft Graph or Outlook endpoints. The preset allows access to graph.microsoft.com, Microsoft login, and Outlook service endpoints.

$
nemoclaw my-assistant policy add outlook --dry-run
$
nemoclaw my-assistant policy add outlook --yes

When the outlook preset is already applied, policy add outlook compares the preset with the live policy. If they match, the command exits zero without changing the live policy. If they differ, the command applies the preset again. This includes changes to the preset file. You do not need to remove the preset before you apply it again. Removing it first temporarily deletes its entries from the live policy.

Then configure the email or calendar tool credentials through the integration you run in the sandbox. Keep OAuth client secrets and refresh tokens out of policy files.

If the tool still fails, run openshell term, trigger the workflow again, and inspect the blocked request. If the blocked endpoint is not covered by the maintained outlook preset, treat it as a separate policy review instead of assuming it is part of the supported preset.

Telegram Bot Messaging

Telegram needs channel configuration and egress policy. If you already enabled Telegram during onboarding but did not include the preset, add it to the running sandbox:

$
nemoclaw my-assistant policy add telegram --yes

To add Telegram after onboarding, set the token on the host, add the channel, rebuild so the image picks up the channel config, and apply the policy preset:

$
export TELEGRAM_BOT_TOKEN=<your-bot-token>
$
NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add telegram
$
nemoclaw my-assistant rebuild
$
nemoclaw my-assistant policy add telegram --yes

If delivery fails, open the TUI and send a test message to the bot:

$
openshell term

The matching preset uses the channel name: telegram, discord, slack, wechat, whatsapp, teams, or googlechat. The googlechat preset resolves to the selected agent’s transport policy. OpenClaw receives the restricted webhook and sends Google Chat REST requests. Hermes pulls and acknowledges Pub/Sub messages over REST and sends Google Chat REST requests.

Slack or Discord Messaging

Slack and Discord also need channel configuration and egress policy. Use the matching policy preset after you configure the channel credentials.

For Slack:

$
export SLACK_BOT_TOKEN=<your-slack-bot-token>
$
export SLACK_APP_TOKEN=<your-slack-app-token>
$
NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add slack
$
nemoclaw my-assistant rebuild
$
nemoclaw my-assistant policy add slack --yes

For Discord:

$
export DISCORD_BOT_TOKEN=<your-discord-bot-token>
$
export DISCORD_SERVER_ID=<your-discord-server-id>
$
NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add discord
$
nemoclaw my-assistant rebuild
$
nemoclaw my-assistant policy add discord --yes

If you enabled Slack or Discord during onboarding, apply only the matching preset:

$
nemoclaw my-assistant policy add slack --yes
$
nemoclaw my-assistant policy add discord --yes

WeChat or WhatsApp Messaging (Experimental)

WeChat and WhatsApp are experimental. Both rely on QR-based pairing flows that are more fragile than token-based bots. The upstream client libraries can change behavior without notice.

WeChat uses Tencent’s iLink Bot API for personal accounts. A host-side QR scan captures the bot token during onboarding rather than requiring you to paste it from a developer portal. Add the channel interactively and apply the preset:

$
nemoclaw my-assistant channels add wechat
$
nemoclaw my-assistant rebuild
$
nemoclaw my-assistant policy add wechat --yes

WhatsApp Web pairs entirely inside the sandbox through QR scan, so channels add does not collect a host-side token. Apply the preset and complete the in-sandbox pairing after the rebuild:

$
NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add whatsapp
$
nemoclaw my-assistant rebuild
$
nemoclaw my-assistant policy add whatsapp --yes

If you enabled WeChat or WhatsApp during onboarding, apply only the matching preset:

$
nemoclaw my-assistant policy add wechat --yes
$
nemoclaw my-assistant policy add whatsapp --yes

GitHub and Jira

Use github when the agent needs GitHub API access or Git access. Use jira when the agent needs Atlassian Jira access.

Preview first:

$
nemoclaw my-assistant policy add github --dry-run
$
nemoclaw my-assistant policy add jira --dry-run

Apply the preset that matches the workflow:

$
nemoclaw my-assistant policy add github --yes
$
nemoclaw my-assistant policy add jira --yes

The jira preset intentionally allows Node.js access to Atlassian Cloud and does not allow curl. When validating it manually, avoid plain curl -s against auth.atlassian.com. Atlassian can return an empty redirect body even when the request succeeds. An empty curl -s output from that endpoint is inconclusive before or after approval. Do not use it as a pass/fail signal. Use a body-visible API probe instead:

$
node -e "require('https').get('https://api.atlassian.com', r => console.log(r.statusCode))"
$
curl -sS --max-time 10 -w '\n%{http_code}\n' https://api.atlassian.com/oauth/token/accessible-resources

Before approval, the curl probe should report 000 or a local policy denial. After explicitly approving curl for api.atlassian.com in OpenShell, it should return Atlassian’s unauthenticated 401 JSON response. The 401 response is the expected success signal for this manual probe. This manual probe proves curl reached Atlassian, but no Jira credentials were supplied.

Remove access when the task is done:

$
nemoclaw my-assistant policy remove github --yes
$
nemoclaw my-assistant policy remove jira --yes

Web Search

Web search requires both the selected provider’s credential and its matching network policy preset. Onboarding suggests brave or tavily only when you selected that provider, including under the Restricted tier. If you unselected or removed the matching preset, preview and add it before using web search.

OpenClaw supports Brave Search and Tavily Search. Apply only the preset that matches the provider you selected during onboarding.

Use these commands for Brave Search.

$
nemoclaw my-assistant policy add brave --dry-run
$
nemoclaw my-assistant policy add brave --yes

Use these commands for Tavily Search.

$
nemoclaw my-assistant policy add tavily --dry-run
$
nemoclaw my-assistant policy add tavily --yes

Rerun onboarding when you change providers because the OpenClaw plugin configuration and OpenShell credential attachment are part of the sandbox image. Configure the matching BRAVE_API_KEY or TAVILY_API_KEY during that onboarding run.

The tavily preset permits only POST /search and POST /extract to api.tavily.com. It enables request-body credential rewriting because Hermes sends its resolver placeholder in the JSON api_key field. OpenShell replaces that placeholder at egress, so the raw key is not written into the sandbox configuration.

Weather and Public Reference Lookups

Use the weather preset when the agent needs read-only weather or geocoding lookups. The Open tier includes it by default. Balanced and Restricted sandboxes require the explicit policy add weather step below. The preset covers read-only public weather and geocoding lookups, including current conditions, forecasts, geocoding, and weather alerts, without enabling messaging or productivity APIs.

$
nemoclaw my-assistant policy add weather --dry-run
$
nemoclaw my-assistant policy add weather --yes

Use the public-reference preset when the agent needs read-only public reference APIs, such as Wikipedia, Wikidata, Wikimedia Commons, Nominatim, or country metadata. The Open tier includes this preset by default.

$
nemoclaw my-assistant policy add public-reference --dry-run
$
nemoclaw my-assistant policy add public-reference --yes

Package and Model Tooling

Use these presets when an agent workflow needs to install packages or download model assets:

Add only the preset required for the task:

$
nemoclaw my-assistant policy add npm --yes
$
nemoclaw my-assistant policy add pypi --yes
$
nemoclaw my-assistant policy add brew --yes
$
nemoclaw my-assistant policy add huggingface --yes

Remove package access after a one-time setup task if the sandbox no longer needs it:

$
nemoclaw my-assistant policy remove npm --yes
$
nemoclaw my-assistant policy remove pypi --yes
$
nemoclaw my-assistant policy remove brew --yes
$
nemoclaw my-assistant policy remove huggingface --yes

The pypi preset allows Python, pip, virtual-environment Python and pip, and /usr/local/bin/uv to reach PyPI endpoints. If uv is installed somewhere else in the sandbox, add a custom preset for that binary path instead of broadening the maintained preset locally.

Homebrew Specifics

The sandbox base image includes Homebrew (Linuxbrew), so apply the brew preset before installing a formula. A /usr/local/bin/brew wrapper puts the entry point on the sandbox PATH while delegating to the Linuxbrew prefix. Installed formula commands are available from the Linuxbrew bin directory in sandbox shell sessions:

$
nemoclaw my-assistant policy add brew --yes
$
nemoclaw my-assistant exec -- brew install <formula>
$
nemoclaw my-assistant exec -- bash -lc '<formula-command>'

You do not need to bootstrap Homebrew, install build dependencies, or source brew shellenv inside the sandbox.

Model Pricing

OpenClaw’s gateway fetches reference pricing from LiteLLM and OpenRouter at startup to populate usage.cost in session JSONL records. The default-strict egress policy denies both hosts. The fetch fails closed, and the gateway logs [gateway/model-pricing] LiteLLM pricing fetch failed: TypeError: fetch failed and the matching OpenRouter line on every startup. Every session record sets usage.cost = 0 even though the input and output token counts populate correctly. Tools that read the session log to display per-turn cost (audit dashboards, compliance review surfaces) cannot distinguish a real free run from this silent failure.

Apply the openclaw-pricing preset to allow both pricing endpoints. The preset pins each host to a single read-only path so it does not widen egress beyond the pricing fetch:

$
nemoclaw my-assistant policy add openclaw-pricing --dry-run
$
nemoclaw my-assistant policy add openclaw-pricing --yes

After the next gateway restart, the WARN entries stop and usage.cost populates from the fetched pricing tables.

Local Inference

Use local-inference when the sandbox needs access to host-side local inference services such as Ollama or vLLM through the OpenShell host gateway. Onboarding auto-suggests this preset when you choose a local provider. If you need to add it after onboarding:

$
nemoclaw my-assistant policy add local-inference --dry-run
$
nemoclaw my-assistant policy add local-inference --yes

Then verify the sandbox status:

$
nemoclaw my-assistant status

Gmail With an App Password

Use the gmail preset for Python IMAP or SMTP workflows that use a dedicated Gmail App Password. Follow Set Up Gmail With an App Password for the security boundary, prerequisites, examples, and cleanup steps.

Inspect or Replace the Live Policy

Use policy list for normal preset state. Follow Replace the Live Network Policy only when you need to export, edit, and replace the complete policy. Use Apply Policy Presets to merge maintained or custom preset entries.

Next Steps

• Approve or Deny Agent Network Requests for the interactive OpenShell TUI flow.
• Customize the Sandbox Network Policy to choose the correct policy workflow.
• Set Up Gmail With an App Password for the full Gmail IMAP and SMTP workflow.
• Choose Messaging Channels for Telegram, Discord, Slack, WeChat, WhatsApp, Microsoft Teams, and Google Chat configuration.
• Commands for the full policy get, policy add, policy list, policy remove, and channels command reference.