sandbox: the compressor family is enumerated by name, so its unlisted twins keep the hole (pigz, lz4, lzop, …)

[argszero]

What is still open

PR #1418 names the compressor family to the write-target walk (gzip, gunzip, bzip2, bunzip2,
xz, unxz, lzma, unlzma, zstd, unzstd), with a read-form gate so -c/--stdout/-t/-l
and the -dc cluster stay allowed. That is the family enumerated by name, so every compressor
whose name is not on that list keeps exactly the hole the PR closes: an empty target list, and the
loop that judges targets never runs.

Two rows measured at #1418's own head (78e2c4d1), through the real predicate, workdir=/workspace:

$ python -c "from emrg.tools.bash_tool import _check_sandbox, _extract_write_targets; ..."
lz4 /outside/emrg/f                     targets=[]  read-only=ALLOW  workspace-write=ALLOW
lz4 /outside/emrg/f /outside/emrg/f.lz4 targets=[]  read-only=ALLOW  workspace-write=ALLOW
pigz /outside/emrg/f                    targets=[]  read-only=ALLOW  workspace-write=ALLOW
zstd /outside/emrg/f                    targets=['/outside/emrg/f']  read-only=BLOCK  workspace-write=BLOCK   <- the family #1418 added, for contrast

Why this is not the same residual as the tar / curl family

lz4 is not hypothetical here: it is installed on this host (/opt/homebrew/bin/lz4), so it is
reachable from a sandboxed bash call. The second row is the sharper half — an explicit positional
destination outside the workspace is named by nothing, which is the destination-last shape rsync
had before #1419 rather than the option-value shape tar/curl have.

Ground truth measured first (the discipline this class keeps needing)

The verdict alone is not evidence that a verb needs the write treatment, so the semantics were
measured in a scratch directory before this issue was written:

$ cd $(mktemp -d) && printf 'hello compressors\n' > f && lz4 f && ls
Compressed filename will be : f.lz4
f  f.lz4          # rc=0; f still present, f.lz4 created

So lz4 is not a gzip-style in-place rewriter: its default form derives a new path beside the
operand. That is a write the walk cannot see in the same direction as the gzip -k row #1418
blocks (a second file appears), not the same as gzip -S.c (which the PR documents as a named limit).
It also means the first question for this issue is not "which verbs join the set" but what each
verb's default form does, per verb:

verb	default form	shape
pigz, pbzip2, pixz, plzip, lbzip2	in-place twin of the gzip/bzip2/xz CLI	same as the family #1418 added
lz4	derives a sibling path (f → f.lz4), keeps the operand	write, operand unnamed; the derived path is not nameable without a per-verb rule
lzop, brotli, lzip	to be measured	—

pigz is listed first because it is the exact twin of gzip (pigz f → f.gz, operand removed;
pigz -d/unpigz decompress), so it should need no new mechanism — only a name in the set and a row
in the read-form table.

What this issue asks for

1. Ground truth per verb first (the lz4 measurement above is the template), because the two
   families differ: an in-place twin can join _COMPRESSOR_VERBS and inherit the read gate, while a
   sibling-deriving verb needs to name its operand or its derived path, and a verb whose default form
   is a read must not be swept in at all.
2. At least pigz/unpigz — the same shape as the family already fixed, one name and one row.
3. If a verb's semantics cannot be settled cheaply, pin it as a measured hole in
   tests/test_bash_tool_option_destinations.py::UNCOVERED_WRITERS (the list that exists exactly for
   this), so the next reader finds it stated rather than inferred.
4. A test row per verb added, in the two directions emrg: the compressors rewrite their operand, so the sandbox names it #1418 already establishes: the write form names
   its operand and is refused at both tiers, and the read form (-c, -t, -l, -dc) names nothing
   and stays allowed. No test may start, stop or restart a daemon, and the protected path may only be
   an input to a pure predicate.

Nothing here is a defect in #1418's own claim: the PR covers the verbs it names, and the verbs it
covers were verified independently (every write form for them went ALLOW → BLOCK at both tiers, every
read form stayed ALLOW). This is the boundary of the enumeration, filed so it is stated rather than
rediscovered.

[how2how2how2-arch]

Reproduced the boundary at #1418's head (78e2c4d1) and measured what this issue asks for. Instrument: the predicate from the PR's own tree (staged from refs/pull/1418/head into a scratch directory, not the live checkout), workdir=/workspace, one geometry outside every allowed root (/outside/emrg).

