[Feature Request] `varlock run --override` flag to force .env values over existing env vars

[baudbot-agent]

varlock version

0.1.4

Problem

varlock run does not override environment variables that are already set in the parent process. This is a reasonable default for short-lived CLI usage, but becomes a correctness problem in long-running daemon/agent contexts where child processes are restarted periodically.

Scenario:

1. A supervisor process is launched via varlock run -- node supervisor.js
2. API_ACCESS_TOKEN and API_ACCESS_TOKEN_EXPIRES_AT are injected from .env at startup
3. Hours later, the token expires and is rotated — a new token is written to .env
4. The supervisor restarts a child process using varlock run -- node worker.js
5. Bug: varlock run sees API_ACCESS_TOKEN already set in the inherited env and does not override it with the fresh value from .env
6. The child process gets the stale, expired token and fails

This affects any rotatable credential or config value managed by varlock. The .env file is the source of truth, but varlock run silently ignores it when the parent env already has a value.

What is expected?

A flag like --override (or --force, or --fresh) that tells varlock run to always use .env values regardless of what is already in the environment:

varlock run --override --path ~/.config/ -- node worker.js

Alternatively, this could be the default behavior for varlock run (since the explicit intent of varlock run is "run this command with my managed env"), with a --no-override flag to preserve the current behavior for users who rely on shell env taking precedence.

What is actually happening?

varlock run preserves existing env vars and only injects vars that are not yet set. There is no way to force .env values to take precedence.

Current workaround

Enumerate all varlock-managed keys via varlock load and unset them before calling varlock run:

if command -v varlock >/dev/null 2>&1; then
  while IFS='=' read -r key _; do
    [ -n "$key" ] && unset "$key"
  done < <(varlock load --path "$HOME/.config/" --format env --compact 2>/dev/null)
fi
varlock run --path ~/.config/ -- node worker.js

This works but is verbose, requires two varlock invocations (one to list keys, one to run), and pipes secret values through stdout unnecessarily.

Context

Discovered while debugging a long-running agent supervisor that kept crash-looping after a token rotation. The supervisor is launched via varlock run, and periodically restarts worker processes also via varlock run. After rotating an expired token in .env, the workers kept getting the old token from the parent's inherited environment.

[theoephraim]

This is interesting. We use passing in process environment variables as the main way to pass in overrides, which at the very least, is often used to pass in a specific env flag (dev vs prod) and sometimes a secret-zero (keys that allow access to fetch other env vars from a secure backend). I dont think we want to remove that behaviour. But luckily I think we have enough contextual info around to realize what is going on, and reset any varlock set env vars within a child varlock process.

Some other potential features which could be useful:

• mark certain env vars in with a decorator that says - "ignore any process env override"
  • this could be at the schema level if you always want that behaviour
  • or you could set it in a file containing values only (.env or .env.local)
• allow passing in overrides via command line flags rather than env vars. This coupled with a setting to ignore all overrides from env vars could work