DesktopAuth: Client.authenticate() hangs indefinitely after desktop app lock/unlock cycles

[vinzenzweber]

Summary

Client.authenticate() with DesktopAuth blocks indefinitely (no timeout, no error) after the 1Password desktop app has been running for an extended period, gone through lock/unlock cycles, or been restarted. The IPC channel between the SDK and the desktop app enters a broken state where connections are accepted but never answered.

Environment

• onepassword-sdk: 0.4.0
• Python: 3.11
• macOS: 15.5 (Sequoia)
• 1Password desktop app: latest (v8)
• 1Password CLI: 2.32.0

Steps to reproduce

1. Set up a Python application that uses DesktopAuth to authenticate:

   from onepassword.client import Client, DesktopAuth
   
   auth = DesktopAuth(account_name="my-account")
   client = await Client.authenticate(
       auth=auth,
       integration_name="my-app",
       integration_version="v1.0.0",
   )
   result = await client.secrets.resolve_all(["op://vault/item/field"])

2. Use the application normally — authentication works on first use.
3. Lock/unlock the 1Password desktop app (or let the Mac sleep/wake), or leave the app running for several hours.
4. Call Client.authenticate() again.

Expected behavior

Client.authenticate() should either:

• Successfully re-authenticate via the desktop app (prompting for biometrics if needed), or
• Raise an exception with a meaningful error after a reasonable timeout.

Actual behavior

Client.authenticate() hangs indefinitely — no biometrics prompt appears, no exception is raised, and the call never returns. The process must be killed externally.

The underlying libop_sdk_ipc_client.dylib appears to connect to the desktop app's Mach port successfully, but the desktop app never responds to the authentication request.

Workaround

The only reliable recovery is to force-kill all 1Password processes and relaunch:

pkill -9 -f 1Password
sleep 3
open -a "1Password"
# Unlock with Touch ID / master password
op whoami  # verify IPC is working again

Regular quit (Cmd+Q) is not sufficient — the IPC stays broken until all processes are killed with -9.

We have switched our project to use the op CLI (subprocess.run(["op", "read", ...])) as the default backend due to this instability, keeping the SDK as an opt-in alternative.

Related issues

This is the same root cause reported across multiple 1Password integrations:

• OpenTofu stops asking for TouchID after a while and hangs when running plan terraform-provider-onepassword#341 — Go SDK hangs identically via DesktopAuth after lock/unlock cycles. A 1Password contributor confirmed it appears to be a desktop app issue.
• Occasional “hangs” with gh shell-plugins#416 — op plugin run hangs; spindumps show threads blocked on __psynch_cvwait waiting for a desktop app response that never comes.
• 1password cli stuck on read NixOS/nixpkgs#373415 — op read gets stuck; desktop app logs show EndConnection errors.

Suggestions

1. Add a configurable timeout to Client.authenticate() / DesktopAuth so callers aren't blocked forever.
2. Detect stale IPC state and raise a clear error (e.g., "1Password desktop app is not responding — restart it") instead of hanging silently.
3. Coordinate with the desktop app team — the bug appears to be in the app's IPC listener, not the SDK itself, but the SDK should be resilient to it.

[phatmandrake]

We've been hitting this in an MCP server integration and found a reliable reproduction and built an automated recovery routine.

Reproduction

1. Establish an SDK connection via DesktopAuth and make calls normally
2. Lock 1Password (menu bar → Lock, or Cmd+Shift+L)
3. Any subsequent Client.authenticate() or SDK call hangs indefinitely
4. Unlocking 1Password does not recover it — the handler remains dead
5. Only a full process restart restores SDK functionality

This is 100% reproducible in our environment (macOS ARM64, SDK 0.4.0 beta, 1Password 8.12.x beta).

Why We Think It Happens

• The SDK uses 1PASSWORD_SDK_INTEGRATIONS_PORT (raw Mach IPC), while the op CLI uses 2BUA8C4S2C.com.1password.browser-helper (XPC). These appear to be completely separate handlers inside 1Password.
• After a lock event, the op CLI continues working — op whoami, op read, etc. all succeed. Only the SDK's Mach port handler seems to be affected.
• The Mach port remains registered in launchd (Active) and the kernel accepts messages into its queue — but the application-level handler doesn't appear to dequeue them.
• We couldn't find any corresponding error in 1Password's logs when the SDK handler stops responding.

Automated Recovery

Since the SDK has no built-in timeout and op_sdk_ipc_send_message → mach_msg blocks the calling thread forever, we built recovery around it:

• Lock detection — read 1Password_rCURRENT.log for Lock state changed: before every call. If locked, fail instantly instead of hanging.
• Subprocess isolation — SDK runs in a worker subprocess. The parent proxy enforces a 5-second timeout and kills the worker if the FFI blocks — the only way to interrupt mach_msg since SIGALRM can't reach it.
• Biometric awareness — after timeout, check 1Password's log for biometric activity. If a prompt is showing, skip the restart and let the user respond. If no activity, the handler is likely wedged.
• Graceful restart — SIGTERM 1Password (not SIGKILL, which can trigger a crash dialog that blocks SDK port re-registration), relaunch, poll launchctl print until 1PASSWORD_SDK_INTEGRATIONS_PORT reappears.
• Stale dylib cleanup — on IPC errors during auth, the worker exits entirely so the next attempt gets a fresh ctypes.CDLL() handle. Without this, the dylib retains a dead Mach port send right and keeps returning -2.

The full lock → unlock → recover cycle completes in under 10 seconds with one Touch ID prompt on the restarted app.

Environment

• macOS ARM64 (Apple Silicon), clamshell mode
• 1Password 8.12.8-23.BETA
• Python SDK 0.4.0 (beta branch)
• op CLI 2.32.0
• No sleep/wake transitions — machine was fully awake (caffeinate active, externally powered)