fix: show pending refs in custom NSWindow at TouchID prompt (op-c0e)

[jeremyschlatter-intern]

Summary

Implements Option 1 from the op-knn design — a custom NSPanel floats above the terminal listing every op:// reference involved in the upcoming TouchID authentication, then the system LAContext dialog appears on top of it. Same pattern used by 1Password, pinentry-mac, and ssh-askpass.

History (this bead has two prior reverts)

• op-rba (6e039b6, reverted in PR Revert broken polecat commits (op-rba, op-c0e, op-xev.2) #5 b1a18f0): printed refs to stdout → polluted piped output like eval $(opcli ...).
• original op-c0e (389198e, reverted in PR Revert broken polecat commits (op-rba, op-c0e, op-xev.2) #5 699977d): put refs in the LAContext localizedReason string → too cramped (~60-80 visible chars), plus broke CI tests.
• PR Revert broken polecat commits (op-rba, op-c0e, op-xev.2) #5 (483346e) reverted both attempts and pinned Option 1 as the required approach.

This PR implements Option 1 and explicitly avoids Options 4/5 (terminal output, helper app) per the bead's out-of-scope list.

Changes

• touchid.m — creates an NSPanel with NSWindowStyleMaskUtilityWindow listing refs, registers NSApp as NSApplicationActivationPolicyAccessory (no dock icon), pumps CFRunLoopRunInMode while blocking on the LAContext reply. Window is closed on auth completion (success or failure).
• touchid_stub.m — matches the new two-arg signature; ignores refsText. Still linked under -tags test so headless CI builds without AppKit.
• keychain.go — AuthenticateBiometric(reason, refs) now takes the ref list; empty list suppresses the window entirely. Dedup preserves order.
• main.go — re-introduces AccountKeychains.pendingRefs; cmdRead, cmdInject, cmdRun populate it; aks.get consumes it only when a new biometric auth will actually be prompted.
• cgo_prod.go — links AppKit.
• Makefile — suppresses deprecated-declarations noise for the new imports.

How this avoids PR #5's revert outcome

• Stdout pollution — the window replaces stderr output entirely; zero stdout writes.
• Dialog truncation — the window has its own scroll view, so an arbitrary number of refs display in full.
• Test breakage — the stub's signature is updated to match and still ignores the new arg, so -tags test builds continue to link without AppKit. go vet clean; production and test-tag builds both compile.

Test plan

• go vet ./... — clean
• Production build (make) — succeeds, links AppKit
• Test-tag build (go build -tags test) — succeeds without AppKit
• Manual (cannot run automated — headless CI can't render NSWindow):
  • opcli read op://Vault/Item/field → window shows 1 ref + system TouchID prompt appears on top
  • opcli inject -i template_with_several_refs.txt → window shows all unique refs deduped
  • opcli run --env-file=... -- cmd → window lists env-var refs + arg refs
  • With a valid unexpired session → no window shown (auth is skipped entirely)
  • Cancelling TouchID → window closes, error is returned normally
  • TouchID failure → window closes, error is returned normally
• E2E tests — existing pre-existing failure tracked in op-atk (SIGN_IDENTITY on machines without a Developer ID cert); not introduced by this change

Out of scope

• Option 4 (terminal/stderr output) — explicitly ruled out by the bead
• Option 5a (separate helper app) — deferred
• Customizing the system TouchID dialog itself — impossible (Option 2 in design)

Refs: op-c0e, op-knn (design), PR #5 (the revert), op-rba (earlier attempt), op-atk (pre-existing SIGN_IDENTITY test failure)

🤖 Generated with Claude Code

[jeremyschlatter]

The official op CLI creates custom TouchID prompt windows that look like this:

By contrast, this PR causes us to end up with two windows on top of each other like this:

The 1-window way is clearly better. Figure out how to do that instead. If helpful, here is a guess from Opus 4.6 about how the op implementation works. Keep in mind it is just a guess and needs to be confirmed:

---

Technical Brief: How 1Password Achieves a Single-Window TouchID Experience

The Theory: Sheet Presentation

1Password's TouchID dialog appears as a single cohesive window, but it's actually two elements composed together: a custom NSWindow owned by 1Password showing context (app icon, "Allow X
to get CLI access", account selector), with the system LAContext biometric prompt presented as a sheet attached to that window. macOS sheets slide down from the parent window's title
bar and share its chrome — corners, shadow, background — making parent+sheet look like one unified panel.

Technical Mechanism

When a macOS app calls LAContext.evaluatePolicy(_:localizedReason:), the system's SecurityAgent process renders the TouchID dialog. The presentation mode depends on the caller's
application state:

• No foreground app / no key window (typical for CLI tools): SecurityAgent renders a floating system modal — a standalone dialog centered on screen. This is what PR #7 currently
  produces.
• Foreground app with an active key window: SecurityAgent can attach the dialog as a document-modal sheet to the calling app's key window. The sheet's corner radius and shadow merge with
  the parent window, producing the unified appearance 1Password shows.

The suspected key requirements:

1. NSApplication initialized with NSApplicationActivationPolicyRegular (not .Accessory) — the app must be a "real" foreground app, not a background utility
2. [NSApp activateIgnoringOtherApps:YES] to claim foreground status
3. The custom NSWindow must be makeKeyAndOrderFront: before calling evaluatePolicy:
4. The evaluatePolicy: call must happen on the main thread while the window is key

Evidence

• The 1Password screenshot shows uniform corner radii and continuous shadow between the context area (app icons, account name) and the biometric area (fingerprint icon, "Use Password"
  button). This is visually consistent with a sheet presentation, not two overlapping windows.
• The macOS Human Interface Guidelines document sheet presentation as the standard pattern for auth dialogs originating from a specific window context.
• PR #7's current approach uses NSApplicationActivationPolicyAccessory and creates an NSPanel with utility-window styling. This explicitly opts out of foreground-app status, which would
  prevent SecurityAgent from attaching its dialog as a sheet.

What Was Ruled Out

• Customizing the LAContext dialog itself: dead end. The dialog is rendered by SecurityAgent in a separate process. No public or private API can change its layout, add views, or restyle
  it. (Confirmed in op-knn design doc, Option 2.)
• Alternative biometric frameworks (CryptoTokenKit, ASAuthorization): all funnel through the same SecurityAgent UI. No advantage. (op-knn Option 3.)
• LocalAuthenticationEmbeddedUI / LAAuthenticationView (macOS 14+): a newer framework that embeds biometric UI inline as a SwiftUI view. This is a viable alternative path if sheet
  presentation doesn't work, but would require a SwiftUI dependency and macOS 14 minimum.

Open Questions

1. Whether NSApplicationActivationPolicyRegular from a CLI-launched process actually works, or whether macOS requires an app bundle (Info.plist, proper CFBundleIdentifier) for foreground
   activation.
2. If sheet presentation fails, LAAuthenticationView (macOS 14+) is the fallback — but its availability on the user's minimum supported macOS version is unknown.

[jeremyschlatter-intern]

Pushed rev 2 — switched to LAAuthenticationView (inline biometric UI)

What I tested for the sheet theory

Spent an iteration verifying the sheet-presentation theory with an ad-hoc-signed test harness driving touchid.m through an app bundle launched via open (needed for the GUI session — SSH process context gives LAErrorUserInteractionRequired). Setup: NSApplicationActivationPolicyRegular + [NSApp run] + makeKeyAndOrderFront: + activateIgnoringOtherApps: before evaluatePolicy:.

Result: SecurityAgent still renders the LAContext modal as a floating, screen-centered dialog. It is not attached as a sheet to our window, regardless of activation policy or key-window state. The two-window stack remains.

Screenshot of that state (our NSWindow partially visible behind the centered LAContext password dialog): v6-no1p.png — I have it locally at /tmp/op-c0e-review/v6-no1p.png if useful.

So the guess from Opus 4.6 in the review was wrong — sheet presentation is not how 1Password gets its unified look.

What I found instead: LAAuthenticationView

LocalAuthenticationEmbeddedUI.framework ships an ObjC class LAAuthenticationView (NSView subclass, macOS 12+ — not 14+ as the review assumed, so SDK availability isn't a concern). From the SDK header (LAAuthenticationView.h):

When evaluatePolicy or evaluateAccessControl is called on this context, the UI will be presented using this view rather than using the standard authentication alert.

This is the supported API for inline biometric UI. No SwiftUI needed — pure ObjC, fits the existing cgo bridge.

This rev uses it

New flow:

1. NSApp set up as Regular foreground app (required for LAContext to accept the call).
2. Inside applicationDidFinishLaunching: (only reliable way to have the process be treated as foreground by LAContext), we create an NSWindow containing: header, scrollable refs list, LAAuthenticationView at the bottom.
3. evaluatePolicy: is called on the same LAContext instance the view is paired with. The biometric prompt renders inside our view — no separate SecurityAgent modal. Single unified card.
4. On auth completion (success or failure), we close the window and [NSApp stop:].

Build: added -framework LocalAuthenticationEmbeddedUI to prod LDFLAGS.

Fallback

LAAuthenticationView only supports biometric-ish policies. If canEvaluatePolicy:WithBiometrics returns false (no Touch ID hardware / no Magic Keyboard with TouchID / no Watch), we fall back to classic LAContext.evaluatePolicy with device-owner auth — the old system password alert, no custom window. Not unified, but functional for the minority case.

What I couldn't verify locally

The polecat worktree is SSH-attached and has no biometric accessory paired (Biometric accessory is not paired. from canEvaluatePolicy). Only the fallback path exercises here. The inline LAAuthenticationView path needs a session with Touch ID hardware to visually confirm.

You're on macOS 14.6.1 with Touch ID — could you:

1. Pull polecat/quartz-mnxkby6z, make sign SIGN_IDENTITY=…, and run opcli read op://Vault/Item/field from Ghostty?
2. Capture the result.

If the inline view doesn't look right, I have two directions ready:

• Tweak layout/dimensions of the surrounding window.
• If for some reason LAAuthenticationView doesn't render correctly when driven by a CLI process (vs. a full Cocoa app), fall back to a custom "Authorize with Touch ID" button that triggers evaluatePolicy on click — matches 1Password's 2-click flow with a separate system modal after click, but at least the pre-click state is a single window.

[jeremyschlatter-intern]

Pushed rev 3 — all six of your design items + cancel

Iterated here with a mock NSImageView in place of LAAuthenticationView (the polecat session has no biometric accessory paired). Final commit swaps the mock back to the real LAAuthenticationView at NSControlSize.small (32×32) — the previous default was .regular (64×64), which is what you flagged as too large.

Your list:

1. ✅ Cancel button — invalidates the LAContext, the pending evaluatePolicy reply fires with a cancelation error and exits the run loop cleanly through the normal completion path. Esc also cancels.
2. ✅ Bullets dropped.
3. ✅ Refs grouped by [account:]vault with # VaultName headers. Vault prefix dropped from each ref. Grouping happens Go-side in formatBiometricRefs — emits JSON, consumed by touchid.m via NSJSONSerialization.
4. ✅ Each vault section is its own inner NSScrollView capped at 8 visible rows with NSScrollerStyleLegacy + autohidesScrollers:NO so the scroll track stays visible even when not scrolling (makes it obvious there's more). Outer scroll handles overflow across many vaults.
5. ✅ Title bumped to 17pt semibold ("opcli access requested"), subtitle 12pt secondary ("request to read N secrets"). "Touch ID" in the authorize label rendered semibold via NSAttributedString.
6. ✅ Forced dark appearance (NSAppearanceNameDarkAqua) so the card looks like the 1P target regardless of system light/dark mode.

Known gap: the actual LAAuthenticationView rendering (stroke/animation/hover of the fingerprint glyph) is only visible with real biometric hardware, so you'll need to eyeball it. If the icon is still too large at .small, I can drop to .mini (16×16). The four NSControlSize options give 16 / 32 / 64 / 128.

Layout fix: previous rev had a bug where the first vault's header rendered above the outer scroll view's visible area. Fixed by using a flipped NSView as the scroll's document view (top-down coords) — the first section is now always visible.

Ready to verify on your Mac.

[jeremyschlatter]

Screenshot of latest version.

Merging as requested