feat(exec): add process sandboxing for mise x and mise run

[jdx]

Summary

• Add lightweight process sandboxing for mise exec and mise run, inspired by zerobox
• Linux: Landlock for filesystem, seccomp-bpf for network
• macOS: sandbox-exec (Seatbelt) with generated profiles, including per-host network filtering
• Task-level sandbox config via deny_*/allow_* fields in mise.toml
• Experimental feature (requires experimental=true)
• Documentation at docs/sandboxing.md
• macOS e2e test job added to CI

Usage

# Full lockdown
mise x --deny-all -- node script.js

# Block network
mise x --deny-net -- npm run build

# Block writes except to ./dist
mise x --allow-write=./dist -- npm run build

# Task-level sandboxing
[tasks.build]
run = "npm run build"
deny_net = true
allow_write = ["./dist"]

Platform support

Feature	Linux	macOS
Deny/allow reads	Landlock	Seatbelt
Deny/allow writes	Landlock	Seatbelt
Deny all network	seccomp	Seatbelt
Per-host network	Not yet	Seatbelt
Env filtering	Built-in	Built-in
Docker support	Yes	N/A

Test plan

• Unit tests pass (cargo test --all-features — 540 passed)
• E2E tests for deny-write, deny-read, deny-net, deny-env, deny-all, task sandbox
• All e2e sandbox tests pass on Linux
• macOS e2e tests (new CI job)
• Pre-commit hooks pass

🤖 Generated with Claude Code

---

Note

High Risk
High risk because it changes how mise exec/task execution spawns processes and mutates inherited environment, and introduces OS-level restrictions (Landlock/seccomp/Seatbelt) that could break existing workflows or behave differently across platforms.

Overview
Adds an experimental process sandboxing layer for mise exec (mise x) and mise run, with new --deny-*/--allow-* flags and equivalent mise.toml task fields to restrict filesystem reads/writes, network access, and inherited environment variables.

Implements platform-specific enforcement (Linux: Landlock for FS + seccomp-bpf for networking; macOS: generated sandbox-exec profile with optional per-host network allowlist) and wires it through both direct exec and task execution, including env filtering/clearing when deny_env is active and clear warnings/fallbacks for unsupported platforms.

Updates generated CLI docs/manpages/completions, adds new sandboxing documentation, introduces e2e sandbox tests, and extends CI (macOS) to run the new e2e suite; adds Linux-only deps (landlock, seccompiler) and lockfile updates.

^{Written by Cursor Bugbot for commit e80ac94. This will update automatically on new commits. Configure here.}

[gemini-code-assist]

Code Review

This pull request implements an experimental process sandboxing feature for mise exec and mise run, providing granular control over filesystem, network, and environment variable access on Linux and macOS. The review identifies several technical issues, most notably the use of the unstable let_chains feature which breaks stable compilation, and a lack of async-signal safety in the Linux pre_exec implementation that could lead to deadlocks. Additional feedback addresses thread-safety concerns with environment manipulation, incorrect hostname handling in macOS Seatbelt profiles, and the need for path canonicalization to prevent sandbox bypasses.

[gemini-code-assist]

The use of let_chains (combining let with &&) is currently an unstable Rust feature. Unless this project explicitly uses a nightly toolchain and has enabled the #![feature(let_chains)] attribute, this will cause a compilation error on stable Rust. It is safer to use nested if let statements.

Suggested change

	if let Ok(real) = dir.canonicalize()
	&& seen.insert(real.clone())
	{
	ruleset = add_path_rule(ruleset, &real, read_access)?;
	}
	if let Ok(real) = dir.canonicalize() {
	if seen.insert(real.clone()) {
	ruleset = add_path_rule(ruleset, &real, read_access)?;
	}
	}

[gemini-code-assist]

This block also uses the unstable let_chains feature, which will prevent compilation on stable Rust.

                    if let Some(parent) = dir.parent() {
                        if parent != std::path::Path::new("/") && seen.insert(parent.to_path_buf()) {
                            ruleset = add_path_rule(ruleset, parent, read_access)?;
                        }
                    }

