Capability

Command allowlist

An opt-in, per-account allowlist that restricts which commands exec is allowed to run — across the CLI, both SDKs, and any hosted API caller. Set it once and it applies automatically to every future call; empty or unset (the default for every account) means unrestricted.

Get, set, clear

Each rule is either a plain command-name string (unconstrained arguments) or an object with args_allow/args_deny regex patterns matched against the joined argument string.

allowlist.py

client.get_allowed_commands()          # {"rules": [...]} -- [] means unrestricted
client.set_allowed_commands([
    "git",
    {"command": "python3", "args_allow": [r"^-c .*"]},
])
client.clear_allowed_commands()        # back to unrestricted

There's no MCP tool for managing this allowlist — deliberately. See why below.

Why no MCP tool

The MCP server (see the MCP server guide ↗) has no tool for reading or changing this allowlist. Its tools are called by the agent itself— exposing allowlist management as one of them would let a compromised or malicious agent simply widen its own restrictions through its own tool surface, defeating the point. Manage it from outside the agent's tool set: the CLI or either SDK, run by a human or a separate trusted process.

Opt-in guardrail, not a sandbox-escape boundary

Restricts by command name/argument pattern only. Allowing a general-purpose interpreter (python3, bash, node) through the allowlist still permits arbitrary code to run once it starts — the sandbox pod's own isolation is what actually constrains what that code can do, not this allowlist. A blocked command raises an error with code command_not_allowed. Full rationale in the root README's The boxxkite CLI ↗ section.