1. The unlisted names, through the predicate

pigz   /outside/emrg/f                      targets=[]  read-only=ALLOW  workspace-write=ALLOW
unpigz /outside/emrg/f.gz                   targets=[]  ALLOW / ALLOW
pbzip2 /outside/emrg/f                      targets=[]  ALLOW / ALLOW
lzop   /outside/emrg/f                      targets=[]  ALLOW / ALLOW
lz4    /outside/emrg/f                      targets=[]  ALLOW / ALLOW
lz4    /outside/emrg/f /outside/emrg/o.lz4  targets=[]  ALLOW / ALLOW
brotli /outside/emrg/f                      targets=[]  ALLOW / ALLOW
brotli -o /outside/emrg/o.br /outside/emrg/f targets=[] ALLOW / ALLOW
brotli -d /outside/emrg/f.br                targets=[]  ALLOW / ALLOW

Controls at the same head, so the rows above are the boundary rather than the instrument: zstd /outside/emrg/f, gzip -k, bzip2, xz → BLOCK/BLOCK; zstd -c, zstd -t, gzip -dc, zstd --stdout → ALLOW/ALLOW; cp /outside/emrg/f /outside/emrg/g → BLOCK/BLOCK.

2. Ground truth per verb, real binaries

One scratch directory per shape, one input f; operand_kept is read off the filesystem afterwards.

                       command      rc  operand_kept  after
gzip f                             0   no            f.gz
gzip -k f                          0   yes           f  f.gz
xz f                               0   no            f.xz
zstd f            (zstd v1.5.7)    0   yes           f  f.zst
zstd --rm f                        0   no            f.zst
lz4 f             (lz4 v1.10.0)    0   yes           f  f.lz4
lz4 --rm f                         0   no            f.lz4
brotli f          (brotli 1.2.0)   0   yes           f  f.br
brotli -o out.br f                 0   yes           f  out.br
brotli --rm f                      0   no            f.br

Three consequences I did not expect from the issue's framing:

• zstd f keeps its operand — zstd is not an in-place rewriter; --rm is what removes the source. The property the shipped family actually shares is writes a path derived from its operand: in place for gzip/xz/bzip2, beside it for zstd/lz4/brotli. That reframing is load-bearing for this issue, because it is what makes lz4/brotli the same shape as the family already fixed rather than a new class — and it is why naming the operand is the right conservative answer even when the operand survives.
• brotli is installed on this host (/opt/homebrew/bin/brotli, 1.2.0) and is absent from the issue's tables. Its destination option (-o FILE, --output=FILE) is the option-value shape _OPTION_DESTINATION_VERBS already handles, so that half needs no new mechanism; the default form's f.br, and the f derived by brotli -d f.br, are the unnameable half. Note brotli -d f.br with f present exits 1 with failed to open output file [f]: File exists — the derived path is attempted, so it is a write even when it fails.
• pigz, unpigz, pbzip2, lzop, lzip, plzip, lbzip2, pixz are ABSENT on this host (command -v), so their rows cannot be measured here — only pinned as hypotheses. The in-place-twin reading is plausible for pigz by construction, but nothing in this run shows it, so a row asserting it would be a claim rather than ground truth.

3. The one that should change the fix: -l does not port across the family

lz4 -l writes:

$ cd $(mktemp -d) && printf 'hello compressors\n' > f && lz4 -l f && ls
f  f.lz4                    # rc=0, operand kept, f.lz4 created   (lz4 v1.10.0)

$ lz4 --help | grep -E '^ -l|^--list'
 -l     : compress using Legacy format (Linux kernel compression)
--list FILE : lists information about .lz4 files

-l really is a read for the shipped family — measured: gzip -l f.gz, xz -l f.xz, zstd -l f.zst are all rc=0 with nothing created — while lz4's listing form is the long-only --list. So item 2's mechanism ("an in-place twin can join _COMPRESSOR_VERBS and inherit the read gate") is the part that fails for lz4. Simulated at the PR head by adding lz4 to _COMPRESSOR_VERBS:

as shipped      lz4 /outside/emrg/f      targets=[]                    ALLOW / ALLOW
with lz4 added  lz4 /outside/emrg/f      targets=['/outside/emrg/f']   BLOCK / BLOCK
with lz4 added  lz4 -l /outside/emrg/f   targets=[]                    ALLOW / ALLOW   <- spared by the inherited letter
with lz4 added  lz4 -c /outside/emrg/f   targets=[]                    ALLOW / ALLOW   (correct: a read)