[gemini-code-assist]

This block uses the unstable let_chains feature, which will prevent compilation on stable Rust.

            if !filtered.contains_key(key) {
                if let Ok(val) = std::env::var(key) {
                    filtered.insert(key.clone(), val);
                }
            }

[gemini-code-assist]

This block uses the unstable let_chains feature, which will prevent compilation on stable Rust.

Suggested change

	if !filtered.contains_key(&k)
	&& let Ok(val) = std::env::var(key)
	{
	filtered.insert(k, val);
	}
	if !filtered.contains_key(&k) {
	if let Ok(val) = std::env::var(key) {
	filtered.insert(k, val);
	}
	}

[gemini-code-assist]

The closure passed to pre_exec must be async-signal-safe. In a multi-threaded process, calling functions that perform heap allocations, use locks, or perform complex I/O (like eprintln!, eyre!, HashSet operations, or canonicalize inside landlock_apply) after fork() but before exec() can lead to deadlocks or undefined behavior.

Consider refactoring the sandbox application so that all preparation (like building the Landlock ruleset and opening file descriptors) happens in the parent process, and the pre_exec closure only performs the minimal necessary syscalls (e.g., ruleset.restrict_self()).

[gemini-code-assist]

Iterating over and removing environment variables using std::env::vars() and env::remove_var() is not thread-safe in Rust. Since mise is a multi-threaded application (using tokio), this can lead to data races if other threads are active. It is generally safer to pass the filtered environment directly to the command being executed rather than modifying the process-global environment.

[gemini-code-assist]

Apple's Seatbelt (sandbox-exec) remote ip rule expects an IP address or CIDR range, not a hostname. Providing a hostname here will likely result in an invalid profile or fail to match the actual network traffic (which uses IPs). To support per-host filtering, you would need to resolve the hostnames to their corresponding IP addresses in the parent process before generating the profile.

[gemini-code-assist]

The resolve_paths function joins relative paths with the current working directory but does not canonicalize them. Sandboxing mechanisms like Landlock and Seatbelt are more robust when provided with absolute, canonicalized paths to prevent potential bypasses via symlinks or .. components. Additionally, if current_dir() fails, relative paths remain relative, which might cause the sandbox application to fail or behave incorrectly.

[greptile-apps]

Greptile Summary

Adds an experimental process sandboxing feature for mise exec/mise run using Landlock+seccomp on Linux and Seatbelt (sandbox-exec) on macOS, with task-level deny_*/allow_* fields in mise.toml. The PR addresses several issues from the previous review round (DNS resolution for macOS ip predicates, loud failure for --allow-net on Linux, proper env_clear scoping, write-path read-allow ordering in SBPL).

• sandbox-exec is deprecated in macOS 14+ and users on recent macOS versions may see deprecation warnings.
• Both platforms implicitly block the project CWD under deny_read, which is the most likely source of user confusion when the feature graduates from experimental.

Confidence Score: 4/5

Safe to merge — gated behind experimental=true; critical correctness issues from prior review rounds are addressed

The critical bugs from the previous threads (hostname-in-ip-predicate, Linux allow-net silent bypass, wrong env_clear scope, SBPL write-allow ordering) all appear fixed. Remaining concerns are P2: sandbox-exec deprecation on macOS 14+, project CWD not auto-whitelisted under deny_read (surprising UX but not a bypass), and heap allocation in pre_exec (theoretically unsafe but practically benign). None block merge.

src/sandbox/macos.rs and src/sandbox/landlock.rs — both implicitly block the project CWD under deny_read, the most likely user confusion point

Important Files Changed

