Skip to main content
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. Put blocked commands under command_policies.commands and deny the session caller:
{
  "extends": "default",
  "meta": {
    "name": "agent-with-command-denies"
  },
  "command_policies": {
    "commands": {
      "rm": {
        "from": {
          "session": "deny"
        }
      },
      "chmod": {
        "from": {
          "session": "deny"
        }
      },
      "sudo": {
        "from": {
          "session": "deny"
        }
      }
    }
  }
}
Run:
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:
{
  "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:
{
  "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.
{
  "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 when a command should be allowed with a specific child sandbox, and use this page when a command should not run.