Description

Description

The github policy preset advertises itself in policy-list / policy-add as "GitHub.com and GitHub API access (git, gh)" and in nemoclaw status lists /usr/bin/gh in the binary whitelist alongside /usr/bin/git. However, the NemoClaw sandbox image does not ship the gh CLI — /usr/bin/gh does not exist and which gh returns nothing. Users who apply ● github and run gh api ... expecting GitHub API access (as the label advertises) get bash: gh: command not found. Same class of "phantom binary in preset whitelist" as already-filed bugs 6066204 (brew), 6044745 (docker), 6072132 (brew).

Environment:

Device:        WSL2 VM on Windows 11 x86_64 (hostname 2u1g-x570-1865), 64 GB RAM + 16 GB swap, no GPU
OS:            Windows 11 build 10.0.28000.1836; WSL2 distro Ubuntu 24.04.4 LTS (Noble Numbat), kernel 6.6.87.2-microsoft-standard-WSL2
Architecture:  x86_64
Node.js:       v22.22.2 (installed via nvm by the NemoClaw installer)
npm:           10.9.7
Docker:        Docker CE 29.4.1 (from get.docker.com)
OpenShell CLI: openshell 0.0.26
NemoClaw:      v0.0.21 (installed via `curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash` from GitHub latest)
OpenClaw:      2026.4.2 (d74a122)

Reproduction Steps

1. nemoclaw onboard — create sandbox sec with NVIDIA Endpoints + Nemotron 3 Super 120B (any configuration works; preset binary set is static).
2. nemoclaw sec policy-add → select github, confirm with Y.
3. Observe the policy-add dialog wording:

    Endpoints that would be opened: github.com, api.github.com
    Apply 'github' to sandbox 'sec'? [Y/n]: Y
    ✓ Policy version 11 loaded (active version: 11)
    Applied preset: github

4. nemoclaw sec policy-list — confirm the preset label advertises gh:

    ● github — GitHub.com and GitHub API access (git, gh)

5. nemoclaw sec connect — enter the sandbox.
6. Inside the sandbox, probe what the preset actually points at vs what's installed:

    which gh
    gh --version
    ls -la /usr/bin/gh /usr/bin/git

Actual Result

Inside sandbox sec with ● github applied:

sandbox@sec:~$ which gh
# (empty — no output)
sandbox@sec:~$ gh --version
bash: gh: command not found
sandbox@sec:~$ gh api /repos/octocat/Hello-World
bash: gh: command not found
sandbox@sec:~$ ls -la /usr/bin/gh /usr/bin/git
ls: cannot access '/usr/bin/gh': No such file or directory
-rwxr-xr-x 1 root root 3713416 Oct  7  2025 /usr/bin/git

Meanwhile, git works correctly through the same preset (confirming the policy itself is fine — this is strictly a missing-binary issue):

sandbox@sec:~$ GIT_SSL_NO_VERIFY=true git clone https://github.com/octocat/Hello-World.git /tmp/test-repo
Cloning into '/tmp/test-repo'...
sandbox@sec:~$ ls -la /tmp/test-repo/
drwxr-xr-x 8 sandbox sandbox 4096 Apr 21 12:55 .git
-rw-r--r-- 1 sandbox sandbox   13 Apr 21 12:55 README

(The GIT_SSL_NO_VERIFY=true workaround is only needed because of separate Open bug 6072119 — proxy CA missing in sandbox trust store. That is not part of this bug's scope; this bug is strictly about the gh binary not being present.)

Preset binary declaration from nemoclaw sec status (evidence that /usr/bin/gh is in the preset spec — format reproduced from existing bug 6062950 where the same spec was captured):

github:
  name: github
  endpoints:
    - host: github.com port: 443 access: full
    - host: api.github.com port: 443 access: full
  binaries:
    - path: /usr/bin/gh       ← phantom — not present in sandbox image
    - path: /usr/bin/git      ← present (3.7 MB, root:root)

Expected Result

Either:

(a) The gh CLI is installed in the sandbox image (at /usr/bin/gh), so the preset works as advertised and gh api /repos// succeeds when ● github is active. OR

(b) If shipping gh in the base image is out of scope, remove /usr/bin/gh from the github preset's binaries: list and drop "gh" from the CLI/TUI label — change from (git, gh) to just (git). The preset surface area should honestly reflect what is usable in the shipped sandbox.

Either way, a user who applies ● github and runs gh api ... inside the sandbox should not hit bash: gh: command not found — they should either get a working gh or should not have been told gh is part of the preset.

Root Cause

The github preset YAML (likely nemoclaw-blueprint/policies/openclaw-sandbox.yaml or equivalent) lists /usr/bin/gh in its binaries section. The NemoClaw sandbox base Dockerfile (ghcr.io/nvidia/nemoclaw/sandbox-base:latest + overlay) installs git via apt but does not apt-install gh. No validation step checks that every binary listed in a preset's binaries: actually exists in the built image.

Precedent fixes for the same pattern:

• 6066204 (FIXED) — brew preset binary missing → fix path likely either installed brew in image OR removed brew from the preset binary list
• 6044745 (FIXED) — /usr/bin/docker missing → similar resolution
• 6072132 (OPEN) — newer brew preset variant, still broken

The cheapest fix for this specific bug is option (b) from Expected: drop gh from the preset binary list and from the label. Shipping gh in the base image is the fuller fix but has size / supply-chain implications (additional apt source: https://cli.github.com/packages).

Related bugs worth cross-linking in triage:

• 6066204 (FIXED) — same pattern on brew preset
• 6044745 (FIXED) — same pattern on docker preset
• 6072132 (OPEN) — same pattern, brew variant
• 6062950 (OPEN) — documents github preset's binaries list (contains the /usr/bin/gh entry)
• 6018311 (FIXED) — fixed github preset network whitelisting, but did not address the UX/docs transparency gap around binary scoping; this bug is a concrete manifestation of that unresolved transparency gap

• User trust / clarity: Users who apply ● github because they read the (git, gh) label expect both binaries to work. The gh gap is a silent surprise.
• Wasted debugging: A user running gh auth login or gh pr list inside sandbox will hit command not found, then likely suspect policy / network misconfiguration before realizing the binary simply isn't installed. Non-obvious failure mode.
• Pattern repeat: This is now the 4th "phantom binary in preset whitelist" instance (brew x2, docker x1, github x1). Points to a systemic gap in the preset definition → sandbox image contract — presets are authored against an assumed toolchain that the image doesn't ship.

Bug Details

[NVB#6100274]