Start the native helper from its own directory - #1169

The standalone binary fails to start its native helper when varlock runs from a directory the current user cannot enter:

EACCES: permission denied, posix_spawn '/usr/local/bin/varlock-local-encrypt'

I hit this on a production host. A secret-rotation script ran runuser -u <service-user> -- varlock cache clear --yes for each service identity. runuser keeps the caller's cwd, here a home directory with mode 750, so the clear failed for all six identities. With cacheTtl=forever, the services kept the old credential until the cache files were deleted by hand. Reproduced in a clean container, the same command exits 1 with the error above.

The cause is in Bun 1.3.14, which the binary is built with (packageManager: [email protected]). Its child_process spawn fails with EACCES when the parent's cwd cannot be entered, even for /bin/true. Bun 1.4.2 and Node both spawn fine from the same cwd.

Change

getNativeBinarySpawnOptions() in binary-resolver.ts starts the helper from its own directory, which anyone who can run it can enter. It is used for every spawn of the helper (runNativeBinary, spawnNativeBinaryAsync, decrypt via the daemon, the detached daemon) and for the two WSL tools that start the Windows daemon (wslpath, powershell.exe). The daemon also stops holding the caller's directory open for its lifetime.

A relative XDG_CONFIG_HOME was the only thing tying the helper to the caller's cwd. It is now resolved to an absolute path, both in getUserVarlockDir() (which builds the daemon's socket and pid paths) and in the env passed to the helper, so keys and the daemon socket stay where they were. An empty XDG_CONFIG_HOME is dropped from the helper's env, since getUserVarlockDir() treats it as unset and the helpers would otherwise read it as a relative path.

This only covers the helper. Other spawns from the binary, including the child of varlock run, still use the caller's cwd, which is correct for them, but they hit the same Bun bug from a cwd that cannot be entered. Upgrading Bun would fix those too.

Test

• Unit: getNativeBinarySpawnOptions returns the helper's directory and resolves a relative XDG_CONFIG_HOME; getUserVarlockDir returns an absolute path for one.
• Smoke (binary.test.ts): enters a temp directory, removes access to it (chmod 000 .), runs cache clear with VARLOCK_DEBUG=1 and a scratch XDG_CONFIG_HOME, and checks that the helper was spawned and did not fail. On main it fails with the EACCES above. It needs the helper next to the binary, and the smoke-test workflow builds with --skip-native, so there it is skipped rather than passing without spawning anything. Skipped on Windows and as root.

I ran the smoke test locally against a binary built with Bun 1.3.14 with the Rust helper bundled, and also by hand in a Debian container as a service user via runuser from a mode 750 directory. cache clear now exits 0.