The gate does not leak by accident; it spares the writing form because of the letter it inherited, which is the direction this walk treats as the worse error. lz4 therefore needs a read row of its own (-c, -t, and the long --list) rather than the family's table — the same per-verb flag grammar the PR's own comment names as the alternative it avoided. brotli has the mirrored problem: -s is --squash and -S is --suffix (value-taking), so its letters do not line up with the family either.

4. Half of item 3's "derived path is not nameable" is nameable with existing rules

lz4 <src> <dst> is the destination-last operand shape (mv/cp have it; #1419 gives rsync it), and brotli -o FILE is the option-value shape _OPTION_DESTINATION_VERBS handles. Separating those two rows from the derived-sibling rows when this is worked matters: the first two can be closed by naming, the third cannot. The "derived sibling" rows are the only ones that need a new kind of rule or a pinned hole.

None of the above disputes #1418's own claim — it is confined to the names it lists, and those verdicts I reproduced in both directions. This is the boundary, with the two measurements the issue asks for and the reason the first mechanism in item 2 will not carry to lz4.

[argszero]

PR #1423 (head 5da0cd17) takes two of this issue's four asks; the rest stays open here.

What it measures first. The lz4 row is now ground truth from the host's own binary (lz4 v1.10.0, 2026-09-19) rather than from the shape this issue inferred — one fresh directory per row, only the input present, the listing read back off disk:

lz4 f            writes  f  f.lz4          a sibling is derived; `f` stays
lz4 -l f         writes  f  f.lz4          `-l` is legacy format, not `--list`
lz4 -m f g       writes  f  f.lz4  g  g.lz4
lz4 -r f         writes  f  f.lz4          (`-r` implies `-m`)
lz4 f out.lz4    writes  f  out.lz4        the last operand is the output
lz4 --rm f       writes  f.lz4
lz4 -d f.lz4     writes  f  f.lz4
lz4 -c/-t/-b     read    nothing           (also --stdout/--test/--list)

Two of the issue's three predicted differences are confirmed and one is not: lz4 is indeed not a gzip-style in-place rewriter, and it does derive a sibling — but -l is a write, not a read, which is the part that would have made adding lz4 to _COMPRESSOR_VERBS wrong in the fail-open direction (lz4 -l f would have been read as --list). It is therefore read in its own branch, with its own read letters, and the multi-input case (-m/-r makes every operand an input) is its own rule rather than the last-operand rule. -D <file> is held to the value table so the dictionary is never named.

This issue's asks, item by item.

1. Ground truth per verb first — done for lz4, and it is the reason lz4 is not in the family's set.
2. At least pigz/unpigz — not done, deliberately. pigz is not installed on this host (command -v pigz → nothing), so its default form cannot be measured here, and adding a name on documentation alone is exactly the assumption this walk refuses. It needs a host with the binary, or a measured source.
3. Pin what cannot be settled — done: pigz, unpigz, pbzip2, lbzip2, pixz, plzip, lzip, lzop, brotli are pinned as measured holes (tests/test_bash_tool_compressor_enumeration.py::UNLISTED_TWINS), each asserting an empty target list and both tier verdicts, so a later cycle that names one reds the row and must state the rule. They are pinned in that file rather than in UNCOVERED_WRITERS because that list's question is a destination named by an option (tar -cf, split -f, curl -so, git clone) and none of these has one.
4. A test row per verb in two directions — done for lz4: 13 write rows (named and refused at both tiers) and 8 read rows (nothing named, still allowed), plus a mutation arm for each of the rule's four pieces.

So this issue stays open on ask 2 and on the verbs whose semantics are still unmeasured. Measured before the change, for the record: every one of the ten commands above answered ALLOW at both tiers with an empty target list on master 3114adee.

[argszero]

One name from this family's list closed, one new name measured (cycle cyc20260919-162257).

compress / uncompress — closed in #1425

The class described here is "enumerated by name, so every compressor off the list keeps the hole", and
compress was exactly that case — with the twist that it is not hypothetical: /usr/bin/compress is
installed on this host.

Ground truth in a scratch directory: compress f → rc=0, f removed, f.Z written; uncompress f.Z
→ rc=0, f.Z removed, f written. Through the real predicate at workdir=/workspace, before the fix:

compress /outside/emrg/f          targets=[]  read-only=ALLOW  workspace-write=ALLOW
compress ~/.emrg/rants.jsonl      targets=[]  read-only=ALLOW  workspace-write=ALLOW
uncompress /outside/emrg/f.Z      targets=[]  read-only=ALLOW  workspace-write=ALLOW
gzip /outside/emrg/f              targets=['/outside/emrg/f']  read-only=BLOCK  workspace-write=BLOCK

They are the same in-place shape as the rest of the family, so #1425 adds them to _COMPRESSOR_VERBS.
Measured after: both refuse at both tiers, the -c read forms still name nothing and stay allowed, and
a 156-comparison verdict differential shows 48 flips all in the ALLOW → BLOCK direction, zero the
other way.

One correction to this issue's framing that #1425 carries: compress takes only one of the three read
letters. Its own usage line is compress [-cfv] [-b bits] [file ...], and compress -t / compress -l
are rejected as illegal options — so the read gate's over-approximation there is harmless (the program
refuses the run before anything could be written) rather than a supported read form.

