An inherited environment variable overrides the values varlock loads

varlock lets variables already in the process environment take precedence over the values it loads. Nest one varlock-wrapped process inside another and the inner one inherits the outer one's settings, including which secrets store to read.

We hit this in lj-website's ops alerts. Our swamp workflows run inside lj-website's varlock run, and the alert step calls a script in the sibling Replicator repository through Replicator's own varlock run. lj-website's OP_TOKEN and OP_ENV_ID were inherited by the inner process and overrode Replicator's .env.local, so Replicator's varlock tried to load lj-website's 1Password environment and failed at initialization. Every alert died before it could send. We found it by deliberately aiming the new production smoke check at a host that would fail and watching for the email that never came.

The fix strips the inherited variables before the inner call: env -u OP_TOKEN -u OP_ENV_ID -u __VARLOCK_RUN -u __VARLOCK_ENV. Replicator had already learned the same lesson for its environment audit, which resolves each environment in a child process given only PATH, HOME, OP_ENV_ID and OP_TOKEN.

The general rule: whenever one varlock-managed process launches another, start the child from a clean environment, or it will quietly resolve as its parent.

Receipt: lj-website commit 85b34a6 (ops/swamp/models/command/shell/replicator-notify.yaml); Replicator scripts/env-audit.ts loadEnvironment (FINDINGS.md, "varlock, environments and secrets").