fix(pre-bash,worktree-guard): block filesystem-root wipes and empty-collapse expansions

[andrei-hasna]

The incident this prevents

On 2026-07-24 a subagent composed this at inference time and ssh'd it to station02:

bash -c 'rm -rf "$(bun pm cache)"/* ; … bun add -g @hasna/connectors@1.3.45'

bun pm cache writes its path to stdout on success, but exits 1 with an error on stderr
and nothing on stdout when no package.json is found walking up from cwd. The
substitution collapsed to empty, so the command ran as rm -rf /*. Unprivileged, ~5
minutes, ~700 GB freed, org repo checkouts on station02 destroyed. One repository's source
(hasna/cloud) is permanently gone. The agent never saw it: a local timeout 150 killed the
ssh client, the tool result was Exit code 143, and it retried without the rm.

$(bun pm cache) with or without 2>/dev/null is equally dangerous — the redirect
discards the diagnostic, not the path. The precondition is "no package.json walking up from
cwd", not any bun version. 13 of 16 stations reproduce it.

Why the existing guard was not the fix

The pre-bash destructive-shell guard was scoped to ~/.hasna, workspace roots and repo
roots. Measured on origin/main @ 2e654bc, driving hooks/pre-bash/src/hook.ts with
command strings:

rm -rf /home/hasna/.hasna    -> {"decision":"block"}   <- control: classifier works
rm -rf /*                    -> {"continue":true}      <- NOT BLOCKED
rm -rf "$(bun pm cache)"/*   -> {"continue":true}      <- NOT BLOCKED

The baseline is wider than reported. These were also unguarded:

rm -rf /usr/*   rm -rf /etc   rm -rf /var/*   rm -rf /home/*   rm -rf "$HOME"/*
rm -fr /*   rm -R -f /*   sudo rm -rf /*   /bin/rm -rf /*   rm -rf -- /*
rm -rf $(bun pm cache)/*   rm -rf `bun pm cache`/*   rm -rf "${VAR}"/*
bash -c 'rm -rf "$(bun pm cache)"/* ; …'      <- the realized incident, verbatim
timeout 150 ssh station02 'rm -rf "$(bun pm cache)"/*'

Enabling that guard unpatched is not remediation. It protects ~/.hasna while / stays
wide open, and says so in its own message.

Three root causes in hooks/codewith-native-common.ts:

1. protectedPathContextFor() had no filesystem or system roots at all.
2. threatensRule() checked a glob content-wipe base with mutatesProtectedPath(), which
   requires the target to be inside the root. So dir/* never matched a protected root
   living under dir. That asymmetry is exactly why rm -rf / blocked (via the ~/.hasna
   tree rule) and rm -rf /* did not.
3. shellWords() / splitShellSegments() did not treat $( ) or backticks as atomic, and
   nothing unwrapped bash -c / ssh. The realized incident's own text was invisible to the
   rm scanner — the whole script was one opaque token.

What this PR implements

Rule 1 — system roots are protected

SYSTEM_PROTECTED_ROOTS: / plus the FHS and macOS system directories. All in root
mode, so a wholesale wipe of a root or its contents blocks while a targeted delete beneath
one still passes:

rm -rf /usr                       -> block
rm -rf /usr/*                     -> block
rm -rf /usr/local/lib/my-build    -> allowed

/tmp is deliberately excluded — scratch cleanup there is routine and bounded. Extend per
machine with HASNA_PROTECTED_SYSTEM_ROOTS (additive only; it cannot remove a root).

Rule 2 — targets that can collapse to empty, blocked by shape

Every destructive target containing a command substitution, backtick substitution or variable
expansion is checked twice: as written, and as the shell would render it if that expansion
returned empty. If the collapsed form hits a protected root, it blocks — regardless of what
the expansion is. This is the rule that catches the next variant nobody has thought of yet.

rm -rf "$(bun pm cache)"/*                              -> block
rm -rf "$(some-command-nobody-has-written-yet)"/*       -> block
rm -rf `cmd`/*    rm -rf "$VAR"/*    rm -rf "${VAR}"/*  -> block
rm -rf /opt/"$APP"/*                                    -> block

Two deliberate non-blocks, both justified rather than incidental:

• Bare rm -rf "$(cmd)", no trailing separator — allowed. An empty expansion makes this
  rm -rf "", which POSIX rm rejects with "cannot remove ''" and a non-zero exit, deleting
  nothing. The entire catastrophic class is the trailing separator, which turns the empty
  string into /. Blocking the bare form would break routine rm -rf "$tmpdir" cleanup for
  zero safety gain — and a guard that blocks routine work gets switched off, which is how this
  class recurs.
• ${VAR:?} / ${VAR:?message} — allowed. POSIX guarantees these abort the shell when
  the variable is unset or empty, so they cannot collapse. This is the idiom the block
  message itself recommends; refusing it would teach agents to drop it. ${VAR?} without
  the colon permits an empty value and is not exempt.

Supporting fixes — each one was an escape found by an adversarial pass

• Content-glob asymmetry. A wholesale glob dir/* is now matched against protected roots
  nested under dir. Narrower globs (dir/build-*) keep their previous weaker check, so
  rm -rf ~/proj* stays allowed while rm -rf ~/* blocks.
• Wrapper unwrapping — required, not optional, since the realized incident lived inside
  bash -c inside ssh: bash/sh/zsh/dash/ksh -c, su -c, runuser -c, eval, and
  ssh host '…', including nested combinations, to depth 3. Remote layers only consider
  absolute targets, because a remote relative path cannot be resolved against the local cwd
  (so ssh host 'rm -rf .' is not a false positive).
• cd tracking — cd / && rm -rf * blocks, and so does cd "$(cmd)"/ && rm -rf ./*,
  which is the incident's shape moved one command to the left.
• for VAR in <root-glob> is followed into rm -rf "$VAR". Only exact $VAR / ${VAR}
  targets bound by a for … in in the same layer are substituted, so it cannot misfire.
• Tokenizer — $( ) and backticks are atomic, with a fallback to the plain tokenizer when
  a substitution is unterminated so nothing is swallowed.
• Block messages name the safe alternative instead of only refusing.

Evidence — failing on bad input, not just passing on good

Full suite: 972 pass, 0 fail (baseline main @ d8c0e8a alone: 941 pass, 0 fail — +31
regression tests). bun run typecheck and bun run build clean.

Rebased onto d8c0e8a ("worktree-guard aligns to canonical 2-segment worktree paths") after
it landed on main and conflicted with this branch. Conflicts were confined to CHANGELOG.md
and two import blocks in hooks/codewith-native-common.test.ts, resolved as a union;
hooks/codewith-native-common.ts auto-merged. Every number and verdict below was re-measured
after the rebase, not carried over.

That commit widens which paths count as managed worktrees, which widens the ~/.hasna
carve-out — so the seam was probed explicitly. Running the classifier with cwd inside a
canonical managed worktree (carve-out live), rm -rf /*, rm -rf /, rm -rf /usr/*,
rm -rf /home/*, rm -rf "$(bun pm cache)"/*, rm -rf ~/.hasna and
rm -rf ~/.hasna/repos/worktrees all still block, while rm -rf dist and
rm -rf ./node_modules stay allowed — 0 mismatches. It holds structurally:
shouldSkipHasnaTreeRule gates on rule.label === "Hasna state root ~/.hasna" before
consulting currentManagedRepoRoot, so the carve-out can only ever suppress that one rule.
System roots are unreachable through it no matter how permissive managedWorktreeInfo becomes.

The three mandated fixtures are asserted verbatim, both against the classifier
(hooks/codewith-native-common.test.ts) and end to end against the hooks run pre-bash
process (src/hooks/codewith-native.test.ts), because the emitted JSON is what actually stops
the tool call.

Driving hooks/pre-bash/src/hook.ts with command strings, before → after:

command	before	after
rm -rf /home/hasna/.hasna (control)	block	block
rm -rf /*	continue	block
rm -rf "$(bun pm cache)"/*	continue	block
bash -c 'rm -rf "$(bun pm cache)"/* ; bun add -g …' (realized incident)	continue	block
rm -fr /* / rm -R -f /* / rm --recursive --force /*	continue	block
sudo rm -rf /* / FOO=bar rm -rf /* / /bin/rm -rf /* / rm -rf -- /*	continue	block
true && rm -rf /* / newline-chained	continue	block
rm -rf $(bun pm cache)/* / rm -rf `bun pm cache`/*	continue	block
rm -rf "${BUN_CACHE}"/* / rm -rf "$BUN_CACHE"/* / rm -rf "$HOME"/*	continue	block
sh -c "rm -rf \"$(bun pm cache)\"/*"	continue	block
timeout 150 ssh station02 'rm -rf "$(bun pm cache)"/*'	continue	block
rm -rf /usr/* / rm -rf /etc / rm -rf /var/* / rm -rf /home/*	continue	block
rm -rf ./node_modules / rm -rf dist / rm -rf /tmp/scratch-1234	continue	continue
rm -rf "$(mktemp -d)" / ls -la / / git status	continue	continue

An adversarial pass then tried to defeat the new guard. Six escapes and two false positives
were found and fixed, and every case is now a committed regression test:

• escapes fixed: eval '…', su -c '…', su root -c '…', cd "$(cmd)"/ && rm -rf ./*,
  for d in /*; do rm -rf "$d"; done, ssh host "cd / && rm -rf *"
• false positives fixed: rm -rf "${CACHE:?cache path required}"/*, rm -rf "${BUN_CACHE:?}"/*

Final adversarial run: escapes=0, falsePositives=0 across 32 attack strings and 12
legitimate-cleanup strings.

No rm is executed at any scope by any test or probe. The classifier is driven with
command strings only.

Known limitations, stated rather than hidden

These are outside the accidental-collapse threat model and are not closed by this PR:

• Deliberate obfuscation such as $'\x2f'* (ANSI-C quoting) or a base64-decoded script.
• Targets arriving on stdin: echo / | xargs rm -rf.
• Heredoc-fed interpreters: bash <<< 'rm -rf /*'.
• Full dataflow. Only for … in bindings are followed; an arbitrary d=/; rm -rf "$d"/*
  chain is not traced (though that one blocks anyway via the collapse rule).
• ssh host rm -rf /* unquoted blocks, but is reported as a local target, because the
  bare rm token is visible to the outer scan. Same verdict, less precise wording.

What remains armed after this lands

Merging this PR changes nothing on any machine by itself. Still required:

1. Publish @hasna/hooks (publish intent to #git-publishing first).
2. Install the published version on all 16 stations.
3. Ensure the hook is actually enabled. The pre-bash guard is currently disabled in
   ~/.codewith/config.toml. Patched-but-disabled protects nothing.

Until all three are done, the 13 stations that reproduce the precondition stay exposed.

A [BREAKING] heads-up was posted to #announcements before this PR was opened
(message 600019).

[andrei-hasna]

Round 2 — adversarial review REJECTED the previous commit; all four bypasses fixed in bb3fbe2

The review was right, and two of the four were regressions this branch introduced against d8c0e8a while advertising a strictly stronger guard. None were covered by the test suite, so the green suite was a false signal on exactly the property being claimed. I reproduced all 24 escape strings and 4 false-positive strings before changing anything.

#	Severity	Hole	Now
B1	critical, regression	a delete inside $( ) was invisible to every rule — echo $(rm -rf /home/hasna/.hasna) was BLOCK on d8c0e8a, continue here. Wrapping the delete in a substitution defeated 100% of the new root protection	substitution bodies are scanned as scripts
B2	critical	a glob was only recognised in the final component, so rm -rf /*/* read as a literal dir named *. It destroys /usr/*, /etc/*, /home/*	every component is scanned; catch-all → threatens, bounded → mutates
B3	high	no brace expansion — rm -rf /{bin,boot,etc,home,lib,opt,root,srv,usr,var} passed	bounded expansion
B4	high, regression	the cd tracker followed a cd the shell confines to a child process; 5 shapes went BLOCK → continue	segmentation reports subshell/pipeline isolation; cd - restores

Also fixed: bash -o errexit -c was never unwrapped (the option’s value was counted as the script operand); regex expansion matching had a fixed nesting depth, so $(dirname "$(dirname "$(bun pm cache)")") and ${A:-${B}} escaped — replaced with a depth-counting scanner, no limit remains.

False positives — fixed, and they matter as much as the escapes

rm -rf "$(pwd)"/*, "$PWD"/*, "${BUILD_DIR:-/tmp/build}"/*, and BUILD=/tmp/build && rm -rf "$BUILD"/* all blocked. A guard that blocks routine cleanup gets switched off, which is how this class of incident recurs. An expansion is now exempt only where the shell provably cannot return it empty: ${VAR:?}, ${VAR:-x} whose default itself survives collapsing, $PWD/$(pwd), and variables assigned a non-empty literal earlier in the same command. ${VAR-x} (no colon) stays collapsible — a set-but-empty variable yields "".

Test weakness the review caught

The SYSTEM_PROTECTED_ROOTS loop asserted only the verdict. /home is also covered by the ~/.hasna tree rule, so it would have stayed green with /home deleted from the list. It now asserts protectedLabel.

Evidence

bun run typecheck   clean
bun run build       clean
bun test            980 pass, 0 fail   (was 972; baseline main d8c0e8a alone: 941)
reviewer probes     escapes=0  falsePositives=0   (24 + 4 strings)

B1/B2/B3 re-confirmed end-to-end through hooks/pre-bash/src/hook.ts, not just the library. Three mandated fixtures still BLOCK. No rm executed at any scope by any test or probe.

Confirmed clean by the reviewer (checked, not skipped)

No ReDoS (linear to 250 KB); no gitCommandInfo/secrets-scan regression across 14 substitution-heavy commit/push forms; the :? vs ? distinction is sound; MAX_WRAPPER_DEPTH/MAX_CWD_VARIANTS not bypassable; and the d8c0e8a merge seam is fine — protectedPathContextFor never calls managedWorktreeInfo, so the new canonical/legacy worktree classification cannot move the ~/.hasna carve-out. That independently confirms the seam probe in the PR body.

Requesting re-review of the round-2 diff (2fe8426..bb3fbe2).

[andrei-hasna]

Round 3 — REJECTED at 9b471e5; 30 escapes + 16 false positives closed in f6def3c

All reproduced before changing anything. Two were regressions this branch introduced, and one was a new fail-open of the class I had already fixed twice.

The two I broke

F1 — (cd X && rm -rf *) was completely unguarded. My B4 fix read isolated as “this cd never applies”, but it only means “does not escape to the parent shell” — segments inside the same subshell do see it. That unguarded the standard cd-without-moving-my-shell idiom, including the realized incident wrapped in parens: (cd "$(bun pm cache)"/ && rm -rf ./*). Seven shapes went BLOCK on 2fe8426 → ALLOW on 9b471e5. My committed test only covered the rm-outside-the-parens form, which is why it stayed green.

F2 — a new fail-open. expansionCannotBeEmpty recursed once per ${A:-…} level while re-scanning the remainder. A 240 KB, 40k-deep input overflowed the stack in 6.0s; hook.ts caught it and answered {"continue":true}, so the rm -rf /* in the same command was never classified. Third time a bound in this file turned “too complex to analyse” into “allowed”. Now 6.0s fail-open → 0.16s block.

The false positives mattered more

rm -rf */node_modules at a monorepo root was blocked, along with */dist, **/dist, /opt/*/logs, /var/*/tmp and seven more; and the truncation refusal hard-blocked …40 substitutions… ; rm -rf dist. A guard that blocks a daily command gets switched off, and then it protects nothing.

