Skip to content

Checks from concurrent agent sessions can fill a shared box's disk; no way to gate with externally-run verdicts #12

Description

@LopezAdan

On m1 (96G root, also the production fleet node) today, multiple agent sessions ran repo checks concurrently and free disk fell from ~48G to ~4G, nearly taking the box down. The owner has suspended greentree use on this box until this is governed.

Two concrete gaps, one proposal each:

  1. Per-box budget, not per-run floors. min_free_disk (full check needs ~50G of build output and has no disk floor — it filled a production node's root filesystem #6, shipped in Govern disk, gate merges, and find tokens where they live #9) refuses to start under a floor and kills mid-run via statvfs, but each run judges only itself: N concurrent greentree runs (or greentree beside plain cargo builds, Checks that consume build artifacts race concurrent builders in a shared checkout #7) each see enough headroom and collectively fill the disk, because a workspace clippy --all-targets/test check can grow target/ by tens of GB after the pre-start check passes. Proposal: a machine-wide advisory budget — a lock/lease file under $XDG_RUNTIME_DIR/greentree/ recording each live run's declared max footprint (per-check max_disk in greentree.yaml); a run refuses to start when the sum of live declarations plus its own exceeds free space. Declared-but-wrong footprints still get caught by the existing statvfs kill.

  2. No way to publish when one required check is knowingly unrunnable on this box. Today an agent that ran every command of full by hand (all green) still cannot gate/publish because verdicts only come from greentree-executed runs. That forces the exact bare git commit fallback the tool exists to prevent. Proposal: either greentree gate --only <checks> with the skipped required checks recorded as skipped(<reason>) in the publish journal (auditable, not silent), or greentree attest-external <check> that records a verdict for the current tree with external: true provenance so the gate can distinguish trusted-machine-verified from operator-claimed.

Context: hit while building the port-share PoC stack on 2026-08-19; the data-path change was committed bare with the full-check commands run by hand, recorded in the working notes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions