> ## Documentation Index
> Fetch the complete documentation index at: https://nono.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Dangerous Command Blocking

> Block destructive commands with Tool Sandbox command-control policies

Dangerous command blocking prevents selected executables from running through Tool Sandbox shims. Use it for commands that should not be available to an agent at all, such as `rm`, `dd`, `chmod`, package managers, privilege escalation tools, or system administration commands.

This is different from giving a command a restricted child sandbox. A command with a `sandbox` policy is allowed to run with specific grants. A deny-only command is resolved and controlled, but every matching invocation is denied.

## Recommended Shape

Put blocked commands under `command_policies.commands` and deny the `session` caller:

```json theme={null}
{
  "extends": "default",
  "meta": {
    "name": "agent-with-command-denies"
  },
  "command_policies": {
    "commands": {
      "rm": {
        "from": {
          "session": "deny"
        }
      },
      "chmod": {
        "from": {
          "session": "deny"
        }
      },
      "sudo": {
        "from": {
          "session": "deny"
        }
      }
    }
  }
}
```

Run:

```bash theme={null}
nono profile validate ~/.config/nono/profiles/agent-with-command-denies.json
nono run --profile agent-with-command-denies -- rm -rf build
```

Expected:

* `rm` through `PATH` is denied by the Tool Sandbox shim;
* direct canonical-path invocation, such as `/bin/rm`, is denied as a direct-exec bypass of a controlled command;
* no child sandbox is launched for the denied command.

## Blocking Child Tools

Use caller-specific denies when one allowed tool must not launch another tool:

```json theme={null}
{
  "command_policies": {
    "commands": {
      "npm": {
        "can_use": ["node", "sh"],
        "sandbox": {
          "fs_read": ["."],
          "fs_write": ["."]
        }
      },
      "node": {
        "from": {
          "npm": {
            "fs_read": ["."],
            "fs_write": ["."]
          }
        }
      },
      "sh": {
        "from": {
          "npm": "deny",
          "session": "deny"
        }
      }
    }
  }
}
```

Here `npm` may launch `node`, but an attempted `npm` lifecycle escape through `sh` is denied.

## Inherited Dangerous Groups

The default profile includes `dangerous_commands`, `dangerous_commands_macos`, and `dangerous_commands_linux`. These groups still populate the older blocked-command list.

When `command_policies.commands` is non-empty, Tool Sandbox folds inherited blocked commands into deny-only command-control entries. That gives dangerous commands shim coverage and direct-path bypass protection while Tool Sandbox is active.

Inherited blocked commands do not activate Tool Sandbox by themselves. A profile that only inherits `dangerous_commands` still uses the older startup-command warning path. Add at least one `command_policies.commands` entry when you want Tool Sandbox command-control behavior.

## Allowing One Dangerous Command

If a profile inherits `dangerous_commands` but intentionally needs one command, use the profile's `commands.allow` compatibility field to remove that inherited blocked-command entry before Tool Sandbox command-control resolution:

```json theme={null}
{
  "extends": "default",
  "meta": {
    "name": "allow-rm-but-block-rest"
  },
  "commands": {
    "allow": ["rm"]
  },
  "command_policies": {
    "commands": {
      "jq": {
        "sandbox": {
          "fs_read": ["."]
        }
      }
    }
  }
}
```

Prefer avoiding broad command allowances. If the real need is to delete files in one workspace area, use filesystem grants and unlink protection instead of allowing `rm` globally.

## Direct Exec Bypass

Policy-controlled and deny-only commands are meant to be reached through Tool Sandbox shims. Direct paths are denied unless explicitly allowed by `allow_direct_exec_bypass` on a policy-controlled command.

Deny-only commands are never eligible for `allow_direct_exec_bypass`. The profile-wide `deny_direct_exec_bypass` list can also name canonical executable paths that must not be bypassed by any command policy.

```json theme={null}
{
  "command_policies": {
    "deny_direct_exec_bypass": ["/bin/rm"],
    "commands": {
      "rm": {
        "from": {
          "session": "deny"
        }
      }
    }
  }
}
```

## Deprecated Surfaces

These older command-blocking surfaces are still parsed for compatibility, but they are startup-only and are not the preferred authoring path:

* CLI `--block-command`;
* profile `commands.deny`;
* capability manifest `process.blocked_commands`.

For new profiles, put command-control policy under `command_policies`. Use [Tool Sandbox](/docs/cli/features/tool-sandbox) when a command should be allowed with a specific child sandbox, and use this page when a command should not run.