NVIDIA
diff --git a/‎.agents/skills/nemoclaw-user-configure-inference/SKILL.md‎
Lines changed: 1 addition & 0 deletions b/‎.agents/skills/nemoclaw-user-configure-inference/SKILL.md‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎.agents/skills/nemoclaw-user-get-started/SKILL.md‎
Lines changed: 2 additions & 1 deletion b/‎.agents/skills/nemoclaw-user-get-started/SKILL.md‎
Lines changed: 2 additions & 1 deletion
diff --git a/‎.agents/skills/nemoclaw-user-get-started/references/windows-preparation.md‎
Lines changed: 3 additions & 0 deletions b/‎.agents/skills/nemoclaw-user-get-started/references/windows-preparation.md‎
Lines changed: 3 additions & 0 deletions
diff --git a/‎.agents/skills/nemoclaw-user-overview/references/release-notes.md‎
Lines changed: 28 additions & 0 deletions b/‎.agents/skills/nemoclaw-user-overview/references/release-notes.md‎
Lines changed: 28 additions & 0 deletions
diff --git a/‎.agents/skills/nemoclaw-user-reference/references/architecture.md‎
Lines changed: 2 additions & 0 deletions b/‎.agents/skills/nemoclaw-user-reference/references/architecture.md‎
Lines changed: 2 additions & 0 deletions
diff --git a/‎.agents/skills/nemoclaw-user-reference/references/commands.md‎
Lines changed: 1 addition & 1 deletion b/‎.agents/skills/nemoclaw-user-reference/references/commands.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎.agents/skills/nemoclaw-user-reference/references/troubleshooting.md‎
Lines changed: 62 additions & 0 deletions b/‎.agents/skills/nemoclaw-user-reference/references/troubleshooting.md‎
Lines changed: 62 additions & 0 deletions
diff --git a/‎.github/workflows/docs-preview-pr.yaml‎
Lines changed: 5 additions & 2 deletions b/‎.github/workflows/docs-preview-pr.yaml‎
Lines changed: 5 additions & 2 deletions
diff --git a/‎docs/about/release-notes.mdx‎
Lines changed: 28 additions & 0 deletions b/‎docs/about/release-notes.mdx‎
Lines changed: 28 additions & 0 deletions
diff --git a/‎docs/inference/use-local-inference.mdx‎
Lines changed: 7 additions & 6 deletions b/‎docs/inference/use-local-inference.mdx‎
Lines changed: 7 additions & 6 deletions
@@ -62,6 +62,7 @@ When NemoClaw runs inside WSL, the provider menu can include Windows-host Ollama
 
 The install and restart paths set `OLLAMA_HOST=0.0.0.0:11434` on the Windows side so Docker and WSL can reach the daemon through `host.docker.internal`.
 After an install or restart action, NemoClaw relaunches Ollama from the detected Windows tray app or verified `ollama.exe` path and waits until `host.docker.internal:11434` responds.
+If the HTTP endpoint is not reachable yet, NemoClaw also checks for the Windows `ollama.exe` process through PowerShell interop so it can offer a start or restart action instead of hiding the Windows-host path.
 If the daemon does not become reachable, onboarding prints PowerShell commands you can run to inspect the Windows-side process and port state.
 Use one Ollama instance on port `11434` at a time.
 If both WSL and Windows-host Ollama are running, pick the intended menu entry during onboarding so NemoClaw validates and pulls models against the right daemon.
 
