Phase 1: spawn/env plumbing — thread env through rex runtimes + gate agent-cmd override (#89, #80)

[joctaTorres]

Phase 1 of 4 — stacked batch engine-runtime-hardening. Base: engine-issues (pre-batch).

• rex: AgentSpawnRequest.env is silently dropped by both rex runtimes — the engine's per-step env never reaches the agent #89 — both rex runtimes export AgentSpawnRequest.env before launching the agent via one shared spawn-command helper (overlay merge semantics); doc contract fixed.
• engine: RATCHET_BATCH_AGENT_CMD / RATCHET_EVAL_AGENT_CMD silently replace the agent in production — no gating, no notice, no journal marker, permissions bypassed #80 — RATCHET_BATCH/EVAL_AGENT_CMD overrides print a notice, set agentOverride in --json, and stamp via:env-override provenance; one shared buildAgentSpawnRequest dedups the override gate across engine/judge/mutation-harness.

Closes #89
Closes #80

Stacked-PR note: best-effort per-phase split of entangled work — shared files land on the earliest phase, so this branch may not build standalone; the verified-green tree is the top of the stack (phase 3).

🤖 Generated with Claude Code

[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	ratchet	27c10ef	Commit Preview URL Branch Preview URL	Jul 09 2026, 10:24 PM

[joctaTorres]

Review — observability lands cleanly; the security-relevant half of #80 is deferred

This closes the audit/integrity half of #80 well: the via: 'env-override' provenance on journal entries and eval run records (stamped at both producers — engine host loop and batch report invoked by the spawned stand-in) is what makes a done reached via a synthetic stub distinguishable from real agent work after the fact. The single-helper dedup (buildAgentSpawnRequest / activeAgentCmdOverride) and the agentOverride: true / notice surfacing are clean and well-tested.

Two things I want to flag for the record, since a reader could mistake this for having contained the override rather than surfaced it:

1. The override still fires unconditionally — no gating (deferred). RATCHET_BATCH_AGENT_CMD / RATCHET_EVAL_AGENT_CMD still hijack the agent on any leftover value (.envrc, CI, a prior eval session). #80's fix-proposal #3 (--allow-agent-override, or gate on NODE_ENV / RATCHET_TEST=1) was not implemented. Net effect: silently replace → replace with a warning, not refuse unless opted in. On its own that's a foot-gun rather than a vuln — the env-setter already has your shell privileges — but it crosses a trust boundary in the exact sources the issue names (a hostile repo's .envrc, CI env set by less-privileged config → command execution on the host).

2. Permissions bypass is untouched — this is the actual security concern (#80 problem #2). The override branch returns a bare bash -c <value> request with no adapter and no permission flags, so resolvePermissionFlags posture/deny never applies — while batch config continues to display the locked-down posture as if it were enforced. A safety control that reports itself active while being silently voided is worse than one that's visibly off, because it defeats the operator's ability to reason about what the spawned command can touch. This PR's goals are explicitly "loud, auditable, single-sourced"; permissions never appear in the plan, so the posture-lie survives.

Severity hinge: how bad #2 is depends on whether ratchet's permission flags are an enforced sandbox/containment boundary or advisory. If they're the real containment for autonomous runs, "bypassed while reporting enforced" is a legitimate finding worth a follow-up (or a batch config caveat when an override var is active).

Not blocking the observability work here — flagging that the security-relevant half of #80 (gating + permissions posture integrity) remains open after this closes #80, and should be tracked so it isn't assumed handled.