shim: guard PEERAGENT_BIN against self-exec loop (pointing at a shim)

[nklisch]

Problem

PEERAGENT_BIN is meant to override the resolved Go binary. If set to a shim copy (this script, or plugin/bin/peeragent), step 1 runs:

exec "$PEERAGENT_BIN" "$@"

→ the shim re-enters step 1 with the same env var → exec itself → infinite self-exec loop. It burns a core and never starts the agent. No error, no exit.

Spotted in the wild this session: an opus peer-review job reported "running" for 19 minutes while a bare sh process sat at 53% CPU with no child — the review never actually executed. Easy footgun: the natural but wrong instinct is PEERAGENT_BIN=$(which peeragent) pointing at the shim.

Fix

In step 1, if the PEERAGENT_BIN target's first two bytes are #! (a shell shim — the Go binaries start with ELF/Mach-O magic), fail fast with exit 2 and a clear message instead of spinning.

Catches pointing at any shim copy (root bin/ or plugin/bin/), not just the exact self path.

--text is detected inline because wants_text is defined later in the script and sh does not parse functions ahead (verified: calling a later-defined function from step 1 gives command not found).

Verified

Case	Result
PEERAGENT_BIN → shim itself (the bug)	exit 2, clear JSON error, no spin
PEERAGENT_BIN → other shim copy (plugin/bin/peeragent)	exit 2
PEERAGENT_BIN → real Go binary	unaffected, execs normally
PEERAGENT_BIN unset → auto-detect	unaffected
--text mode	human-readable message
no args	guard fires correctly under set -eu

Test

Added a "shim PEERAGENT_BIN self-exec-loop guard" step to scripts/validate.sh — runs the guarded path under timeout 3 so a regression (guard removed/broken) hangs and fails the suite rather than passing by luck. Asserts process exit 2 (set by the shim itself, independent of the Go binary's exit-code semantics) and the self-exec loop message.

plugin/bin/peeragent re-synced from bin/peeragent via package-plugin.sh.

Out of scope (flagged, not fixed here)

The pre-existing "shim smoke" step asserts process exit 4 for --status missing-job, but on this build the Go binary's process exit is 1 (the exit_code:4 lives only in the JSON metadata). That step appears already red on clean upstream, unrelated to this change. Worth a separate look at how the Go binary maps failure status → process exit code.