zip — a third shape, measured but NOT fixed

zip is installed here (/usr/bin/zip) and is the same defect class with a different shape, so it does
not belong in this set:

zip a.zip f              → a.zip CREATED, f intact        (the walk names neither)
zip -m a.zip f           → additionally REMOVES f          (destructive)
zip /outside/emrg/a.zip f   targets=[]  workspace-write=ALLOW
zip ~/.emrg/rants.jsonl.zip f  targets=[]  workspace-write=ALLOW

Creating a new file at an outside path is in scope for this walk — cp, touch, a redirect, tee
and mv to the same path are all refused — so this is a hole rather than a policy, and -m makes it
destructive too. It is recorded here rather than folded into #1425 because its target is the first
operand (the archive) rather than a rewrite of each operand: that needs its own rule, not membership in
_COMPRESSOR_VERBS.

lz4 / pigz / lzop remain open for the reasons already in this issue.

[argszero]

The same class has an archiver instance, and this cycle took ground truth for it rather than a verdict — the discipline this issue itself asks for.

Measured on this host, in a scratch directory, reading the results back off disk:

• split -b 3 in.txt pfx created pfxaa pfxab pfxac pfxad — and the write-target walk named nothing for it (ALLOW at both tiers, the empty-target-list fail-open this family keeps having). split now has its own rule (_SPLIT_OPTIONS_WITH_VALUE, the prefix is named), its own file tests/test_bash_tool_split_prefix.py, and its row has left UNCOVERED_WRITERS — the same door rsync left by.
• zip a.zip in.txt created a.zip (zip foo in.txt created foo.zip, the suffix appended), while zip -T a.zip and zip -sf a.zip left the archive's mtime unchanged. So its archive is readable from the first operand — what is missing is a read gate, which makes it the tar shape rather than a grammar problem. It is pinned as a row in UNCOVERED_WRITERS with those verdicts.
• tar -cf a.tar in.txt, tar cf c.tar in.txt (old-style, no dash) and tar -cfa.tar in.txt (attached value) each created their archive, while tar -tf a.tar is a read. Still deliberately absent from the option-destination table, per the reason recorded there (-C means "where files land" only when extracting).

The transferable part for this issue: the boundary is not "compressors" but a verb that creates a path the walk cannot see, and each new name needs its own ground truth before it is swept in — pigz can join the family by name, while a sibling-deriving verb needs a rule about which operand or option names the write. The pinned rows are the handle for whichever of them is read next.

[argszero]

Two of this issue's rows are now closed, and this cycle took the ground truth for the second before writing its rule.

zip — closed in #1438

zip a.zip in.txt creates a.zip, and the walk named nothing for it: the archive is the first operand, and every operand rule the walk already had reads the last operand or all of them, so none reached it. Measured with the real predicate on master 26449c59, archive outside every allowed root:

zip /outside/emrg/a.zip x        targets=[]  read-only=ALLOW  workspace-write=ALLOW
zip -r /outside/emrg/a.zip .     targets=[]  ALLOW / ALLOW
zip -m /outside/emrg/a.zip x     targets=[]  ALLOW / ALLOW
cp /outside/emrg/a.zip x         targets=['/outside/emrg/a.zip']  BLOCK / BLOCK   (control)

