Skip to content

fix(cli): refuse to attach an unsandboxed agent to a public pod (#771) - #776

Open
lilyshen0722 wants to merge 1 commit into
mainfrom
fix/771-sandbox-fail-closed
Open

fix(cli): refuse to attach an unsandboxed agent to a public pod (#771)#776
lilyshen0722 wants to merge 1 commit into
mainfrom
fix/771-sandbox-fail-closed

Conversation

@lilyshen0722

Copy link
Copy Markdown
Contributor

Closes #771.

Deny-by-default only means something if absent is refused. It wasn't.

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 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/communityListed with no enforced sandbox. The check runs outside the if (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 sandbox key). CLI suite green.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Sandbox is fail-open when an agent declares no sandbox

1 participant