Capability

Command allowlist

An opt-in, per-account allowlist enforced on every future exec call — set it once, it applies automatically from then on, across the CLI, both SDKs, and any hosted API caller. 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

No MCP tool exists for managing this — deliberately. See 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 boxkite CLI ↗ section.