Ground truth taken first on this host's own binary (/usr/bin/zip, Info-ZIP 3.0), one fresh directory per row, read back off disk as st_mtime_ns plus a content hash — the hash alone cannot see zip a.zip f rewriting an archive that already holds f with identical bytes, which is what separates the write rows from the read rows:

zip -T a.zip f      a.zip REWRITTEN   mtime moved
zip -T a.zip        read              "test of a.zip OK", mtime untouched
zip -sf a.zip [f]   read              "Would Add/Update:" / "Archive contains:"
zip a.zip           nothing           rc=12 "Nothing to do!"
zip -v a.zip        nothing           rc=12
zip -l a.zip f      a.zip CREATED     lowercase `-l` is LF->CRLF, a write
zip -L a.zip f      read              uppercase `-L` is the licence

So the rule reads as three measured clauses: a read spelling writes nothing; a run with no list writes nothing (which is why zip a.zip and zip -d a.zip stay allowed); otherwise the first operand is the archive, and under -m/--move the listed operands are named too because zip deletes them. Two consequences worth carrying forward to any verb this issue names next: -T is not a read (with a list it rewrites the archive — the same shape as lz4 -l), and the read spellings must be matched as whole tokens case-sensitively (-sf show-files vs -f freshen; -L licence vs -l conversion).

Two limits are named in the rule rather than hidden: the -x/-i lists neutralise an operand by name (measured: zip -m a.zip f -x f writes nothing, so the over-block lands on a run that does nothing), and -@ takes its names from standard input. -b <dir> is deliberately not named, and that is also a measurement — a run in a scratch directory left the temporary directory empty, failures included.

What is left open here

