[kixelated]

Problem

mbx's low-space GC can delete a target while a program launched directly from it is still running, and drain the shared cache below its ordinary budget. This implements the host configuration for moq-dev/moq#7820, following the recorded incident.

Approach

• Keep every existing checkout's target with target.keep = ["/"]. This covers direct binary execution and the gaps between benchmark runs, without requiring a lease or a process-table scan. Targets whose checkout disappeared remain collectible.
• Set gc.min_free_size = "none" to disable pressure-driven eviction. Normal action-store and incremental-state budgets remain enabled.
• Document inspection, ownership-aware cleanup, and explicit cleanup's ability to remove kept targets.

Impact

• Public API and wire: none.
• Existing checkouts retain targets even when age/size budgets or low disk space would otherwise select them. Retained targets can exceed their budget. Disk exhaustion can fail the build with the ordinary No space left on device error. This is an I/O failure policy, not a disk reservation or an early headroom check.
• Applied through the existing config symlink on desktop. Other hosts receive the policy when their dotfiles are updated.

Alternatives and choices

Lowering the free-space threshold does not protect targets. Upgrading alone does not fix this: upstream's process protection deliberately excludes low-space collection. A lease protects wrapped commands, but does not cover a binary launched after Cargo exits or gaps between launches. Explicitly retaining existing checkouts is simpler than adding another launcher, scan, or grace period. No new refusal threshold or dependency.

The live checkout contained unrelated local commits and uncommitted changes. Source was edited and checkpointed in place; this main-based publication contains only mbx/config.toml and docs/mbx.md. The existing branch and unrelated changes were preserved.

Validation

• Isolated tests on installed mbx 1.25.0 and latest stable 1.29.2 (release archive SHA-256 verified). Each uses a private config, cache and target root, a copied executable with a pipe handshake, and managed-view records aged deterministically. No active/shared host cache was collected.
• Both versions delete the unprotected running target under a forced 100TiB free-space minimum. A shared lease protects it. The tracked config preserves the live target with both the forced minimum and a 1B target budget; abandoned targets are still removed.
• A real tiny Cargo project built through each version, then its build script wrote to /dev/full: Cargo exited 101 and printed StorageFull: No space left on device; the earlier executable remained. Explicit GC with the tracked policy preserved the populated action store and the live target.
• git diff --check origin/main...fix/mbx-target-retention passes. Both mbx versions parse the config; the live settings report ["/"] and none.
• Publication snapshot: quest gate nix develop --command python3 -B -m unittest discover -s <snapshot>/tests -v runs 71 tests, 70 pass. test_normal_run_avoids_cargo_repository_scan errors because its expected stub log is absent. The identical error reproduces on unchanged main 0b312644d3e9bc2c98cda485ebb39d346915f357, also 70/71. The live checkout's additional existing tests give 88/89 with the same sole error. This is not reported as a full-suite pass.

Review

Skipped for 26d375495bfad24cdac99f035cc67e35d7e9a045: two documented retention settings and their usage guide, with no new executable logic. Manually checked the current and 1.25.0 collection paths and validated the behavioral boundary with both released binaries. No sub-agents were started.

Follow-ups

Investigate the pre-existing cleanup shell-dispatch test's missing stub log under this development environment. No matching fix was found among the open dotfiles PRs. Disk reclamation remains an ownership-aware maintenance action; no shared cache or other checkout was deleted here. No new quests or upstream public posts were created.

(Written by GPT-6.1 Sol)