> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/nemoclaw/llms.txt. > For full documentation content, see https://docs.nvidia.com/nemoclaw/llms-full.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemoclaw/_mcp/server. # Common NemoClaw Integration Policy Examples > Guided examples for adding post-install integration policy access to a NemoClaw sandbox. # 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/`. 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. Prefer 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: ```bash nemoclaw my-assistant policy-list ``` ```bash nemohermes my-assistant policy-list ``` For a live view of blocked requests, open the OpenShell TUI in a separate host terminal: ```bash openshell term ``` When the agent reaches an endpoint that is not in 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 NemoClaw preset entry that can be reviewed and replayed like `policy-add`. ## Supported Integration Presets NemoClaw ships maintained policy presets for common services in `nemoclaw-blueprint/policies/presets/`. | Workflow | Preset | | ---------------------------------------------- | ------------------ | | Brave Search | `brave` | | Homebrew packages | `brew` | | Discord messaging | `discord` | | GitHub and GitHub API | `github` | | Hugging Face Hub and Inference API | `huggingface` | | Jira and Atlassian Cloud | `jira` | | Local Ollama or vLLM through the host gateway | `local-inference` | | OpenClaw model-pricing reference fetch | `openclaw-pricing` | | npm and Yarn packages | `npm` | | Microsoft 365, Outlook, and Graph API | `outlook` | | Python Package Index | `pypi` | | Slack messaging | `slack` | | Telegram Bot API | `telegram` | | WeChat (personal) iLink Bot API (experimental) | `wechat` | | WhatsApp Web messaging (experimental) | `whatsapp` | Preview the endpoints before applying: ```bash nemoclaw my-assistant policy-add outlook --dry-run ``` ```bash nemohermes my-assistant policy-add outlook --dry-run ``` Apply the preset: ```bash nemoclaw my-assistant policy-add outlook --yes ``` ```bash nemohermes my-assistant policy-add outlook --yes ``` Remove it later if the sandbox no longer needs that access: ```bash nemoclaw my-assistant policy-remove outlook --yes ``` ```bash nemohermes 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 `graph.microsoft.com`, Microsoft login, and Outlook service endpoints. ```bash nemoclaw my-assistant policy-add outlook --dry-run nemoclaw my-assistant policy-add outlook --yes ``` ```bash nemohermes my-assistant policy-add outlook --dry-run nemohermes my-assistant policy-add outlook --yes ``` Then configure the email or calendar tool credentials through the integration you are running 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 both channel configuration and egress policy. If you already enabled Telegram during onboarding but did not include the preset, add it to the running sandbox: ```bash nemoclaw my-assistant policy-add telegram --yes ``` ```bash nemohermes 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 make sure the policy preset is applied: ```bash export TELEGRAM_BOT_TOKEN= NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add telegram nemoclaw my-assistant rebuild nemoclaw my-assistant policy-add telegram --yes ``` ```bash export TELEGRAM_BOT_TOKEN= NEMOCLAW_NON_INTERACTIVE=1 nemohermes my-assistant channels add telegram nemohermes my-assistant rebuild nemohermes my-assistant policy-add telegram --yes ``` If delivery fails, open the TUI and send a test message to the bot: ```bash openshell term ``` The matching preset for each supported messaging channel is the channel name (`telegram`, `discord`, `slack`, `wechat`, or `whatsapp`). ## Slack or Discord Messaging Slack and Discord also need both channel configuration and egress policy. Use the matching policy preset after you configure the channel credentials. For Slack: ```bash export SLACK_BOT_TOKEN= export SLACK_APP_TOKEN= NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add slack nemoclaw my-assistant rebuild nemoclaw my-assistant policy-add slack --yes ``` ```bash export SLACK_BOT_TOKEN= export SLACK_APP_TOKEN= NEMOCLAW_NON_INTERACTIVE=1 nemohermes my-assistant channels add slack nemohermes my-assistant rebuild nemohermes my-assistant policy-add slack --yes ``` For Discord: ```bash export DISCORD_BOT_TOKEN= export DISCORD_SERVER_ID= NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add discord nemoclaw my-assistant rebuild nemoclaw my-assistant policy-add discord --yes ``` ```bash export DISCORD_BOT_TOKEN= export DISCORD_SERVER_ID= NEMOCLAW_NON_INTERACTIVE=1 nemohermes my-assistant channels add discord nemohermes my-assistant rebuild nemohermes my-assistant policy-add discord --yes ``` If you enabled Slack or Discord during onboarding, apply only the matching preset: ```bash nemoclaw my-assistant policy-add slack --yes nemoclaw my-assistant policy-add discord --yes ``` ```bash nemohermes my-assistant policy-add slack --yes nemohermes 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, and the upstream client libraries can change behavior without notice. WeChat uses Tencent's iLink Bot API for personal accounts. The bot token is captured by a host-side QR scan during onboarding rather than pasted from a developer portal. Add the channel interactively and apply the preset: ```bash nemoclaw my-assistant channels add wechat nemoclaw my-assistant rebuild nemoclaw my-assistant policy-add wechat --yes ``` ```bash nemohermes my-assistant channels add wechat nemohermes my-assistant rebuild nemohermes my-assistant policy-add wechat --yes ``` WhatsApp Web pairs entirely inside the sandbox via QR scan, so `channels add` does not collect a host-side token. Apply the preset and complete the in-sandbox pairing after the rebuild: ```bash NEMOCLAW_NON_INTERACTIVE=1 nemoclaw my-assistant channels add whatsapp nemoclaw my-assistant rebuild nemoclaw my-assistant policy-add whatsapp --yes ``` ```bash NEMOCLAW_NON_INTERACTIVE=1 nemohermes my-assistant channels add whatsapp nemohermes my-assistant rebuild nemohermes my-assistant policy-add whatsapp --yes ``` If you enabled WeChat or WhatsApp during onboarding, apply only the matching preset: ```bash nemoclaw my-assistant policy-add wechat --yes nemoclaw my-assistant policy-add whatsapp --yes ``` ```bash nemohermes my-assistant policy-add wechat --yes nemohermes my-assistant policy-add whatsapp --yes ``` ## GitHub and Jira Use `github` when the agent needs GitHub API or Git access. Use `jira` when the agent needs Atlassian Jira access. Preview first: ```bash nemoclaw my-assistant policy-add github --dry-run nemoclaw my-assistant policy-add jira --dry-run ``` ```bash nemohermes my-assistant policy-add github --dry-run nemohermes my-assistant policy-add jira --dry-run ``` Apply the preset that matches the workflow: ```bash nemoclaw my-assistant policy-add github --yes nemoclaw my-assistant policy-add jira --yes ``` ```bash nemohermes my-assistant policy-add github --yes nemohermes 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. Use a body-visible API probe instead: ```bash 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. That `401` 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: ```bash nemoclaw my-assistant policy-remove github --yes nemoclaw my-assistant policy-remove jira --yes ``` ```bash nemohermes my-assistant policy-remove github --yes nemohermes my-assistant policy-remove jira --yes ``` ## Brave Search The default Balanced policy tier includes `brave`. If you chose Restricted during onboarding or removed the preset later, add it before enabling Brave Search workflows: ```bash nemoclaw my-assistant policy-add brave --dry-run nemoclaw my-assistant policy-add brave --yes ``` ```bash nemohermes my-assistant policy-add brave --dry-run nemohermes my-assistant policy-add brave --yes ``` The Brave Search API key is still configured separately during onboarding or through the web search setup flow. ## Package and Model Tooling Use these presets when an agent workflow installs packages or downloads model assets: | Workflow | Preset | | ----------------------------------------------------- | ------------- | | npm or Yarn packages | `npm` | | Python packages from PyPI with `pip`, Python, or `uv` | `pypi` | | Homebrew packages | `brew` | | Hugging Face model or dataset access | `huggingface` | Add only the preset required for the task: ```bash 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 ``` ```bash nemohermes my-assistant policy-add npm --yes nemohermes my-assistant policy-add pypi --yes nemohermes my-assistant policy-add brew --yes nemohermes my-assistant policy-add huggingface --yes ``` Remove package access after a one-time setup task if the sandbox no longer needs it: ```bash 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 ``` ```bash nemohermes my-assistant policy-remove npm --yes nemohermes my-assistant policy-remove pypi --yes nemohermes my-assistant policy-remove brew --yes nemohermes 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 applying the `brew` preset is the only step needed 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: ```bash nemoclaw my-assistant policy-add brew --yes nemoclaw my-assistant exec -- brew install nemoclaw my-assistant exec -- bash -lc '' ``` ```bash nemohermes my-assistant policy-add brew --yes nemohermes my-assistant exec -- brew install nemohermes my-assistant exec -- bash -lc '' ``` 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 on every start so it can populate `usage.cost` in session JSONL records. The default-strict egress policy denies both hosts. The fetch fails closed, the gateway logs `[gateway/model-pricing] LiteLLM pricing fetch failed: TypeError: fetch failed` (and the matching OpenRouter line) on every startup, and every session record records `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: ```bash 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. Hermes does not use OpenClaw's model-pricing reference fetch. ## 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: ```bash nemoclaw my-assistant policy-add local-inference --dry-run nemoclaw my-assistant policy-add local-inference --yes ``` ```bash nemohermes my-assistant policy-add local-inference --dry-run nemohermes my-assistant policy-add local-inference --yes ``` Then verify the sandbox status: ```bash nemoclaw my-assistant status ``` ```bash nemohermes my-assistant status ``` ## Inspect or Replace the Live Policy Use `policy-list` for normal preset state: ```bash nemoclaw my-assistant policy-list ``` ```bash nemohermes my-assistant policy-list ``` Use OpenShell when you need the full enforced YAML: ```bash openshell policy get --full my-assistant > live-policy.yaml ``` If you must replace the live policy, edit the full policy file and set it back: ```bash openshell policy set --policy live-policy.yaml my-assistant --wait ``` `openshell policy set` replaces the live policy with the file you provide. It does not accept a preset file that starts with a `preset:` block, and it does not merge a single endpoint into the existing policy. Use `nemoclaw my-assistant policy-add` for maintained NemoClaw presets. Use `nemohermes my-assistant policy-add` for maintained NemoClaw presets. ## Next Steps * [Approve or Deny Agent Network Requests](approve-network-requests) for the interactive OpenShell TUI flow. * [Customize the Sandbox Network Policy](customize-network-policy) for static policy edits and raw OpenShell policy files. * [Messaging Channels](../manage-sandboxes/messaging-channels) for Telegram, Discord, Slack, WeChat, and WhatsApp channel configuration. * [Commands](../reference/commands) for the full `policy-add`, `policy-list`, `policy-remove`, and `channels` command reference.