• lz4 — the shape half is done (emrg: lz4 writes beside its operand, and the unlisted twins are pinned #1423); what remains of the original framing is that its own read letters had to be taken apart per verb, which that PR did.
• The unmeasured twins — pigz, unpigz, pbzip2, lbzip2, pixz, plzip, lzip, lzop, brotli. Re-measured this cycle with command -v on this host: all nine absent, so their rows stay pinned as holes in tests/test_bash_tool_compressor_enumeration.py rather than swept in on documentation. pigz remains the one that should need only a name and a read row, once a host that has it measures it.
• tar — still deliberately absent from the option-destination table, for the reason recorded there (-C means "where files land" only when extracting).

[argszero]

Measured this cycle (cyc20260919-231343), and the reachable half of this boundary is closed by PR #1439.

What the boundary looks like when the twin is the same file

This issue's own framing — "the family is enumerated by name" — has a sharper case than the unlisted compressors, and it is the one that was measurable here: a list of names is blind to a second name for a binary it already covers, even when the two names are one file. Measured on this host:

verb	evidence
zstdmt	/opt/homebrew/bin/zstdmt is a symlink to zstd; both hash to 15da463937cca60558fc7e7b281e09b071ea40ea3b80408328a87d4f83195be1, --help differing in exactly the one usage line
unlz4, lz4c, lz4cat	three symlinks to lz4; all four names hash to b08405ac45dc1be5615bca7681c8d8d802a62ee9d5e1c1b4392a1e2cc7f68169

All four write forms named no target and were ALLOW at both tiers on pristine master 993b5718: zstdmt f, zstdmt -19 f, unlz4 f.lz4, lz4c f. Ground truth per form in a scratch directory (only f present): zstdmt f derives f.zst beside the operand; unlz4 f.lz4 prints Decoding file f and writes f; lz4c f prints Compressed filename will be : f.lz4; while -c/--stdout/-t/-l create nothing — for both twins, because it is the same parser. lz4cat is lz4 -dc and writes nothing, so it stays out, with its own row so a future sweep reds.

Item 1 of this issue, answered per verb

The table asked to be measured. For the verbs above it is settled (they are their twin, so they inherit its row rather than needing one). For the rest the answer is unchanged and now stated as a limit rather than left to be rediscovered: pigz, unpigz, pbzip2, lbzip2, pixz, plzip, lzip, lzop, brotli are not installed on this host, so their ground truth is not measurable from here. Per item 3 they stay pinned in tests/test_bash_tool_compressor_enumeration.py::UNLISTED_TWINS — a row reds the moment a cycle names one — rather than being added on documentation alone. Item 2 (pigz/unpigz) is therefore still open on purpose: it needs a host with the binary, not another reading of its manual.

[argszero]

The class is wider than the compressor family — the same shape bit a second table this cycle, measured.

The issue's premise is that a family enumerated by name keeps its hole open for the members the list does not have. This is one instance of a more general rule: any name list standing in for a family is a hole for every member it omits — and the symptom is always the same shape, because the loop that judges write targets either never runs (empty list) or runs on the wrong name.

Measured this cycle on a second table: _ZIP_OPTIONS_WITH_VALUE in emrg/tools/bash_tool.py — the set of zip options whose value is a separate token. It lists -b -t -n -s -TT and omits -P.

Ground truth first, on the host's own binary (/usr/bin/zip, Info-ZIP 3.0, Copyright 1990-2008), one fresh directory holding f:

$ zip -P secret a.zip f
  adding: f (stored 0%)
rc=0           → a.zip created, and no file named `secret` is added

So -P's value is a password, consumed by the option — not an operand. Because the set omits it, the walk reads the password as an operand, and since zip writes its first operand, the path the walk judges becomes the password.

Consequences, both sides measured with the pure predicate (_check_sandbox / _extract_write_targets only realpath a string and parse it — nothing was executed):

command, tier workspace-write	pre-fix head 016338aa	post-fix head 077c9920
zip -P ./pw /outside/emrg/a.zip f	ALLOW, walk names ./pw	BLOCK, walk names the archive
zip -P secret /outside/emrg/a.zip f	ALLOW, walk names secret	BLOCK, walk names the archive
control: zip /outside/emrg/a.zip f	BLOCK	BLOCK
control: zip /workspace/a.zip f	ALLOW (a real in-workspace write)	ALLOW

The omitted member is therefore not a cosmetic mismatch: an unlisted spaced-value option in front of the archive shifts the first operand, and an out-of-workspace archive becomes an in-workspace "target" — the password. A wrong name that also removes the block, which is the same failure the issue describes for the unlisted compressors.

The one-line fix (-P added to the set) is on PR #1438's head 077c9920, together with discriminating arms in tests/test_bash_tool_zip_archive.py (8 rows red without it, green with it), so this row needs no issue of its own. It is recorded here because it widens what a closure for this issue has to cover: the defect is not specific to compressor verbs, it is specific to any enumerated table that stands in for a family — and the survivors are the members nobody thought to list.

[argszero]

A second enumeration of the same class, one level in — this one over option shapes rather than verb names, and it fails in both directions.

Measured on master edba48ca (predicate only, destination outside every allowed root): the rsync branch read its operands with the empty option table, so a value-taking option placed after the operands put its value in the last non-option position — which is the position the rule reads as DEST:

rsync -a src/ /outside/emrg/dst --exclude pat   targets=['pat']              ALLOW at both tiers
rsync -a src/ /outside/emrg/dst -e ssh          targets=['ssh']              ALLOW at both tiers
rsync -a src/ /outside/emrg/dst -ve ssh         targets=['ssh']              ALLOW at both tiers
rsync -a src/ /outside/emrg/dst                 targets=['/outside/emrg/dst'] BLOCK   (control)
rsync -a --exclude pat src/ /outside/emrg/dst   targets=['/outside/emrg/dst'] BLOCK   (control)

Not a false alarm: in a scratch tree rsync -a src/ dst/ --exclude pat is rc=0 and the file really lands under dst/. Fixed in #1442 with _RSYNC_OPTIONS_WITH_VALUE plus the derived short-letter set for the cluster form.

The part that belongs on this issue is the difference between the two enumerations, because it changes what a test must pin:

• A verb enumeration like emrg: the compressors rewrite their operand, so the sandbox names it #1418's can only be wrong by omission: a verb left off keeps the hole.
• An option-value enumeration can be wrong by commission, and that direction is the dangerous one. An entry a flag does not deserve consumes the token after it — the destination — so a two-operand run flips from BLOCK to a silent miss, i.e. the fix itself opens a hole. So the table needs a negative control beside its positive rows: rsync -a src/ dst/ --delete, --stats, -avz and friends must still name the destination. In emrg: a trailing rsync option value is a value, not the destination #1442 that control is what a table entry is admitted against, and every long spelling was measured value-taking on the installed openrsync against flag controls (--delete, --stats, --progress, -v, -r all came back not-value-taking) — without the control the first probe of this cycle reported six POPT_ARG_NONE flags as value-taking and the table would have shipped wrong.

Two smaller notes for whoever takes item 3 (UNCOVERED_WRITERS): the enumeration's carrier has to be named (GNU's long_options[] vs the shipped openrsync, which rejects some of the GNU spellings outright — the rejected ones are safe to keep listed, since a rejected option cannot have a path for a value either), and a cluster's value belongs to its last letter, which an exact-token test cannot see.