@@ -49,7 +49,8 @@ $ curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
 ```
 
 On DGX Spark, DGX Station, and Windows WSL, an interactive installer offers express install after you accept the third-party software notice.
-Express install switches onboarding to non-interactive mode, allows `sudo` password prompts for required host changes, applies the suggested security policy, and selects the managed local inference path for that platform.
+Express install switches onboarding to non-interactive mode, allows `sudo` password prompts for required host changes, and selects the managed local inference path for that platform.
+Unless `NEMOCLAW_POLICY_TIER` is set, it applies sandbox policy in `suggested` mode with the `balanced` tier by default, using the base sandbox policy plus supported package, model, web-search, and local-inference presets.
 On WSL, express install selects the Windows-host Ollama setup path.
 Set `NEMOCLAW_NO_EXPRESS=1` to skip the express prompt, or set `NEMOCLAW_PROVIDER` before launching the installer when you want to choose a provider yourself.
 
 
@@ -45,6 +45,9 @@ $ curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
 
 If the bootstrap script reports that Docker is not reachable from Ubuntu, open Docker Desktop Settings and confirm that WSL integration is enabled for Ubuntu (Settings > Resources > WSL integration), then rerun the script.
 
+If the bootstrap script reports that `winget.exe` is not available (common on Windows Server or stripped Windows installs), install **App Installer** from the Microsoft Store (which provides `winget`), or download and install Docker Desktop manually from [docker.com](https://www.docker.com/products/docker-desktop/).
+Rerun the bootstrap script after Docker Desktop is installed; the script skips the install step once it detects Docker Desktop is present.
+
 The manual steps below describe the same Windows preparation pieces and are useful when you need to verify or repair WSL, Ubuntu, or Docker Desktop by hand.
 
 ## Enable WSL 2
 
@@ -4,6 +4,34 @@
 
 NVIDIA NemoClaw is available in early preview starting March 16, 2026. Use this page to track changes.
 
+## v0.0.48
+
+NemoClaw v0.0.48 improves onboarding, sandbox builds, local inference, messaging, and day-two sandbox operations:
+
+- Windows WSL onboarding detects Windows-host Ollama through both the HTTP endpoint and a Windows process probe, so the installer can offer start or restart actions even when the daemon is installed but not yet reachable from WSL.
+- Onboarding no longer prints a noisy `No active forward found` warning when it performs best-effort dashboard forward cleanup before rebuilding or recovering a sandbox.
+- `nemoclaw <name> share mount` verifies the requested remote path against the target sandbox name, so probes for non-default sandboxes no longer accidentally inspect the default sandbox.
+- The OpenClaw plugin tolerates an empty or malformed onboard `config.json` by falling back to default onboard status instead of failing during startup.
+- Hermes messaging policies are scoped to Hermes-supported channel behavior, keeping unsupported OpenClaw-specific messaging access out of Hermes sandboxes.
+- Onboard session snapshots persist machine-readable state for resume flows, which makes provider and policy decisions more durable across retries.
+- DGX Spark GPU sandbox recreation restores the startup path for Hermes by patching Docker GPU state and preserving the marker files the Hermes entrypoint needs.
+- Discord messaging routes REST and gateway traffic through the sandbox proxy path, including a loopback proxy for gateway traffic, so Discord channels work through the same policy-controlled egress model as other sandbox traffic.
+- Sandbox base images now include Homebrew and a `python` to `python3` compatibility symlink, reducing first-run setup for package and script workflows inside the sandbox.
+- The NemoClaw sandbox image includes a Docker health check so container runtimes can report whether the in-sandbox gateway is responding.
+- Sandbox startup resolves workspace template files from the installed package when source-relative files are not available, which helps package installs seed a fresh workspace consistently.
+- Installer checksum verification prefers `sha256sum` and falls back when needed, improving compatibility on Linux hosts where `shasum` is not installed.
+- VM-driver snapshot health checks now use gateway metadata instead of stale local assumptions, so snapshot operations fail less often after gateway state changes.
+
+## v0.0.47
+
+NemoClaw v0.0.47 focused on release hardening and validation coverage:
+
+- The scenario E2E framework gained baseline onboarding coverage for CLI setup, OpenShell gateway creation, sandbox state, inference routing, and smoke tests.
+- Messaging provider scenarios now validate provider attachment, placeholder configuration, secret-leak prevention, bridge reachability, Discord gateway routing, Slack provider state, Telegram injection safety, and token-rotation isolation.
+- CLI command registration was refactored so public display defaults stay consistent across sandbox channel, host, log, policy, skill, and snapshot commands.
+- PR review advisor automation was added for maintainers, with deterministic GitHub context gathering and structured review comments.
+- The release refreshed v0.0.46 documentation, generated user skills, navigation, and version metadata.
+
 ## v0.0.46
 
 NemoClaw v0.0.46 improves Windows setup, messaging channels, Hermes sandboxes, inference routing, and command compatibility:
 
@@ -218,6 +218,8 @@ container image. Inside the sandbox:
 - Network egress is restricted by the baseline policy in `openclaw-sandbox.yaml`.
 - Filesystem access is confined to `/sandbox` and `/tmp` for read-write access, with system paths read-only.
 - The NemoClaw plugin injects sandbox and policy context into agent turns so the agent can report policy blocks accurately.
+- The image exposes a Docker health check that probes the in-sandbox gateway, so container runtimes can report whether the agent service is responding.
+- The image includes common runtime compatibility helpers such as Homebrew and a `python` to `python3` symlink for tools that still invoke `python`.
 
 ## Inference Routing
 
 
@@ -867,7 +867,7 @@ Prerequisites:
 
 - `sshfs` must be installed on the host (`sudo apt-get install sshfs` on Linux, `brew install macfuse && brew install sshfs` on macOS).
 - The sandbox must be running.
-- The remote sandbox path must exist. NemoClaw verifies it before invoking `sshfs` and prints a `connect`, then `ls <path>` check when the probe fails.
+- The remote sandbox path must exist. NemoClaw verifies it against the target sandbox before invoking `sshfs` and prints a `connect`, then `ls <path>` check when the probe fails.
 - Sandboxes created before the `openssh-sftp-server` base image update must be rebuilt with `nemoclaw <name> rebuild`.
 - The local mount path must be on a writable filesystem; FUSE creates the mount on the host side.
   If the default `~/.nemoclaw/mounts/<name>` lives on a read-only filesystem, pass an explicit writable path as the second positional argument.
 
@@ -800,6 +800,54 @@ In that case:
 - inspect gateway logs and blocked requests with `openshell term`
 - treat the failure as a native Discord gateway problem, not as a bridge startup problem
 
+### Discord preset validation behind a proxy
+
+The built-in Discord policy preset intentionally allows the Node binaries used by the messaging runtime and does not allow `curl`.
+As a result, `curl -s https://discord.com` failing, hanging, or printing no output is not proof that the Discord preset is broken.
+
+Behind the OpenShell proxy, direct DNS-only checks can also be the wrong signal.
+For example, `dns.resolve("gateway.discord.gg")` can fail even when HTTPS requests routed through the proxy are healthy.
+
+Use Node HTTPS as the manual REST probe:
+
+```console
+$ node - <<'NODE'
+const https = require("node:https");
+
+https
+  .get("https://discord.com/api/v10/gateway", (res) => {
+    console.log(`${res.statusCode} ${res.statusMessage || ""}`.trim());
+    res.resume();
+  })
+  .on("error", (err) => {
+    console.error(err.message);
+    process.exitCode = 1;
+  });
+NODE
+```
+
+To check Discord CDN egress, use the same Node HTTPS path:
+
+```console
+$ node - <<'NODE'
+const https = require("node:https");
+
+https
+  .get("https://cdn.discordapp.com/", (res) => {
+    console.log(`${res.statusCode} ${res.statusMessage || ""}`.trim());
+    res.resume();
+  })
+  .on("error", (err) => {
+    console.error(err.message);
+    process.exitCode = 1;
+  });
+NODE
+```
+
+Any HTTP status from these probes means the Node process reached the endpoint; the exact status can vary by unauthenticated path.
+If the Node REST probe works but the Discord channel is still unhealthy, investigate the native gateway path instead of widening the preset.
+Check the gateway logs and blocked-request output with `openshell term`, and look for `gateway.discord.gg` connection or WebSocket upgrade failures.
+
 ### Messaging bridge appears running but no messages arrive
 
 Bot tokens for Telegram (`getUpdates`), Discord (gateway), and Slack (Socket Mode) only allow one active consumer per token. If two NemoClaw sandboxes are configured with the same bot token, each one kicks the other off its polling connection and neither delivers messages. `nemoclaw status` still reports the bridge as running because the gateway process itself is alive.
