You'll noticeTier: how much it should matter to you
5Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
Sandbox NetworkArea: what it touches
Internal ChangesKind: in v2.1.268,
What probably matters to youSection of the release
What
Bash, PowerShell, and Monitor tool calls can now include an allowed_domains field 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_domains list 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 new registerCommandNetworkLists/unregisterCommandNetworkLists sandbox 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_rain flag 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.
