config_digest pins the launch target's spelling, not its bytes: a project-local binary/launch_args is rewritable in place

[pbean]

Split out of #461 point 4 / PR #495, where a reviewer found that config_digest pins the launch target's spelling and nothing verifies its bytes. Sibling of #499 — same fix surface (validate-level confinement on binary), different mechanism: #499 is an unpinned hard-coded token (serve) under the hookless transport, this is a pinned pointer to mutable content under the ordinary hooked transport.

The hole

config_digest hashes binary and launch_args as strings. For a project-local launch target — binary a path into the tree, or binary = "python" with the real program in launch_args — a driven session rewrites the referenced file in place. No config field moves, the digest matches, and the unattended child sweep launches the replacement in the host process.

Nothing forbids or flags the shape today:

• adapters/profile.py:146-148 requires only a non-empty string for binary; launch_args gets str_list and no path check.
• The three sibling path fields in the same parser are all containment-guarded — hooks.config_path (profile.py:165-170), skill_tree (profile.py:195-196), seed_files (profile.py:203-205) each reject absolute paths and parent refs. The two fields naming the program actually executed are the ones left out.
• validate's check is shutil.which(p.binary) (cli.py:414-418), which accepts a path happily. probe-adapter already does Path(profile.binary).name (cli.py:2891), i.e. the code tolerates a path-shaped binary by design.

Why the sweep child is genuinely exposed

The obvious dismissal — "the parent loop re-execs the same target every session anyway, so this buys the attacker nothing" — is false for the triage role:

• ROLES = ("dev", "review", "triage") (runsetup.py:81) and all three adapters are built for every run.
• Base Engine.__init__ wires only dev+review (engine.py:272-275). sweep.py:391 holds the only adapters["triage"] assignment, and sweep.py:739/855 the only two role="triage" dispatches.
• [adapter.triage] may name a different profile (policy.py:373, documented in data/settings/core.toml).

So a [adapter.triage] override's launch target is exec'd by a sweep and by nothing else. Two further shapes where no parent session follows the child: sweep.auto = "run-end" fires when _pick_next() returns None (engine.py:773-775), and under isolation = "worktree" parent sessions run at the worktree root while triage runs at the main checkout.

Why a wider hash is the wrong instrument

Content-hashing the launch target would catch the in-place edit — this is not the skill_tree "cheaper route" argument. It fails for different reasons:

1. The target is not identifiable. Which launch_args token names a file is undecidable (-i vs tools/agent.py); you would be stat-ing argv tokens heuristically.
2. Digest-time resolution is not launch-time resolution. The digest runs in the orchestrator's Python process; the exec happens in a tmux shell with its own PATH.
3. One indirection defeats it. This repo's own tests/conftest.py:60-76 write_script_launcher writes a stub that execs sys.executable on a sidecar .py. Hashing the stub misses the payload — exactly the under-catch a lexical rule has.
4. The target is usually not ours to pin. It is normally a third-party CLI on PATH that self-updates. A mid-run update would move a content hash and burn the auto-sweep trigger for the life of the run: _maybe_auto_sweep appends to sweeps_triggered and _save()s at engine.py:5097, before calling the factory at 5110, with an early return at 5086.

Why the reviewer's second remedy does not decide it either

"Reject launch targets that resolve inside the writable project" is refuted as worded — a bare command name can resolve inside the project. Measured in this repo under an active venv:

PATH[0]: /home/pinkyd/dev/bmad-automator2/.venv/bin
python  -> /home/pinkyd/dev/bmad-automator2/.venv/bin/python

So a lexical rule (reject path-shaped binary) under-catches, and a resolve-and-contain rule is environment-dependent, must run at launch rather than parse, and would reject a legitimate binary = "python" on any machine with a project venv or node_modules/.bin on PATH. Under isolation = "worktree" "the writable project" is ambiguous (main checkout and the linked worktree).