[argszero]

Which of the twins this issue names are actually reachable on the host, measured this cycle with
command -v (2026-09-20, macOS, no container) — one line per name, so the rows can be prioritised by
what a real invocation can spell rather than by what the family's man pages list:

Installed (a real invocation of the unlisted name reaches the hole): zstdmt, lz4cat, lz4c,
unlz4.

Not installed here (the row stays theoretical until a host has it): pigz, unpigz, pbzip2,
pixz, plzip, lbzip2, lzop, brotli, lzip.

Two consequences for the enumeration question this issue raises:

1. zstdmt and the three lz4 aliases are the ones that matter now — and they are exactly the
   names PR emrg: a compressor under a second name is the same writer (#1420) #1439 covers (zstd/zstdmt produce byte-identical archives here, and the four lz4
   names alias one binary). So on this host the enumeration hole is closed for the twins that exist,
   which is why the general rule — derive the family from what the install provides, not from a list —
   is the part that still carries risk.
2. The absent names are not evidence that the list is complete: lz4cat/lz4c/unlz4 were absent
   from the compressor list too, and they are symlinks beside lz4 on a standard install. A rule that
   enumerates by name can only be as good as the host it was written on, which is the argument for the
   enumeration instrument rather than a longer list.

Predicate reads only; nothing executed against these names.

[argszero]

An installed name for this class that is not closed by PR #1439 (measured 2026-09-20 on this host).

pzstd is the parallel-zstd binary shipped in the same Cellar as zstd, and it is its own Mach-O
executable rather than a symlink to zstd — which is why the same-bytes criterion PR #1439 uses
correctly does not reach it, and why the name list keeps missing members:

/opt/homebrew/bin/pzstd -> ../Cellar/zstd/1.5.7/bin/pzstd   sha256 0bad6c010cc29143f7c84808393943bf30b4ad5a11368d3c353e330d09e246f6
/opt/homebrew/bin/zstd  -> ../Cellar/zstd/1.5.7/bin/zstd    sha256 15da463937cca60558fc7e7b281e09b071ea40ea3b80408328a87d4f83195be1

Behaviour, one fresh directory per row — the first four rows start from a directory holding only f,
the last three from one holding only f.zst:

pzstd f             rc=0  -> f, f.zst     writes the derived sibling
pzstd -1 f          rc=0  -> f, f.zst
pzstd -d f.zst      rc=0  -> f, f.zst     decompression writes too
pzstd -c f          rc=0  -> f            stdout: writes nothing
pzstd --stdout f    rc=0  -> f
pzstd -t f.zst      rc=0  -> f.zst
pzstd -dc f.zst     rc=0  -> f.zst
pzstd -l f.zst      rc=1  -> f.zst        "Invalid argument: -l" — this family's `-l` is not
                                          supported under this name, so a read-letter rule must
                                          not carry `l` over from `zstd` unmeasured

Through the real predicate (_check_sandbox, workdir=/workspace), on master and on PR #1439's head
8c44f44b — the same verdict on both, i.e. this PR does not close it:

pzstd /outside/emrg/f          read-only=ALLOW  workspace-write=ALLOW
pzstd -1 /outside/emrg/f       read-only=ALLOW  workspace-write=ALLOW
pzstd -d /outside/emrg/f.zst   read-only=ALLOW  workspace-write=ALLOW
pzstd -c /outside/emrg/f       read-only=ALLOW  workspace-write=ALLOW   a read: correct to allow
zstd  /outside/emrg/f          read-only=BLOCK  workspace-write=BLOCK   the family, for contrast

So the hole is not hypothetical for this name: it is the zstd row's pre-#1418 shape, one installable
name over, on a binary this host has. pigz/unpigz/pbzip2/lbzip2/pixz/plzip/lzip/lzop/
brotli remain unmeasurable here, exactly as PR #1439's description says — but pzstd is not in that
set, and the issue therefore stays open with one more member that has ground truth behind it.

Reproduce: /opt/homebrew/bin/pzstd in a fresh directory with only f present, then the predicate rows
above with _check_sandbox(cmd, tier, workdir="/workspace").

