Description

nemoclaw <name> policy-add and policy-remove present a numbered preset picker and a Y/n confirmation. They do not accept the preset name as an argument, do not honor NEMOCLAW_NON_INTERACTIVE=1, and do not accept input on stdin — every piping attempt drops the input before the prompt appears, and the command silently returns to the prompt without applying anything.

For sandboxes provisioned over SSM Send-Command, SSH-without-TTY, or any other headless/CI path, this makes it impossible to script preset changes after onboard. The only workaround I found is installing expect inside the host and running:

spawn nemoclaw <sandbox> policy-add
expect "Choose preset"
send "11\r"
expect "Apply 'slack'"
send "y\r"
expect eof

This is fragile (depends on the preset's menu position and prompt wording both staying stable across versions).

Why this matters for me

Related to #2014 — when onboarding enables a messaging channel but the corresponding policy preset is not auto-applied, you have to apply it post-onboard. On a headless EC2 host that is exactly when policy-add becomes the blocker.

Relation to #2039

#2039 is the orthogonal gap (custom preset YAML input via --from-file). This filing is about the scriptability of the existing 11 built-in presets: even when the preset already exists and the operator knows its name, there is no non-interactive path to apply it. A single nemoclaw <sandbox> policy-add <preset-name> --yes form would close this axis; #2039's --from-file would close the other.

Environment

• OS: Amazon Linux 2023 on EC2
• Node: v22.22.2
• NemoClaw: v0.0.18-21-g800195b5

Reproduction

# Any of these silently no-op without applying:
echo "11" | nemoclaw <sandbox> policy-add
printf "11\ny\n" | nemoclaw <sandbox> policy-add
{ echo 11; sleep 1; echo y; } | nemoclaw <sandbox> policy-add
NEMOCLAW_NON_INTERACTIVE=1 nemoclaw <sandbox> policy-add slack

None apply the preset. policy-list afterward shows the preset is still ○ not applied.

Requested outcome

One of:

1. Positional argument: nemoclaw <sandbox> policy-add <preset-name> that skips both prompts when the preset name is valid and unambiguous. Add --yes for the confirmation, and --dry-run already documented in --help should work in argument form too.
2. Honor stdin: when stdin is not a TTY, read the preset name (or number) + a y/n from it instead of requiring a TTY.
3. Honor NEMOCLAW_NON_INTERACTIVE=1 + env: e.g. NEMOCLAW_POLICY_ADD=slack NEMOCLAW_NON_INTERACTIVE=1 nemoclaw <sandbox> policy-add.

Option 1 is the cleanest for CI/SSM/SSH. Option 2 is the minimum viable fix.

The existing --dry-run and --help flags imply this command was meant to be scriptable — the prompt-only UX looks like an oversight.

Checklist

• I reproduced the issue on a clean host
• I searched existing issues and did not find a duplicate for this specific subcommand