It would also break this repo's own zero-token E2E gates: tests/test_stories_e2e.py:324 sets binary to <sandbox>/.bmad-loop/fake-cli.sh, a project-local path beside the very policy.toml/profiles/ the digest polices (14 tests; plus path-binary adapter constructions in test_generic_tmux.py and test_opencode_http.py).

Scope

• Unreachable on stock config — all six shipped profiles use bare PATH names with no script path in launch_args.
• Requires a user-authored project-local profile. SECURITY.md puts "Command or path injection via configuration, profiles, or spawned coding-CLI / tmux sessions" in scope, but "Security issues in user-authored skills, plugins, profiles, or test/lint commands" out of scope, and best-practice docs(roadmap): TEA plugin shipped (experimental) #2 asks users to trust their profiles. This sits on that seam.

Fix space (not decided)

1. validate warning when the resolved binary (or a launch_args token that exists as a file) lands inside the project tree — cheap, non-breaking, honest, and useful to the user regardless of security. Same instrument opencode-http _serve_argv puts a cwd-relative "serve" at argv[1], so an interpreter binary executes a workspace file #499 settled on as its option 3, so the two should land together.
2. Containment guard at parse time, matching the three sibling path fields. Stricter, and would break the E2E scaffolds above as written (repairable by moving the fake CLI out of the project root).
3. Content-pin at enable time — the shape Enabled plugins are trusted by NAME, so a session can swap the module behind one #496 fix-option-2 proposes for plugins. Same objections as above (items 1-4); noted so nobody re-derives it.

Option 1 looks right, for #499's reason: the shape is unsanctioned rather than supported, and telling the human is more useful than a security-framed refusal.

Refs #461, #495, #499.

[coderabbitai]

🔗 Related PRs

#110 - fix(runs): validate run ids and stop a run ref escaping the runs dir [merged]
#214 - fix(probe): run the diagnose egress leak self-check; ship payload schema, not values (#199) [merged]
#298 - fix(adapters,engine): pin the read-back to the spec the session owes (#261) [merged]
#479 - fix(config): recover the stranded seed guards and TOML conversion funnels (#456) [merged]
#495 - fix(sweep): integrity-pin the agent-writable host-exec config across the auto-sweep re-read (#461 point 4) [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[pbean]

Note for whoever picks this up: this issue's fourth argument against a wider hash — "the target is
usually not ours to pin" — rests on a mechanism that #604 (closing #501) changes.

The argument as filed:

A mid-run update would move a content hash and burn the auto-sweep trigger for the life of the
run: _maybe_auto_sweep appends to sweeps_triggered and _save()s at engine.py:5097,
before calling the factory at 5110, with an early return at 5086.

Three corrections, none of which overturn the conclusion:

1. The cited mechanism is gone. sweeps_triggered is now appended only once the child sweep has
   actually started — the latch fires from compose_sweep's success boundary, via a required
   started thunk on the SweepFactory protocol. A digest refusal (which raises before composition)
   no longer spends the trigger at all. The line numbers have also moved; re-locate by symbol.

2. The conclusion survives anyway, for a different reason. An un-latched trigger is essentially
   never re-asked: run-end fires from _loop, whose return lands on finished = True, and
   cli._resume_paused_run refuses a finished run; per-epic fires from _epic_boundary, and
   current_epic advances within the same frame. So "burns the trigger for the life of the run"
   should now read as "refuses every trigger for the life of the run" — the same wrong answer
   refuses the next one too, and under [sweep] auto = "run-end" there is exactly one. A
   self-updating third-party CLI would still cost the run its deferred-work sweep.

3. The cost is no longer silent. A refusal is now recorded in RunState.sweeps_refused
   (trigger → not-started / failed / dirty) and surfaced by the end-of-run summary,
   bmad-loop status, status --json and bmad-loop diagnose. That does not make a content-pin
   affordable, but it does mean the over-refusal this issue predicts would be diagnosable rather
   than invisible — worth weighing if option 3 (content-pin at enable time) is ever reconsidered.

Option 1 (a validate-level warning) is untouched by any of this, and still looks like the right
instrument for the reasons this issue and #499 both give.