Description

[Description]
When the jira policy preset is applied to a NemoClaw sandbox, the documented test case expects per-binary enforcement: curl to auth.atlassian.com should be locally blocked (exit “000”) while Node to api.atlassian.com is allowed, and approving the curl request in openshell term should then allow curl to work. In practice, Node sees a 301 from api.atlassian.com as expected, but curl -s --max-time 10 https://auth.atlassian.com produces no visible body or error both before and after approval, and does not clearly exhibit “000” vs “allowed” behavior. This suggests the Jira preset is not enforcing a binary whitelist as specified, and/or the curl behavior in this test cannot be observed as written.

[Environment]
(adapt your actual sandbox versions.)

NemoClaw: v0.0.44

OpenShell CLI: 0.0.39

OpenClaw: 2026.4.24

Sandbox OS: Linux (default NemoClaw base, x86_64)

Network: outbound HTTPS generally allowed (no 403 proxy like the Discord-proxy case).

[Steps to Reproduce]
Pre-condition:

1. Sandbox running, no extra presets applied
   Steps:
2. Run: nemoclaw policy-add
3. Select "jira" from preset list
4. Confirm application
5. Run: nemoclaw connect
6. Inside sandbox: curl -s --max-time 10 https://auth.atlassian.com
7. Inside sandbox: node -e "require('https').get('https://api.atlassian.com', r => console.log(r.statusCode))"
8. Use openshell term approve the curl request
9. Exit sandbox

Inside sandbox:

curl -v --max-time 10 https://auth.atlassian.com
echo $?

node -e "require('https').get('https://api.atlassian.com', r => console.log(r.statusCode))"
In openshell term, approve the curl request for auth.atlassian.com.

Retry the curl with -v and echo $?.

[Expected]

Before approval: curl is locally blocked with a non-normal status (“000” or explicit NemoClaw error), and no outbound TLS handshake is attempted (per-binary whitelist enforcement).

Node returns 200/301 as it is allowed by the Jira preset.

After approval: curl succeeds with 200/301, clearly different from the pre-approval behavior.

[Actual]

Node returns 301 from api.atlassian.com as expected.

curl -s --max-time 10 https://auth.atlassian.com shows no visible difference before vs after approval; the “000 blocked” pattern is not observable.

Behavior matches the known issue where presets permit any binary to access allowed endpoints, instead of enforcing a binary whitelist.

Bug Details

[NVB#6188234]