Five Sandbox Profiles
Comparing workspace, devbox, read-only, strict, off, and custom Profile boundaries
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Five Sandbox Profiles”?
Comparing workspace, devbox, read-only, strict, off, and custom Profile boundaries
Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.
Write one question you could answer with evidence after trying this idea.
A conclusion that sounds complete but leaves the key assumption untested.
Be able to infer read/write and network boundaries from ProfileName and SandboxProfile, correctly configure custom extends, and identify platform support and degradation conditions.
Profiles Are Multi-Dimensional Capability Presets
Horizontal position aids memory. The actual differences between devbox, workspace, and strict simultaneously involve default reads, writable paths, and network policy.
Full filesystem readable by default; workspace, GROK_HOME, and temp directories writable; no subprocess network restriction.
default_read=truerestrict_network=false
Full filesystem readable by default; enumerates root directories, granting broad write permissions except /data and virtual filesystems; no network restriction.
/data remains readable; write-protected on Linux via bwrapFull filesystem readable by default; workspace not writable; GROK_HOME, temp directories, and required devices remain writable.
restrict_network=trueGlobal default read disabled; only system runtime directories and workspace are open; workspace, GROK_HOME, and temp directories remain writable.
default_read=falserestrict_network=true
Skips capability set application and logs "Sandbox disabled." Also accepts the alias none.
Cannot be used as a base for custom extendsextends Rules
- custom starts from workspace by default.
- Can extend workspace, devbox, read-only, or strict.
- Cannot extend off/none.
- Cannot extend another custom profile.
- read_only, read_write, deny are appended to the base class. When subprocess network restriction is needed, explicitly set restrict_network=true in the custom profile.
Global Priority Protection
The system reads ~/.grok/sandbox.toml first, then .grok/sandbox.toml. Project configuration can only add new profile names. If a project declares a profile with the same name as an existing global profile, merge uses entry.or_insert, keeping the global definition in effect.
Filesystem Constraints
When enforce is enabled and running on Unix, capabilities are applied via Landlock or Seatbelt. macOS deny uses Seatbelt rules; Linux sub-path read-deny also requires bwrap bind-over.
Network Constraints
The main process network remains open to access model APIs. restrict_network is currently expressed through subprocess filtering; the seccomp implementation in source code is effective on Linux, while non-Linux functions are no-ops. Platform boundaries must be verified against actual build and runtime environments.
pub enum ProfileName {
#[default]
Workspace,
Devbox,
ReadOnly,
Strict,
Off,
Custom(String),
}Snapshot note: The enum is fully preserved. The spectrum diagram aids teaching memory; actual capabilities come from resolve(), essential_writable_paths(), and platform apply results.
Classroom Exercise: Design a Review-Only Profile
Requirements: read access to repository and system tools, no workspace write, allow write to temp directories, restrict subprocess networking, and additionally deny ~/.ssh. Choose a built-in base class, write the extends and deny for the custom profile, and explain why a project cannot replace a user-global definition with the same name.
Where the risk boundary sits in “Profiles Are Multi-Dimensional Capability Presets”
“Be able to infer read/write and network boundaries from ProfileName and SandboxProfile , correctly configure custom extends, and identify platform support and degradation condition…” moves security beyond telling a model not to make mistakes. The real protection is ensuring that a mistaken judgment cannot become an irreversible result through permissions, data, or the environment.
Separate model suggestions from real authority
In the flow described by “Horizontal position aids memory.”, check what the user may request, what the model may suggest, what the tool actually permits, and who can approve a write or send action. Web pages, documents, and tool results can carry untrusted instructions; looking like documentation does not grant them authority.
- custom starts from workspace by default
- Can extend workspace, devbox, read-only, or strict
- Cannot extend off/none
Security includes failure and recovery
Use “Requirements: read access to repository and system tools, no workspace write, allow write to temp directories, restrict subprocess networking, and additionally deny ~/.ssh .” for a reverse exercise: add bad input, a missing credential, or an approval that never arrives. Confirm that the system refuses, pauses, and leaves a trace instead of executing to completion.
From “Profiles Are Multi-Dimensional Capability Presets” to “Source-Level Semantics of the Five Built-in Profiles”
“Profiles Are Multi-Dimensional Capability Presets” grounds the problem in “Horizontal position aids memory. The actual differences between devbox, workspace, and strict simultaneously involve default reads, writable paths, and network policy”. “Source-Level Semantics of the Five Built-in Profiles” then moves it toward “Full filesystem readable by default; workspace, GROK_HOME, and temp directories writable; no subprocess network restriction”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For security, separate what the model wants to do from what the system permits. Check data boundaries, tool permissions, human confirmation, and recovery after failure.
- “Profiles Are Multi-Dimensional Capability Presets”: Horizontal position aids memory. The actual differences between devbox, workspace, and strict simultaneously involve default reads, writable paths, and network policy
- “Source-Level Semantics of the Five Built-in Profiles”: Full filesystem readable by default; workspace, GROK_HOME, and temp directories writable; no subprocess network restriction
- “The closing point”: read_only, read_write, deny are appended to the base class. When subprocess network restriction is needed, explicitly set restrict_network=true in the custom profile
The final “The closing point” brings the discussion to “read_only, read_write, deny are appended to the base class. When subprocess network restriction is needed, explicitly set restrict_network=true in the custom profile”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.