blueclawWhat is not enforced
blueclaw has no executable allowlist, no denied command list, no denied path prefix, and no prompt instruction telling the model what it may not touch.
A command the requester may not run fails at the kernel, as it would for that person at a shell. Every such list would be a second copy of permissions the kernel already enforces, and it would go stale and block work the person is entitled to do. Inside the requester's permissions the agent may install a package, walk the filesystem or run a build without asking.
TerminalConfiguration has nine fields: mode, the sandbox provider, workspaceRootPath, posixHelperPath, timeoutSecond, outputMaxBytes, sessionMaxCount, allowNetwork and allowInteractiveShell. None is a list. The guardrail's checks are structural:
| Check | Where |
|---|---|
| refuses to execute when the daemon is effectively root | BuildCommandPlan |
| resolves the working directory against the workspace root | resolveWorkingDirectoryPath |
builds the environment from the identity and forces a canonical PATH | sanitizeEnvironmentVariables, applyPOSIXEnvironment |
| caps the timeout | timeoutSecond |
requires bubblewrap when terminal.mode is sandbox | BuildCommandPlan |
Two things in this path look like string filters and decide nothing: shell argument quoting is serialization, and matching stderr classifies a command that has already failed into a diagnostic code.
Effects that leave the machine, such as sending a message or publishing a site, are judged by a person at the approval gate.