[BUG]: Auto-load re-resolve inside varlock run fails when an @internal value came from the shell #1138

varlock version

1.21.0

Steps to reproduce

.env.schema:

# @defaultSensitive=false
# ---
# Comes from the shell, only used to build SERVICE_URL.
# @internal
SUBDOMAIN=
SERVICE_URL=https://${SUBDOMAIN}.example.com

check.ts:

await import("varlock/auto-load");
console.log("SERVICE_URL =", process.env.SERVICE_URL);

1. SUBDOMAIN=api varlock run -- bun check.ts
2. SUBDOMAIN=api varlock run -- sh -c 'echo "# edited" >> .env.schema; bun check.ts'

What is expected?

Both print SERVICE_URL = https://api.example.com. The second is the watch-mode case the JavaScript guide describes: an env file changes while the app runs under varlock run (for example varlock run -- bun run --watch src/index.ts), and auto-load re-resolves instead of reusing the blob.

What is actually happening?

1 works. 2 fails:

❓ SUBDOMAIN*  🔩internal
   └ undefined
   - Value is required but is currently empty
⛔ SERVICE_URL*  🔐sensitive
   └ undefined
   - Dependency SUBDOMAIN is invalid

varlock run strips @internal items from the child env, including values that came from the ambient environment (as documented). When the child's auto-load then re-resolves because an env file changed, the internal value is no longer there to resolve from, so the load fails. The same happens to a secret-zero passed in from the shell, for example an OP_TOKEN of type opServiceAccountToken: editing an env file during a watch session breaks every op() item. Without @internal, step 2 works.

Possible fixes: carry internal ambient values in the (encrypted) blob for re-resolution only, or have auto-load re-resolve through the parent varlock run, or document that re-resolution in a child cannot see internal items.

System Info

macOS 27.0 (arm64)
Bun 1.4.2
varlock 1.21.0

Any additional comments?

Hit in a Bun monorepo where a value set by the shell per checkout feeds other items; we had to drop @internal from it so a watch session survives an env edit.