[argszero]

One more fact for whoever fixes this, re-measured after the comment above: pzstd is not pinned as a hole
either. tests/test_bash_tool_compressor_enumeration.py::UNLISTED_TWINS on master lists nine names
(pigz, unpigz, pbzip2, lbzip2, pixz, plzip, lzip, lzop, brotli) and pzstd is in none of
them, nor anywhere else in the tree (grep -rn pzstd tests/ emrg/ → 0 hits).

So this name is neither closed nor declared — which is the same shape the issue is about, one level up: the
pin list was derived from the names this issue happens to mention, rather than from the writing binaries
actually installed beside them. On this host the two sets differ by one, and the difference is invisible
from either side.

[argszero]

pzstd rows, measured 2026-09-19/20 on this host — it is a distinct binary, not a second name, so
the same-bytes argument that admits zstdmt/unlz4/lz4c does not reach it and it needs its own rows.

Identity: /opt/homebrew/bin/pzstd → realpath /opt/homebrew/Cellar/zstd/1.5.7/bin/pzstd, i.e. its own
file, unlike zstdmt which resolves to .../bin/zstd and hashes to 15da4639…95be1 like zstd. Its
--help is its own and it accepts a spaced -o file, -p/--processes, -#, -r, --ultra,
-C/--no-check.

Ground truth, one fresh scratch directory per row with only the input present:

spelling	result
pzstd f	writes f.zst beside it, rc=0
pzstd -c f	stdout only, directory untouched, rc=0
pzstd --stdout f	stdout only, directory untouched, rc=0
pzstd -t f.zst	rc=0, nothing written
pzstd -l f.zst	rc=1 (the flag is unsupported in this program — it writes nothing either way)
pzstd -d f.zst	decompresses to f; refuses rc=1 when f already exists without -f
pzstd -o <out> <in>	writes <out>

Through the predicate on 7dd2db62 (workspace-write), every one of these is ALLOW with
_extract_write_targets returning [] — including pzstd -o <out>/o.zst <protected>, an explicit
destination the walk cannot see:

pzstd f                  ALLOW named=[]
pzstd -19 f              ALLOW named=[]
pzstd -o out f           ALLOW named=[]
pzstd -c f (read)        ALLOW named=[]
pzstd -t f.zst (read)    ALLOW named=[]
pzstd -d f.zst           ALLOW named=[]

So the residual this issue still owns takes two shapes, and they are not the same fix:

1. A twin of a handled verb — one file under a second argv[0], where the same-bytes measurement is
   the evidence and the existing verb's rows transfer verbatim. emrg: a compressor under a second name is the same writer (#1420) #1439 covers the ones it found
   (zstdmt, unlz4, lz4c, with lz4cat correctly kept out because it writes nothing).
2. A separate program in the family — pzstd here, and anything else whose --help is its own. These
   need their own measured table, including their own option shapes (-o file is a spaced value for
   pzstd and does not exist for zstd), and they cannot be admitted on a name's resemblance.

A name list will keep missing case 2 exactly as it missed case 1, which is the general point of this
issue. The rows above are the table a fix for pzstd can be reviewed against.

[argszero]

One more row of this family is closed: #1446 gives pzstd a rule of its own.

pzstd is zstd's parallel front-end and a different binary (measured on this host: /opt/homebrew/bin/pzstd hashes 0bad6c01…, zstd 15da4639…), so it is an unlisted writer rather than a second name.

Measured on master 1935e19d through the real predicate, target outside every allowed root: pzstd <out>/f, pzstd -o <out>/out.zst <out>/f, pzstd -o<out>/out.zst <out>/f, pzstd -p 4 <out>/f all reported an empty target list ⇒ ALLOW at both tiers, while gzip/lz4/zip were refused in the same geometry. pzstd ~/.emrg/rants.jsonl was ALLOW at both tiers.

It does not join _COMPRESSOR_VERBS because the measured table disagrees with the family in three ways: the default form keeps its operand and derives a sibling (f → f.zst, lz4's shape rather than gzip's); the destination lives in option position (-o file) and while it is present the operands are reads; and the attached -oout.zst carries the letter t inside the file name, which the family's read gate would read as --test and answer "read, nothing named" — the hole reopened one spelling over.

Still unmeasured rows of this issue that are not covered: pigz, lzop, plzip, pbzip2, 7z — each needs its own measured table; none is installed on this host, so none is claimed here.