Root cause was matching on “the parent of the first glob”, which ignores that a trailing literal bounds the delete. Glob matching is now exact component-by-component semantics: a pattern threatens a root only if it can match that root or an ancestor of it, or wholesale-wipes its contents. Caps raised to 8 wrappers / 256 layers (~2 ms), so ordinary commands never truncate.

Also fixed

F3	the non-empty exemptions were exploitable six ways — prefix assignments (bash expands $X before applying X=… cmd), assignments after the delete, reassignment, empty reassignment, subshell- and pipeline-scoped assignments; $PWD exempt even when reassigned; ${A:-/} safe merely for having a default. Defaults are now substituted verbatim, so ${A:-/} collapses to / and blocks
F4	delete inside ${x:-$(rm -rf /*)} was invisible
F5	verb check missed rm -f --recursive and quoted "rm"
F6	brace fallback missed absolute alternatives {/etc,…}
F7	a ${…} before a brace group abandoned expansion entirely
F8	my own 9b471e5 quote fix handled quotes but not backslashes
F9	cd -P, cd -L, cd --, { cd /; }, pushd

Self-caught while fixing

The precise glob rewrite then missed /*/bin and find /*/x -delete — a catch-all in the first component sweeps every top-level directory, and a trailing literal makes the pattern deeper than any single root — and dropped the piped-cd case. Both were found only by re-running the earlier corpora.

Evidence

typecheck + build   clean
bun test            994 pass, 0 fail   (baseline main d8c0e8a: 941)

All five probe corpora green simultaneously — round-3 (46 cases), round-1 (28), cd/subshell (7), original attack (44), managed-worktree seam (9): escapes=0 falsePositives=0 in every one. Three mandated fixtures still BLOCK end-to-end through the hook binary.

Process fix adopted

The reviewer’s sharpest point was not any single bug: every probe set on this branch was written after the fix it tested, so none could catch a within-branch regression. The round-3 corpus is now committed as tests and replayed on every change — which is precisely what caught the two regressions above.

Requesting re-review of 9b471e5..f6def3c.