[BUG] `PKG_EXECPATH` from parent varlock process breaks nested `varlock run` calls

[baudbot-agent]

varlock version

0.1.4

Steps to reproduce

1. Launch a process via varlock:

   varlock run -- node supervisor.js

2. Inside supervisor.js (or a shell script spawned by it), call varlock again:

   varlock run --path ~/.config/ -- sh -c 'echo $MY_VAR'

3. The nested varlock run fails:

   Error: Cannot find module '/home/user/run'
   

What is expected?

Nested varlock run calls should work correctly regardless of how the parent process was launched.

What is actually happening?

The initial varlock run sets PKG_EXECPATH=/path/to/varlock in the child process environment. This is a Node.js SEA (Single Executable Application) convention — when set, it tells Node.js that the binary was packaged as a single executable.

When a nested varlock run is invoked, the varlock binary (which is a Node.js SEA) sees PKG_EXECPATH already set and misinterprets its own argv. Instead of treating run as a subcommand, it tries to resolve it as a Node module path relative to the working directory, producing:

Error: Cannot find module '/home/user/run'

Workaround

Unset PKG_EXECPATH before any nested varlock call:

unset PKG_EXECPATH
varlock run --path ~/.config/ -- node worker.js

Suggested fix

varlock should unset PKG_EXECPATH (or delete it from process.env) early in its own startup, before argument parsing. The binary knows it is a SEA — it does not need this env var to persist, and it should not leak it to child processes.

Alternatively, varlock could strip PKG_EXECPATH from the child process environment in varlock run so it does not propagate.

System Info

• OS: Ubuntu 24.04 (aarch64)
• Node: v22.14.0 (embedded in varlock SEA)
• varlock: 0.1.4
• Install: ~/.varlock/bin/varlock

Context

Discovered in a long-running supervisor process launched via varlock run -- node supervisor.js. When the supervisor spawns helper scripts that also invoke varlock run to probe for configured secrets, all nested varlock calls fail silently (stderr is suppressed with 2>/dev/null in production), causing downstream processes to never start.

[theoephraim]

Thanks @baudbot-agent - im about to move things over to a bun-powered binary, so likely this will go away, or at least change.