fix(tests): resolve the spawned CLI binary without guessing cargo layout

[chaliy]

What changed

The bounded-child harness now finds the bashkit CLI binary it spawns by walking
up from the test binary until the binary turns up, instead of assuming a fixed
depth, and fails closed naming every path it ruled out. No product code changes,
no workflow changes.

Why

Nightly run 252's AddressSanitizer job went red on
threat_model_tests::resource_exhaustion::indirect_hostile_cycles_rejected_in_bounded_child
with spawn bashkit CLI: Os { code: 2, kind: NotFound }, while required CI on
the same commits stayed green.

The harness runs hostile reproducers in a child CLI process by design
(TM-DOS-135: pre-fix they overflowed the stack and aborted the whole test
runner). It located that binary as the test binary's grandparent directory,
which holds only for the <profile>/deps/<test> layout of the pinned stable
toolchain. Cargo 1.101-nightly's separate build directory puts the test binary
at <profile>/build/<package>/<hash>/out/<test>, so the lookup resolved into a
hashed build directory and the five CLI-spawning regressions failed on a path
that never existed — NotFound before the launcher landed, exit 127 after —
rather than on the bounds they assert. A red nightly that said nothing about the
product, and a security regression that had stopped being exercised there.

Only the export of the final binary into the profile directory is contractual,
and that directory is an ancestor of the test binary under either layout, so
that is what the lookup relies on now.

Two things worth recording, both measured on cargo 1.101.0-nightly (29c5daa1a)
with -Z build-std --target x86_64-unknown-linux-gnu:

• --bins is not the mechanism, which is why this PR does not add it: on
  that toolchain it builds the binary only as a test harness inside the hashed
  build directory (build/<pkg>/<hash>/out/<name>-<hash>) and exports nothing
  runnable.
• What makes cargo export the binary is selecting the bashkit-cli package,
  whose own integration tests get CARGO_BIN_EXE_bashkit. Both the required CI
  job and the ASAN job already do that via --tests, so the binary was present
  all along — only unfindable.

Before / After

Reproducing on main with a selection narrow enough to exclude bashkit-cli
(the shape in which the path bug is visible on stable too):

$ cargo test -p bashkit --test integration indirect_hostile_cycles_rejected_in_bounded_child
assertion `left == right` failed
  left: Some(127)
 right: Some(1)
test result: FAILED. 0 passed; 1 failed

Exit 127 is the launcher's exec of a path that does not exist — nothing to do
with the hostile script under test. After, the same invocation names the cause
and every directory ruled out:

bashkit CLI binary not found above the test binary
/home/user/bashkit/target/debug/deps/integration-dcaeaea1ffc8c0c6: this suite
spawns it to run hostile reproducers out of process, so the test selection must
include the bashkit-cli package (its own integration tests are what make cargo
export the binary). Ruled out: /home/user/bashkit/target/debug/deps/bashkit,
/home/user/bashkit/target/debug/bashkit, /home/user/bashkit/target/bashkit

The nightly layout, measured directly in a minimal workspace on the nightly
toolchain, with the old fixed-depth guess and the new walk side by side:

CURRENT_EXE=.../target/x86_64-unknown-linux-gnu/debug/build/liba/25038115b7f663aa/out/probe-25038115b7f663aa
OLD_GUESS=.../debug/build/liba/25038115b7f663aa/binb         exists=false
ANCESTOR[4]=.../target/x86_64-unknown-linux-gnu/debug        has_bin=true

With the binary present, the harness module passes (the five CLI cases plus the
new layout case):

$ cargo test -p bashkit --test integration threat_model_tests::resource_exhaustion
test result: ok. 35 passed; 0 failed; 0 ignored; 0 measured; 1579 filtered out

Authoritative proof: the Nightly workflow is dispatched on this branch, so its
AddressSanitizer job reports against this head directly.

Other local checks: cargo fmt --check clean, cargo clippy -p bashkit --tests
clean, just check-okf conformant, just check-doc-links OK.

Risk

• Low. Test-harness and knowledge only; no product code, no CI configuration.
• A wrong binary would be worse than a failure, so the walk is contained three
  ways: it requires a regular file, so the package-named build/bashkit
  directory cannot be mistaken for the binary; it stops at cargo's target
  directory, recognised by its CACHEDIR.TAG, so a same-named file above the
  build tree is never spawned; and it is bounded to six ancestor levels (five
  are needed for the deepest known layout) whether or not that marker is
  present. Absence stays an error rather than a path that fails later.

Checklist

• Tests added or updated — cli_lookup_resolves_known_cargo_layouts covers
  both layouts over synthetic trees, since the live tree only ever has its
  own toolchain's layout, plus the directory collision, a decoy above the
  target directory, and the absent case
• Backward compatibility considered (internal test harness)

---

https://claude.ai/code/session_01AZCDWdi9DiWzZF5VmWdqXM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	d21fbc6	Commit Preview URL Branch Preview URL	Oct 11 2026, 10:22 PM