---
name: editing-a-script-under-a-running-bash-mangles-the-live-run-into-vacuous-greens
description: bash reads a script file incrementally by byte offset, so rewriting it while a shell is executing it makes that shell resume mid-line — a mangled env prefix launches the battery without its rig env and every cell skips as a green-looking PASS, not a syntax error
metadata:
  type: feedback
---

todlando 2026-09-07 11:15Z (W2 F17 xbox verify): his run read `.spt/twohost-web-xbox.sh` from MY gate
worktree 03:58-04:07 local; I rewrote that file (arm D) at 04:00:08 and `mutate.py` at 04:00:02, two
minutes into his execution, not knowing he ran out of my tree. His A step's env-prefix line was being
read in that window (its own --no-run build took 23.5 s). bash resumed at a shifted byte offset and
launched `cargo nextest run` with no SPT_TWO_HOST → `Rig::from_env` :126 → all five cells skipped
in 0.0x s = the vacuous-green signature, zero WEB_SERVE_FOR on the owner. The three-way env bisect
(unset sibling / --no-capture / no -E) was exonerated by running the exact A form by hand.

**Why:** the damage is INVISIBLE — a mid-line resume in an env prefix yields a plausible command,
not an error; Summary==1, exit 0, PASS lines. And the editor is usually the OTHER agent who owns
the tree and has no signal that anyone is executing out of it.

**How to apply:** (1) a launcher COPIES the driver and every script it calls to a content-addressed
dir (`.spt/frozen/<sha12>/`) and runs the copy — an edit lands on the next launch, never the live one
(launch-gate.py does this now; `frozen=` in the driver log names the dir). (2) Never edit a script
in a tree another agent may be executing from; if you must, copy-then-edit under a new name.
(3) When a run reads vacuous, check the script's mtime against the run window BEFORE bisecting
env. See [[uniform-zero-second-pass-including-the-must-skip-cell-is-env-that-never-reached-the-child]],
[[a-shared-tool-binary-can-flip-under-a-live-gate]].
- 2026-09-07 face (hertz), on REPRODUCING it: I reproduced the corruption on the first try -- rewrote a running script in place, bash resumed at the stale byte offset and died "unexpected EOF while looking for matching quote" mid-line. I then tried to engineer the SILENT form (shift the offset so a `VAR=1 cmd` prefix truncates into a still-valid line) and FAILED to reproduce it on a 5-line script: it ran healthy. Most likely because a small script is read in one block, so there is no second read to land at a stale offset. **So a failed repro on a toy script is NOT evidence the hazard is absent** -- the real case needed a long slow step (a 23.5s --no-run build) to hold the file open across the edit. Test the FREEZE fix against a driver with a genuinely slow step, never a synthetic sleep in a tiny file, or the test will pass for the wrong reason.