Add Deno and macOS Keychain smoke coverage

[bjesuiter]

Summary

This PR improves Deno compatibility and makes the macOS Keychain access model explicit and non-destructive.

Deno

• allow deno processes to connect to the Varlock IPC helper
• generate shell completion scripts that invoke Varlock correctly through deno run -A
• add an opt-in Deno compatibility path to the shared smoke-test runner

macOS Keychain

• make all production secret reads go directly through Security.framework; there is no /usr/bin/security read fallback
• change varlock keychain fix-access to read each referenced item through VarlockEnclave and guide the user to choose Always Allow
• support fix-access for one item or every explicit keychain(...) reference in an env file
• add varlock keychain cloneToOwned as an explicit, non-destructive way to create a Varlock-owned copy
• add varlock keychain delete for generic-password items
• update the Keychain documentation and daemon IPC types accordingly

Keychain access behavior

For a secret that already exists in Keychain and is owned or managed outside Varlock, the normal path is to read it in place. macOS may prompt for access; choosing Always Allow adds VarlockEnclave to that item's ACL so repeated reads no longer prompt. Choosing Allow Once only authorizes the current read.

cloneToOwned is optional. It reads the source through Security.framework, creates a separate Varlock-owned destination item, optionally writes its keychain(...) env reference, and leaves the original item unchanged. The PR does not perform automatic ownership transfer or delete/recreate existing external items.

Smoke coverage

The gated macOS suite covers fix-access, cloneToOwned, set, and import, including subsequent reads and daemon-state resets between tests. /usr/bin/security is used only by test setup and cleanup to create or remove fixtures, never as a production secret-read path.

• Deno compatibility tests: VARLOCK_RUN_DENO_COMPAT=1
• Keychain tests: VARLOCK_RUN_KEYCHAIN_SMOKE=1

[theoephraim]

I'm not sure about deferring to security as a fallback. Maybe it could be a per item opt-in if it really solves some very specific use case?

Also I had thought that the main reason to read from existing keychain items is the case where a user is already using that item in other contexts, or for example where an IT department is managing those items for the user. In this case I dont think recreating the item will be a good idea.

One thing to note - it could be that you are seeing more prompts than would actually occur since you are not signing the built binary whereas the real one will be signed.

[theoephraim]

@pullfrog review this

[pullfrog]

ℹ️ No critical issues — one minor cleanup inline.

Reviewed changes — this PR adds Deno IPC/completion support and reworks the macOS Keychain flows (fix-access, a new non-destructive cloneToOwned, a new delete, and a /usr/bin/security read fallback), backed by gated smoke tests.

• Allow Deno clients over IPC — add deno to PeerIdentity.swift's allowedBinaryNames, and generate a Deno-aware completion script (getDenoCompletionExec in cli-executable.ts) via the new @bomb.sh/tab dependency.
• Rework fix-access to a native read prompt — fixAccessForRefs now performs a keychainGet(useFallback=false) read (guiding the user to "Always Allow") instead of mutating item ACLs; the keychain-fix-access daemon action and KeychainFixAccessResult type are removed.
• Add security CLI read fallback — KeychainManager.getItem/getItemOfClass gain a useFallback flag; on errSecAuthFailed/errSecInteractionNotAllowed (or other errors) they fall back to getGenericPasswordViaSecurityCLI. The useFallback flag is threaded through the resolver, daemon client, and daemon dispatch, and documented in the keychain docs.
• Add keychain cloneToOwned — non-destructive command that reads a source secret and recreates it as a Varlock-owned item (optionally writing the env ref); replaces the previous destructive take-ownership approach.
• Add keychain delete — new CLI command, daemon keychain-delete action, KeychainManager.deleteGenericPassword, and KeychainDeleteResult type. setGenericPassword also gains an optional keychainName.
• Add gated smoke tests + helpers — opt-in Deno (VARLOCK_RUN_DENO_COMPAT=1) and Keychain (VARLOCK_RUN_KEYCHAIN_SMOKE=1) suites, a shared resetVarlockDaemon helper, stdin input support in run-varlock, and new fixtures/scripts.
• Docs + changesets — keychain docs updated for the new commands and useFallback, plus three patch bump files.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[bjesuiter]

