Description

[Description] After `nemoclaw rebuild --yes`, the CLI reports messaging presets (telegram, slack, discord, jira, outlook) as ○ (not applied) in `policy-list` and `nemoclaw list`. However, the OpenShell gateway still has the old telegram policy rules loaded and actively allows traffic to api.telegram.org. The Telegram bridge successfully polls getUpdates, receives inbound messages, and sends replies — all while the CLI claims the preset is not applied.

This is a policy state inconsistency between the NemoClaw CLI layer and the OpenShell
gateway enforcement layer. It poses both a usability and security concern:

• Users may believe the network is restricted when it is actually open
• Users may attempt to re-apply a preset that is already active, causing unknown side effects
• Security audits based on policy-list output would be inaccurate

[Environment]
Device: Ubuntu (Brev cloud instance, massedcompute A100)
Node.js: v22.22.2
npm: 10.9.7
Docker: Docker version 28.0.4, build b8034c0
OpenShell CLI: 0.0.26
NemoClaw: v0.0.18
OpenClaw: 2026.4.2 (d74a122)

[Steps to Reproduce]

1. nemoclaw onboard — create sandbox "testmessage" with Cloud API + Telegram
2. nemoclaw testmessage policy-add → select telegram → confirm
3. Verify: nemoclaw testmessage policy-list shows ● telegram
4. Verify: Telegram bot responds to messages (inbound works)
5. nemoclaw testmessage rebuild --yes
6. Wait for rebuild to complete successfully
7. nemoclaw testmessage policy-list
8. nemoclaw list
9. Send a message to the Telegram bot

[Expected Result]
Either:
a) policy-list shows ● telegram AND telegram works (consistent — preset restored), OR
b) policy-list shows ○ telegram AND telegram does NOT work (consistent — preset lost)

[Actual Result]
policy-list shows ○ telegram, BUT telegram inbound/outbound BOTH still work:

$ nemoclaw testmessage policy-list
● brave — Brave Search API access
● brew — Homebrew (Linuxbrew) package manager access
○ discord — Discord API, gateway, and CDN access
○ github — GitHub.com and GitHub API access (git, gh)
● huggingface — Hugging Face Hub, LFS, and Inference API access
○ jira — Jira and Atlassian Cloud access
● npm — npm and Yarn registry access
○ outlook — Microsoft Outlook and Graph API access
● pypi — Python Package Index (PyPI) access
○ slack — Slack API, Socket Mode, and webhooks access
○ telegram — Telegram Bot API access

$ nemoclaw list
testmessage
model: nvidia/nemotron-3-super-120b-a12b provider: nvidia-prod
policies: npm, pypi, huggingface, brew, brave
(telegram NOT listed)

Meanwhile, OCSF gateway logs show telegram traffic ALLOWED:
[ocsf] HTTP:POST ALLOWED POST http://api.telegram.org/bot[CREDENTIAL]/sendMessage [policy:telegram]
[ocsf] HTTP:POST ALLOWED POST http://api.telegram.org/bot[CREDENTIAL]/getUpdates [policy:telegram]

And the Telegram bot responds to user messages normally.

[Root Cause Analysis]
The rebuild flow performs: backup → destroy → recreate (onboard) → restore.

During recreate, the onboard step applies the default policy tier (balanced = npm, pypi,
huggingface, brew, brave) and submits a new policy version to the gateway. However, the
OpenShell gateway may be reusing or caching the previous policy version that included
the telegram rules.

The inconsistency arises because:

1. NemoClaw CLI tracks applied presets in its own metadata (registry or onboard-session)
2. The gateway's policy engine tracks loaded policy versions independently
3. After rebuild, the CLI metadata is reset (only default tier presets recorded)
4. But the gateway may still have the old policy loaded or cached from before the destroy

This means policy-list reads from the CLI-side metadata (shows ○ telegram) while the
actual enforcement reads from the gateway-side policy engine (still has telegram rules).

The two sources of truth are out of sync after rebuild.

Suggested fix:

• After rebuild's recreate step, explicitly sync the gateway policy state with the CLI metadata
• Or: after applying the new policy version, verify the gateway has loaded it and the old
  version is fully superseded (not cached)
• At minimum: policy-list should read from the gateway's actual loaded policy, not just
  CLI-side metadata, to always reflect the true enforcement state

Bug Details

[NVB# 6089645]