Harness: post-bridge hardening (merge-agent isolation, doctor version check, per-ref provenance)

[marcusrbrown]

Follow-up items deferred from the integrate→build bridge work (#774). None block a first patched release; each is a contained hardening improvement.

1. Isolate the LLM merge agent from the auth secret and redact failure output

The integrate job runs opencode run with model credentials provisioned to a 0600 file. The credential is never echoed and the job is read-only (no id-token, no push), but the autonomous merge agent and its tools can read the filesystem, including the auth path, and a raw failure message could in principle surface command output.

• Run the merge under a restrictive permissions/sandbox policy so spawned tools cannot read the credential path or reach the network outside the merge repo.
• Add a single-line, length-capped, secret-redacting error formatter for integrate/opencode failures instead of printing raw Error.message.

2. harness doctor version check is stale relative to the +harness.<sha> scheme

cmdDoctor compares a built binary --version against the bare base version (e.g. 1.15.13), but built harness binaries now self-report <baseVersion>+harness.<shortSha> via buildHarnessVersion(). For a genuinely built artifact this equality check fails. cmdDoctor is not on the release path (the build path uses verify-binary.ts, which expects the +harness.<sha> form), so this is latent, not a regression — but the new version scheme makes it reachable.

• Update cmdDoctor to accept the +harness.<shortSha> version form.

3. Per-ref provenance collapses to the integration commit

runIntegration sets every ref's resolvedSha to the shared integration commit. The provenance manifest therefore cannot record the actual upstream SHA each ref resolved to. Acceptable under the current 1–3 ref carry policy, but it weakens per-ref auditability.

• Resolve and record each ref's actual upstream SHA in the provenance manifest.

Optional test additions (from review)

• Assert the produced artifact contains no .git directory (the clean-snapshot guarantee underpins the handoff).
• Assert --source-tree pointing at a non-empty non-git directory builds without invoking the clone path.

[fro-bot]

Triage: post-bridge hardening (#775)

Follow-up hardening from the integrate→build bridge (#774, merged). All three items confirmed against the current main source — each is a latent/auditability improvement, none is a release blocker.

Summary of findings (verified in code)

1. Merge agent isolation + redacted failure output — valid

• The LLM merge runs opencode run with no permission/sandbox restriction: execFileAsync(opencodeBin, ['run', '--agent', agent, '--model', model, prompt], …) at packages/harness/src/integrate.ts:206. The autonomous agent's tools can read the filesystem (incl. the 0600 auth file written by the workflow at harness-release.yaml:108-109).
• Mitigations already in place: job is read-only (contents: read, no id-token), secret is never echoed, JSON-validated before use (harness-release.yaml:99-124).
• Gap A — no sandboxing: runMerge passes no --agent-scoped permission policy or network restriction, so spawned tools could in principle read the credential path. Recommend running the merge under a restrictive OpenCode permissions config (deny filesystem reads outside the merge repo; deny network outside the merge fetch).
• Gap B — raw error surfacing: failure paths interpolate errorMessage(error) (the raw Error.message) into returned strings throughout integrate.ts (e.g. lines 309, 354, 386). integrate-command.ts claims "one-line message only — no stack traces, no secrets" (line 12) but does not redact or length-cap. Recommend a single shared secret-redacting, length-capped formatter applied at the integrate/opencode failure boundary.

2. harness doctor version check is stale — valid (latent, not a regression)

• cmdDoctor compares the built binary --version against the bare baseVersion: if (binary.isBuilt && version !== p.baseVersion) at packages/harness/src/cli.ts:101.
• Built binaries now self-report <baseVersion>+harness.<shortSha> via buildHarnessVersion() (packages/harness/src/version.ts:6-8), so for a genuinely built artifact this exact-equality check fails.
• cmdDoctor is not on the release path — the release uses scripts/verify-binary.ts, which already expects/accepts the +harness.<short8> form (verify-binary.ts:8,94,150). So this is latent, but reachable under the new scheme. Recommend updating cmdDoctor to accept the +harness.<shortSha> form (mirror verify-binary.ts's logic, ideally via the shared buildHarnessVersion/parse helper).

3. Per-ref provenance collapses to the integration commit — valid (auditability)

• runIntegration sets every ref's resolvedSha to the shared integration commit: integrationRefs: sources.map((s, i) => ({ ref: …, resolvedSha: integrationCommit })) at packages/harness/src/integrate.ts:393-396 (the inline comment at line 390 acknowledges this).
• Acceptable under the current 1–3 ref carry policy, but the manifest cannot record each ref's actual upstream SHA. Recommend resolving each ref's upstream SHA (e.g. git rev-parse FETCH_HEAD/the fetched ref tip during the fetch step at integrate.ts:330) and recording it per-ref in the manifest.

Optional test additions (from #774 review) — both worth adding:

• Assert the produced artifact contains no .git directory (clean-snapshot guarantee underpinning the handoff).
• Assert --source-tree pointing at a non-empty non-git directory builds without invoking the clone path.

Reproduction

• Item 2 is the only directly reproducible one without secrets: build a harness binary, then run harness doctor against it — the version check fails because the binary reports <base>+harness.<sha> while cmdDoctor expects bare <base>. (Confirmed by code inspection; no live secret needed.)
• Items 1 & 3 require a live HARNESS_OPENCODE_AUTH_JSON release run to exercise end-to-end, but both are confirmed structurally in source as described above.

Proposed next steps (suggested order, smallest blast radius first)

1. Item 2 (doctor) — small, self-contained: update cmdDoctor in cli.ts to accept +harness.<shortSha>; add a unit test. Reuse the parsing already in verify-binary.ts.
2. Item 3 (per-ref SHA) — capture each fetched ref's resolved upstream SHA in the adapters fetch step and thread it into the manifest; update integrate.test.ts to assert distinct per-ref SHAs.
3. Item 1b (error redaction) — add a shared length-capped, secret-redacting formatter; route integrate.ts/integrate-command.ts failure messages through it; test with a synthetic secret-bearing error.
4. Item 1a (sandbox) — define a restrictive OpenCode permissions policy for runMerge and wire it into the opencode run invocation; validate against a real dispatch.
5. Optional tests — add the .git-absence and --source-tree no-clone assertions to the integrate/build test suites.

Items 1–3 are independent and can be split into separate PRs. Suggest tackling 2 + 3 + tests together (no secret needed, fast to verify) and treating the sandbox work (1a) as its own change requiring a live release dispatch to validate.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/agent
Run ID	26994556822
Cache	hit
Session	ses_16a0da5f8ffelaWt2bBQ271SYS

[marcusrbrown]

Re-verified against current main after the 1.16.0 publish — all items still stand.

• Doctor version check (item 2): still bare-equality (binary.isBuilt && version !== baseVersion), so it fails on a real built binary that self-reports <base>+harness.<sha>. Off the release path (verify-binary.ts already handles the +harness.<short8> form), but reachable. Smallest fix — reuse the verify-binary parse logic. I hit this directly smoke-testing the published 1.16.0 binary.
• Merge agent isolation + error redaction (item 1): runMerge still invokes opencode run with no permission/sandbox scope, and failure paths still interpolate raw Error.message with no shared redacting/length-capped formatter.
• Per-ref provenance SHA (item 3): structure still collapses every ref's resolvedSha to the shared integration commit. Currently moot — the 1.16.0 carry set is empty (stock release, PR #30182 was reverted upstream), so there are no refs to record. This only becomes real work when the harness next carries an actual patch; worth fixing alongside that.

Keeping open. Suggested order unchanged: item 2 (small, no secret needed) first, then 1b redaction, then 1a sandbox (needs a live release dispatch to validate), with item 3 deferred until a non-empty carry returns.