@@ -1131,6 +1179,20 @@ $ wsl -d Ubuntu
 $ docker info
 ```
 
+### Windows-host Ollama is installed but not shown during onboarding
+
+When NemoClaw runs inside WSL, it checks both the Windows-host Ollama HTTP endpoint and the Windows `ollama.exe` process.
+If Ollama is installed but the daemon is not reachable through `host.docker.internal:11434`, the wizard should still offer a start or restart action.
+
+If the Windows-host option does not appear, confirm that PowerShell interop is enabled in WSL and that Windows can locate Ollama:
+
+```console
+$ powershell.exe -NoProfile -Command "Get-Process ollama -ErrorAction SilentlyContinue"
+```
+
+If the process is missing, start Ollama from Windows and rerun onboarding.
+If the process exists but the endpoint is unreachable, use the restart action when the wizard offers it, or restart Ollama from Windows with `OLLAMA_HOST=0.0.0.0:11434`.
+
 ### Ollama inference fails or hangs in WSL
 
 Ollama configures context length based on your hardware.
 
@@ -65,12 +65,15 @@ jobs:
           PREVIEW_ID: pr-${{ github.event.pull_request.number }}
         working-directory: ./fern
         run: |
+          set +e
           OUTPUT=$(fern generate --docs --preview --id "$PREVIEW_ID" 2>&1)
+          STATUS=$?
+          set -e
           echo "$OUTPUT"
-          URL=$(echo "$OUTPUT" | grep -oP 'Published docs to \K.*(?= \()')
+          URL=$(echo "$OUTPUT" | sed -nE 's/.*Published docs to (https?:\/\/[^[:space:]]+).*/\1/p' | head -n1)
           if [ -z "$URL" ]; then
             echo "::error::Failed to generate preview URL. See fern output above."
-            exit 1
+            exit "$STATUS"
           fi
           echo "preview_url=$URL" >> "$GITHUB_OUTPUT"
 
 
@@ -11,6 +11,34 @@ content:
 ---
 NVIDIA NemoClaw is available in early preview starting March 16, 2026. Use this page to track changes.
 
+## v0.0.48
+
+NemoClaw v0.0.48 improves onboarding, sandbox builds, local inference, messaging, and day-two sandbox operations:
+
+- Windows WSL onboarding detects Windows-host Ollama through both the HTTP endpoint and a Windows process probe, so the installer can offer start or restart actions even when the daemon is installed but not yet reachable from WSL.
+- Onboarding no longer prints a noisy `No active forward found` warning when it performs best-effort dashboard forward cleanup before rebuilding or recovering a sandbox.
+- `nemoclaw <name> share mount` verifies the requested remote path against the target sandbox name, so probes for non-default sandboxes no longer accidentally inspect the default sandbox.
+- The OpenClaw plugin tolerates an empty or malformed onboard `config.json` by falling back to default onboard status instead of failing during startup.
+- Hermes messaging policies are scoped to Hermes-supported channel behavior, keeping unsupported OpenClaw-specific messaging access out of Hermes sandboxes.
+- Onboard session snapshots persist machine-readable state for resume flows, which makes provider and policy decisions more durable across retries.
+- DGX Spark GPU sandbox recreation restores the startup path for Hermes by patching Docker GPU state and preserving the marker files the Hermes entrypoint needs.
+- Discord messaging routes REST and gateway traffic through the sandbox proxy path, including a loopback proxy for gateway traffic, so Discord channels work through the same policy-controlled egress model as other sandbox traffic.
+- Sandbox base images now include Homebrew and a `python` to `python3` compatibility symlink, reducing first-run setup for package and script workflows inside the sandbox.
+- The NemoClaw sandbox image includes a Docker health check so container runtimes can report whether the in-sandbox gateway is responding.
+- Sandbox startup resolves workspace template files from the installed package when source-relative files are not available, which helps package installs seed a fresh workspace consistently.
+- Installer checksum verification prefers `sha256sum` and falls back when needed, improving compatibility on Linux hosts where `shasum` is not installed.
+- VM-driver snapshot health checks now use gateway metadata instead of stale local assumptions, so snapshot operations fail less often after gateway state changes.
+
+## v0.0.47
+
+NemoClaw v0.0.47 focused on release hardening and validation coverage:
+
+- The scenario E2E framework gained baseline onboarding coverage for CLI setup, OpenShell gateway creation, sandbox state, inference routing, and smoke tests.
+- Messaging provider scenarios now validate provider attachment, placeholder configuration, secret-leak prevention, bridge reachability, Discord gateway routing, Slack provider state, Telegram injection safety, and token-rotation isolation.
+- CLI command registration was refactored so public display defaults stay consistent across sandbox channel, host, log, policy, skill, and snapshot commands.
+- PR review advisor automation was added for maintainers, with deterministic GitHub context gathering and structured review comments.
+- The release refreshed v0.0.46 documentation, generated user skills, navigation, and version metadata.
+
 ## v0.0.46
 
 NemoClaw v0.0.46 improves Windows setup, messaging channels, Hermes sandboxes, inference routing, and command compatibility:
 
@@ -55,15 +55,16 @@ On WSL, if you choose the Windows-host Ollama path, NemoClaw uses `host.docker.i
 
 When NemoClaw runs inside WSL, the provider menu can include Windows-host Ollama actions:
 
