Struct SandboxEvent 

pub struct SandboxEvent {
    pub run_id: i64,
    pub step: u32,
    pub kind: String,
    pub backend: Option<String>,
    pub detail: Option<String>,
}

One event in the life of a sandboxed execution: the sandbox created for a run, a command run in it (with the backend that isolated it), a resource cap that killed it, a denied network attempt, or the sandbox torn down.

Together these let an operator audit not just what code ran but where and how it was isolated, reconstructable from the store alone after the run.

use io_harness::{SandboxEvent, Store};

let events = store.sandbox_events(run_id)?;

// Which backend actually isolated the run. The crate picks a native one per
// platform and falls back to a portable floor, so "was this really contained"
// is a question about this field and not about the configuration.
let backend = events.iter().find_map(|e| e.backend.as_deref());
assert_eq!(backend, Some("macos-sandbox-exec"));

// And the phase to look for when a run that used to pass stops passing:
// `criterion-compile` means the criterion no longer compiles *against* the
// subject, which before 0.8.1 could be reported as a pass.
let phases: Vec<&str> = events
    .iter()
    .filter(|e| e.kind == "gate_phase_failed")
    .filter_map(|e| e.detail.as_deref())
    .collect();
assert_eq!(phases, ["criterion-compile"]);

Fields

run_id: i64

The run this execution belongs to.

step: u32

The step it occurred on.

kind: String

"create", "exec", "cap_hit", "destroy", "gate_phase_failed" (whose detail names the phase), or "gate_output" (whose detail is what a failing gate command printed).

A "net_deny" kind was documented here from 0.6.0 to 0.11.0 and never existed: nothing constructed it and nothing emitted it. It was removed in 0.12.0 rather than implemented, because a sandbox denies egress structurally — the backend gives the child no route out, so there is no attempt to observe and nothing to count. Network decisions the harness actually makes are in policy_events with act = "net".

backend: Option<String>

The backend that isolated the run (e.g. "macos-sandbox-exec").

detail: Option<String>

The argv for an "exec", the breached cap for a "cap_hit", or the bounded output of a failing gate command for a "gate_output". Never the agent’s file contents and never credentials — the command line, or what the caller’s own criterion printed.

Implementations

impl SandboxEvent

pub fn create(run_id: i64, step: u32, backend: &str) -> Self

A sandbox was created for a run, isolated by backend.

pub fn exec(run_id: i64, step: u32, backend: &str, argv: &str) -> Self

A command ran in the sandbox under backend.

pub fn cap_hit(run_id: i64, step: u32, cap: &str) -> Self

A resource cap killed the run.

pub fn destroy(run_id: i64, step: u32) -> Self

The sandbox was torn down (workdir removed, processes reaped).

pub fn gate_phase_failed(run_id: i64, step: u32, phase: &str) -> Self

Which phase of an execution gate failed: "subject-compile" (the file under verification does not compile), "criterion-compile" (the criterion does not compile against it), "test-run" (it compiled and the test failed), or "subject-emptied" (the file compiled but a crate-level attribute stripped its items, so nothing was type-checked — the compile-only gates).

0.8.1 added this because the release deliberately makes some previously passing runs fail. criterion-compile is the one to look for: before 0.8.1 the subject and the criterion were one crate, so a subject could shadow the names the criterion used — or delete it outright — and be reported as passing. An operator whose run stopped passing on upgrade can tell that case from an ordinary failed criterion without reading the harness’s source.

A new kind value, not a new table or column: a 0.8.0 store takes it with no migration.

pub fn gate_output(run_id: i64, step: u32, output: &str) -> Self

What a failing gate command printed, already bounded by the caller (0.17.0).

Verification::Command can run any command in any language, so “the criterion did not pass” stops being a self-explaining outcome: cargo test failing because the agent’s change is wrong and npm test failing because the machine has no node_modules are the same discriminant and need opposite responses. The command’s own output is the only thing that tells them apart.

This is the one detail that is not a command line. It is a gate command’s output — a caller-supplied criterion, never the agent’s file contents — and it is what makes a language-agnostic gate diagnosable at all. Bounded by the caller before it arrives here.

use io_harness::{SandboxEvent, Store};

let store = Store::memory()?;
let run_id = store.start_run("make the suite pass", "/repo")?;
store.record_sandbox_event(&SandboxEvent::gate_output(
    run_id, 3, "FAIL test/parse.test.js\n  expected 2 received 1",
))?;

let why = store.sandbox_events(run_id)?;
assert!(why.iter().any(|e| e.kind == "gate_output"
    && e.detail.as_deref().is_some_and(|d| d.contains("expected 2"))));

A new kind value, not a new table or column: a 0.6.0 store takes it with no migration.

Trait Implementations

impl Clone for SandboxEvent

fn clone(&self) -> SandboxEvent

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for SandboxEvent

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for SandboxEvent

impl PartialEq for SandboxEvent

fn eq(&self, other: &SandboxEvent) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for SandboxEvent