fix(cli): refuse to attach an unsandboxed agent to a public pod (#771) - #776
Open
lilyshen0722 wants to merge 1 commit into
Open
fix(cli): refuse to attach an unsandboxed agent to a public pod (#771)#776lilyshen0722 wants to merge 1 commit into
lilyshen0722 wants to merge 1 commit into
Conversation
The public-agent sandbox is deny-by-default and attack-tested — but it only engages once sandbox.trust and sandbox.mode are declared. sandbox.mode defaults to 'none', and nothing connected "this pod is public" to "this agent must be confined", so an agent attached with no sandbox block ran unconfined, silently. hq-support ran exactly that way in a 67-member public pod until 2026-07-27. Its permission deny-list was doing the file-blocking work while the OS-level sandbox never engaged at all — and I asserted it was sandboxed on the strength of the code existing rather than checking the runtime. Attach now reads the target pod and refuses when it is publicRead or communityListed and no enforced sandbox is declared. The check deliberately runs outside the `if (envPath)` branch, because the dangerous case is an agent with NO environment file — for which that branch never executed. If pod visibility cannot be read (older server, network fault, permissions) attach proceeds, but logs that the check was skipped. Failing an attach on an unrelated fault would be its own footgun; a silent skip is how the original hole stayed invisible. Closes #771 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #771.
Deny-by-default only means something if absent is refused. It wasn't.
sandbox.modedefaults to'none', and nothing connected "this pod is public" to "this agent must be confined" — so an agent attached with no sandbox block ran unconfined, silently.hq-supportran that way in a 67-member public pod until yesterday; its permission deny-list was doing the file-blocking work while the OS sandbox never engaged.Attach now reads the target pod and refuses when it's
publicRead/communityListedwith no enforced sandbox. The check runs outside theif (envPath)branch — the dangerous case is an agent with no environment file at all, for which that branch never executed.Unreadable pod → proceeds with a warning. Failing attach on an unrelated network fault would be its own footgun, but a silent skip is how the original hole stayed invisible.
9 new tests including the exact hq-support shape (env with mcp/skills, no
sandboxkey). CLI suite green.