-- **Use Ollama on Windows host** when the Windows daemon is already reachable.
-- **Restart Ollama on Windows host** when the daemon is installed but only bound to Windows loopback.
-- **Start Ollama on Windows host** when Ollama is installed but not running.
-- **Install Ollama on Windows host** when Windows does not have Ollama installed.
+- Use Ollama on Windows host when the Windows daemon is already reachable.
+- Restart Ollama on Windows host when the daemon is installed but only bound to Windows loopback.
+- Start Ollama on Windows host when Ollama is installed but not running.
+- Install Ollama on Windows host when Windows does not have Ollama installed.
 
 The install and restart paths set `OLLAMA_HOST=0.0.0.0:11434` on the Windows side so Docker and WSL can reach the daemon through `host.docker.internal`.
 After an install or restart action, NemoClaw relaunches Ollama from the detected Windows tray app or verified `ollama.exe` path and waits until `host.docker.internal:11434` responds.
-If the daemon does not become reachable, onboarding prints PowerShell commands you can run to inspect the Windows-side process and port state.
-Use one Ollama instance on port `11434` at a time.
+
+If the HTTP endpoint is not reachable yet, NemoClaw also checks for the Windows `ollama.exe` process through PowerShell interop so it can offer a start or restart action instead of hiding the Windows-host path.
+If the daemon does not become reachable, onboarding prints PowerShell commands you can run to inspect the Windows-side process and port state. Use one Ollama instance on port `11434` at a time.
 If both WSL and Windows-host Ollama are running, pick the intended menu entry during onboarding so NemoClaw validates and pulls models against the right daemon.
 
 <Warning>