fix: probe for the sandbox enforcer instead of assuming one (#1) - #2
Merged
Conversation
grok 1.0.3's Linux enforcer is bubblewrap, which plain Debian/Ubuntu and WSL images do not ship. It does not warn and continue — it refuses to start with exit 1 and empty stdout, so from the plugin's side every sandboxed invocation just failed, several layers from the cause. @roy7 reported it with a live repro. The two modes get different answers on purpose. A read-leaning rescue's primary guard is the tool deny list, which needs no kernel, so it drops the flag and runs with one belt instead of two. `--write` refuses: there the workspace sandbox is the only thing bounding edits, and degrading it silently would hand an agent the whole disk. The error carries `apt install -y bubblewrap`. Also stops re-asserting --sandbox on --resume. Passing a profile that differs from the session's saved one is a hard error and omitting it is always accepted, so the safe rule is to not send it again. The README claimed the opposite behaviour — silent degradation under Landlock, verified empirically against an older Grok. Corrected, with the asymmetry and the override documented. Tests cover both machines, which is the part that was missing: the fake grok cannot tell the suite whether this box can enforce a sandbox, so GROK_COMPANION_SANDBOX stands in for the machine and every sandbox assertion now runs twice.
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
1 participant
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.
Fixes #1, reported by @roy7 with a live repro on WSL2 Ubuntu / grok 1.0.3.
The bug
buildHeadlessArgspushed--sandboxunconditionally for both task modes.Grok's Linux enforcer is bubblewrap, which plain Debian/Ubuntu and WSL
images do not ship, and grok 1.0.3 does not warn-and-continue — it refuses:
Exit 1, empty stdout. Every sandboxed invocation failed with the cause several
layers from the symptom.
The fix
Probe first, then answer differently per mode — the asymmetry is the point:
rescue(read-leaning)rescue --write--sandbox read-only+ deny list--sandbox workspaceRead-leaning rescues are guarded primarily by the tool deny list, which needs
no kernel — losing the sandbox costs one belt out of two. For
--writethesandbox is the only thing bounding edits, so degrading it silently would be
worse than failing.
GROK_COMPANION_SANDBOX=on|offoverrides the probe.Also:
--sandboxis no longer re-sent on--resume. Per @roy7's owncorrection in the thread, omitting it is always accepted and only a differing
profile is a hard error — so not sending it is the simple safe rule.
Docs were wrong too
The README's Security Model said the sandbox silently degrades under
Landlock, "verified empirically". That was true of an older Grok and is the
opposite of 1.0.3's behaviour. Corrected in README and llms.txt.
Tests
58 pass. The gap that let this ship: the fake grok cannot tell the suite
whether the box can enforce a sandbox, so every sandbox assertion ran once, on
the happy machine.
GROK_COMPANION_SANDBOXnow stands in for the machine andthey run twice — including a companion-level test that
--writeexits 1 withbubblewrapin the message.