Allow Deno as a VarlockEnclave IPC client

[bjesuiter]

What happened

deno run -A npm:varlock@1.9.0 load --skip-cache fails when resolving a keychain(...) secret on macOS.

Observed error:

keychain(): Failed to read keychain item: Daemon connection closed
Make sure the item exists in your Keychain and VarlockEnclave has access.

The same env file succeeds with the globally installed varlock CLI.

Why

With VARLOCK_DEBUG=1, Deno resolves the native helper from Deno's npm cache, but the decisive failure is in the native daemon's IPC client authorization.

When the Deno-cache helper daemon is started manually, it logs:

varlock: rejected IPC connection from unauthorized process (pid=..., path=/Users/.../.deno/bin/deno)

VarlockEnclave currently allows IPC clients by executable name. The allowlist includes node and bun, but not deno, so Deno is rejected before keychain-get, keychain-search, or keychain-fix-access can run.

Affected paths are likely any Varlock feature using the local encryption daemon, including keychain() and the varlock keychain subcommands.

Proposed fix

Add deno to the native daemon client allowlist, matching the existing Node/Bun runtime treatment:

 private let allowedBinaryNames: Set<String> = [
     "VarlockEnclave",        // The daemon itself (self-connections via .app bundle)
     "varlock-local-encrypt", // Rust binary (not used on macOS, but for completeness)
     "varlock",               // SEA CLI binary
     "node",                  // Node.js (varlock TS client)
     "bun",                   // Bun runtime (varlock TS client)
+    "deno",                  // Deno runtime (varlock TS client)
 ]

I validated this patch builds and the Swift test suite still passes locally with:

cd packages/encryption-binary-swift/swift
swift test

[bjesuiter]

My agent initially proposed a stricter check: allow deno only when its argv indicates it is running npm:varlock / npm:varlock@....

I decided against that for now because:

• Depending on how Deno executes an npm package, I cannot guarantee the original package spec always remains visible in argv.
• A string equality/prefix check would be brittle if aliases or wrapper commands are introduced anywhere in the invocation chain.
• Argument-based detection can become sensitive to shell/env interpolation timing, depending on when env vars or command aliases are evaluated.
• Existing node and bun support already blanket-allows those runtime executable names, so adding deno keeps behavior consistent.

[philmillman]

Thank you @bjesuiter we'll have a look shortly

[bjesuiter]

I'm already looking into it. Simply allowing "deno" as process name in the switft code seemst to work, but I'm still trying to validate general functionality with deno to ensure compatibility.
when i'm ready i'll post a PR!

[bjesuiter]

Here is the pr: #847

it also optimizes behavior of the new keychain commands, sorry for muddling them into the same pr. It was helpful to have these keychain smoke tests in the same branch to be able to test the whole smoke test suite with deno too to ensure compatibility with at least deno run -A