Group of 6 Under the hood
A new allowed_domains option lets sandboxed Bash/PowerShell commands reach specific extra hosts, enforced against the actual sandbox
What
- Bash, PowerShell, and Monitor tool calls can now include an
allowed_domainsfield listing hosts (plain domain, wildcard, or IP, each with an optional port) that a sandboxed command is allowed to reach. In auto mode this list is reviewed together with the command by the auto-mode classifier and applied for that one command; in any other mode it's ignored. - The list is checked against anti-spoofing rules that reject loopback/IPv4-mapped addresses and canonical-form mismatches.
- If a command carries an
allowed_domainslist but wouldn't actually run inside a confining sandbox, execution is now refused outright instead of silently running unconfined. When it does run sandboxed, the list is registered with the sandbox manager for the life of the process and unregistered on exit or error, via newregisterCommandNetworkLists/unregisterCommandNetworkListssandbox functions. - A new canned deny response short-circuits network classification for hosts not in the command's
allowed_domains, returning the message "not in this command's allowed_domains — re-run the command with this host listed if it needs it" instead of running the full classifier. - The whole capability is gated behind the
tengu_flickering_rainflag plus sandboxing being enabled, and applies to both Bash and PowerShell's input validation.
Why
This gives the model a way to ask for specific extra network access a sandboxed command needs (for example, to reach a particular API) without disabling sandbox network confinement altogether, while making sure the allowlist is only honored when a real sandbox is actually enforcing it.