Filename	Overview
src/sandbox/mod.rs	Core SandboxConfig type with is_active/effective_deny_* helpers, filter_env, and dual apply paths — logic is sound but creates two parallel code paths
src/sandbox/landlock.rs	Landlock ruleset: correctly uses read_access only when deny_read is active; deny_write-only grants read to '/' so reads remain unrestricted; non-existent allow_write paths emit a warning
src/sandbox/macos.rs	Seatbelt profile: DNS resolution now produces IP literals for allow_net; allow_write read-allows emitted after (deny file-read*) for correct last-match ordering; CWD not auto-whitelisted under deny_read
src/sandbox/seccomp.rs	Blocks AF_INET/AF_INET6 socket()/socketpair() via seccomp-bpf; returns EPERM; supports x86_64 and aarch64 only
src/cmd.rs	apply_sandbox(): Linux uses pre_exec hook, macOS rewrites command to sandbox-exec; execute_raw() correctly overrides piped stdio back to inherit
src/task/task_executor.rs	build_sandbox_for_task correctly merges task-level and CLI sandbox configs; env filtered before setting on cmd; apply_sandbox() awaited before block_in_place
src/cli/exec.rs	Adds deny_/allow_ CLI flags; filters env in current process before execve; calls sandbox.apply() for Landlock in-process on Linux or sandbox-exec on macOS
src/task/mod.rs	Adds deny_all/deny_/allow_ fields to Task struct with serde defaults; deny_all expanded into individual deny flags when building SandboxConfig
e2e/sandbox/test_sandbox_deny_write	Tests write denial outside /tmp and allow-write; pre-creates SANDBOX_DIR so Landlock rule path exists at rule-creation time
e2e/sandbox/test_sandbox_deny_all	Tests deny-all write blocking; avoids deny-all for env check because macOS deny_read can abort bash (noted in comment)

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[mise x / mise run] --> B{sandbox.is_active?}
    B -- No --> C[exec program normally]
    B -- Yes --> D[ensure_experimental]
    D --> E[filter_env]
    E --> F{Platform?}
    F -- Linux --> G[CmdLineRunner with_sandbox]
    G --> H[pre_exec hook in child]
    H --> I{deny_read/write?}
    I -- Yes --> J[apply_landlock]
    H --> K{deny_net?}
    K -- Yes --> L[apply_seccomp block AF_INET]
    J --> M[execve target]
    L --> M
    F -- macOS --> N[apply_sandbox]
    N --> O[generate SBPL profile]
    O --> P{allow_net entries?}
    P -- Yes --> Q[tokio DNS lookup to IPs]
    Q --> R[emit ip literal rules]
    P -- No --> S[emit deny network* only]
    R --> T[rewrite cmd to sandbox-exec]
    S --> T
    T --> U[exec sandbox-exec]
    F -- Windows/Other --> V[warn unsandboxed run normally]

Loading

_{Reviews (10): Last reviewed commit: "[autofix.ci] apply automated fixes (atte..." | Re-trigger Greptile}

[github-actions]

Hyperfine Performance

mise x -- echo

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.1 x -- echo	19.6 ± 0.8	18.4	25.8	1.00
mise x -- echo	20.7 ± 2.9	19.3	82.5	1.05 ± 0.15

mise env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.1 env	19.3 ± 0.7	17.9	21.4	1.00
mise env	19.9 ± 0.7	18.7	22.3	1.03 ± 0.05

mise hook-env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.1 hook-env	20.0 ± 1.1	18.6	30.5	1.00
mise hook-env	20.7 ± 0.9	19.4	29.0	1.03 ± 0.07

mise ls

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.1 ls	19.3 ± 0.5	18.2	21.2	1.00
mise ls	20.0 ± 0.8	18.7	23.9	1.04 ± 0.05

xtasks/test/perf

Command	mise-2026.4.1	mise	Variance
install (cached)	126ms	125ms	+0%
ls (cached)	67ms	69ms	-2%
bin-paths (cached)	71ms	71ms	+0%
task-ls (cached)	629ms	⚠️ 2574ms	-75%

⚠️ Warning: task-ls cached performance variance is -75%

[greg0x]

lol, I literally just started designing the same thing and came here to look around 😄
Nice one! Let me know if I can help get this merged.

Great project btw! Fits exactly how I think about this — and even better in many areas. E.g. the sops secret handling is genuinely awesome!

[jdx]

Bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR