rpc: avoid blocking startup on an undetermined Contacts permission

[markxiong0122]

imsg rpc initializes Contacts before starting the JSON-RPC server:

• RpcCommand.swift calls await ContactResolver.create()
• the default policy is .requestIfNeeded
• .notDetermined then awaits CNContactStore.requestAccess

In a headless Aqua-domain LaunchAgent, that authorization request can remain pending indefinitely. The process stays alive but accepts no JSON-RPC requests, so unrelated methods such as chats.list, messages.history, and send.rich all hang before the server starts. We reproduced this on macOS with imsg 0.12.3 and verified the same call path on current main.

ContactResolver already supports the right fail-open-for-metadata behavior: .skipIfNotDetermined returns NoOpContactResolver(contactsUnavailable: true). Could the RPC entrypoint use:

let contacts = await ContactResolver.create(accessPolicy: .skipIfNotDetermined)

Interactive CLI commands can keep the existing default. RPC callers can then start reliably without Contacts display-name resolution, while authorized installations continue loading contacts normally.

A downstream watchdog now bounds requests, but fixing the RPC startup policy avoids the native wedge itself.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 1:08 AM ET / 05:08 UTC.

Summary
Current main still creates the prompt-capable Contacts resolver before JSON-RPC begins serving, so this issue remains necessary. The focused open implementation candidate at #187 owns the repair and includes headless runtime evidence; keep this issue open until that PR is reviewed and merged.

Reproducibility: yes. —current source establishes the path: RPC calls the default ContactResolver.create() before server startup, and that default requests access when Contacts authorization is undetermined. This read-only Linux review did not execute macOS Contacts APIs, but the linked pull request also supplies a real non-TTY macOS transcript.

Next step
Do not queue a competing repair because the open linked pull request already owns this small source-proven fix; the next action is compatibility review and merge of that candidate.

Review details

Best possible solution:

Review and land the focused linked pull request if its noninteractive fail-open policy and interactive compatibility coverage are accepted; the merged fix can then close this issue.

Do we have a high-confidence way to reproduce the issue?

Yes—current source establishes the path: RPC calls the default ContactResolver.create() before server startup, and that default requests access when Contacts authorization is undetermined. This read-only Linux review did not execute macOS Contacts APIs, but the linked pull request also supplies a real non-TTY macOS transcript.

Is this the best way to solve the issue?

Yes—the existing skipIfNotDetermined policy is the narrow maintainable remedy because it preserves authorized resolution while avoiding a permission prompt before headless RPC can serve. The linked PR's TTY/non-TTY distinction is the safer compatibility refinement to review.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked fix needs compatibility review to ensure headless RPC avoids permission prompting while interactive terminal use retains the intended Contacts prompt behavior.

Codex review notes: model internal, reasoning high; reviewed against e22dfad8e54e.

Label changes

Label justifications:

• P1: A headless RPC host can remain alive while serving no requests, blocking chat, history, and send operations until external recovery.
• impact:crash-loop: The reported LaunchAgent-style startup wedge leaves the RPC process unavailable and requires watchdog or operator recovery.

Evidence reviewed

What I checked:

• Current RPC startup remains blocking: The command constructs the Contacts resolver with its default policy before creating and running the JSON-RPC server. The default policy requests access when authorization is undetermined, so the reported startup wedge remains on current main. (Sources/imsg/Commands/RpcCommand.swift:26, e22dfad8e54e)
• Fail-open policy already exists: skipIfNotDetermined returns a no-op resolver rather than calling requestAccess, while the default policy remains requestIfNeeded. This establishes a narrow existing-policy path for the fix. (Sources/IMsgCore/ContactResolver.swift:68, e22dfad8e54e)
• Comparable commands already fail open: chats and history initialize Contacts with skipIfNotDetermined, unlike RPC. This independent call-site comparison supports the reported omission. (Sources/imsg/Commands/ChatsCommand.swift:35, e22dfad8e54e)
• Deterministic resolver coverage exists: The current test suite covers the undetermined-permission branch where the fail-open policy must avoid requesting access, providing a stable basis for an RPC-specific regression test. (Tests/IMsgCoreTests/ContactResolverTests.swift:40, e22dfad8e54e)
• Release and current-main comparison: There is no RPC or Contacts-resolver diff between the v0.13.4 release commit and current main, so the affected startup path remains unchanged after that release. (Sources/imsg/Commands/RpcCommand.swift:26, 1d8b679cc3a3)
• Current-file provenance: Blame attributes the present RPC startup lines to the v0.13.4 preparation commit. This is the strongest available local history signal for routing; deeper history could not be hydrated from the promisor remote during review. (Sources/imsg/Commands/RpcCommand.swift:26, 1d8b679cc3a3)

Likely related people:

• Peter Steinberger: Current RPC startup lines are attributed to the v0.13.4 preparation commit, the strongest locally verifiable ownership signal for the affected entrypoint. (role: recent current-file contributor; confidence: medium; commits: 1d8b679cc3a3; files: Sources/imsg/Commands/RpcCommand.swift)
• SebTardif: The open canonical pull request directly targets the RPC Contacts-startup policy and provides the focused implementation and validation approach. (role: implementation candidate author; confidence: medium; commits: b8bcf52b8f94; files: Sources/imsg/Commands/RpcCommand.swift, Sources/IMsgCore/ContactResolver.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.