I'm not sure about deferring to security as a fallback. Maybe it could be a per item opt-in if it really solves some very specific use case?

=> The CodexBar App by Peter Steinberger does this to avoid too many access prompts when accessing things like: Anthropic OAuth Token for claude code to read usage from the token. In this example, CodexBar is not the owner of the secret too, so i figured, this fallback might be useful for us here.

But I admit, getting into the weeds of keychain behavior feels like a lot of trial and error. As I implemented the fix it seemed to help first, but I later realized your point of a non-signed dev build locally.

One thing to note - it could be that you are seeing more prompts than would actually occur since you are not signing the built binary whereas the real one will be signed.

After fixing that by signing the builds with my own apple developer key, the prompt behavior got better already.
Obviously, my signed version cannot read original varlock owned secrets, but the behavior between the "security" cli and my self-signed varlock helper build should be consistent with the behavior your originally signed varlock build should show.
So i assume that the test cases i added should still benefit us by avoiding regressions in keychain behavior :)

Also I had thought that the main reason to read from existing keychain items is the case where a user is already using that item in other contexts, or for example where an IT department is managing those items for the user. In this case I dont think recreating the item will be a good idea.

=> yes, I agree, the copy-then-own method seems not good, so i ripped it out again.
I'll look into the fallback to security cli again to check if we need this or not.

[bjesuiter]

Follow-up on the Keychain behavior: I removed the /usr/bin/security read fallback. Secret reads now use Security.framework directly again, so macOS evaluates access for VarlockEnclave itself.

For the original case—someone wants to use a secret that already exists in Keychain and is not owned by Varlock—the best flow is to choose Always Allow when macOS prompts. That adds VarlockEnclave to that item's ACL, so subsequent reads should no longer prompt. Allow Once only authorizes the current read. (you probably know this, but I wanted to conserve this here for people who might read this thread :D)

I also dug further into CodexBar. Delegating reads to /usr/bin/security was not a general prompt-suppression mechanism and CodexBar later disabled that production path because security find-generic-password -w can itself prompt. Other parts of its strategy are more relevant: gating/caching reads and caching credentials in a CodexBar-owned Keychain item. The latter is conceptually close to our explicit, non-destructive cloneToOwned flow.

@theoephraim what do you think of keeping these as the two explicit options?

1. Read an existing/externally managed item in place via Security.framework and choose Always Allow once.
2. Optionally use cloneToOwned when the user deliberately wants a Varlock-owned cached copy, while leaving the original untouched.
   => i could also remove the cloneToOwned again and we think about this caching mechanic more ^^

[pullfrog]

✅ No new issues found.

Reviewed changes — reviewed the native Keychain read revision added since the prior Pullfrog review.

• Removed the command-line fallback — deleted the /usr/bin/security generic-password fallback so secret reads consistently authorize VarlockEnclave through Security.framework.
• Removed fallback configuration — removed useFallback from the resolver, daemon client, daemon dispatch, documentation, changesets, and generated smoke fixture.
• Clarified persistent access behavior — updated the Keychain guidance to explain how choosing Always Allow grants VarlockEnclave persistent access, while Allow Once applies only to the current read.

  ^{｜ View workflow run ｜ Using azure/gpt-5.6-sol ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes focused on the signed-helper requirement added since the previous Pullfrog pass.

• Added a Keychain smoke preflight: gated macOS Keychain runs now fail before test execution when the packaged VarlockEnclave.app is missing, invalidly signed, ad-hoc signed, or lacks a stable Team ID.
• Added signing remediation guidance: the failure message points local contributors to the repository's APPLE_SIGNING_IDENTITY build path, which matches the native build script.

  ^{｜ View workflow run ｜ Using azure/gpt-5.6-sol ｜ 𝕏}