rpc daemon inherits benign Apple Contacts.framework 'Could not fetch group … :ABGroup' stderr noise when CardDAV accounts are present (docs suggestion)

[prashantkamani]

Summary (docs suggestion — no code change requested)

On macOS hosts with third-party CardDAV contact accounts (Google, Yahoo, etc.), the long-lived imsg rpc --json daemon's stderr periodically carries Apple Contacts-framework noise like:

2026-08-04 00:32:38.518 imsg[88305:38969629] Could not fetch group for change type 1 with identifier <UUID>:ABGroup, making it a delete change type.

Roughly one line per contacts account per Contacts sync (~hourly), indefinitely. On our host (imsg 0.13.0, 4 CardDAV accounts): ~130 lines/day, steady for a month.

What it is (verified at v0.13.0, fa2f82d)

• imsg links Contacts.framework for ContactResolver name resolution. Apple's change-history reconciliation runs in-process in any client of that framework, and logs this line (unified-log level Default) when it can't materialize an account's container/default group. The records are active; "delete change type" is the framework's designed fallback wording, not an actual deletion.
• No imsg code is involved — the repo has no CNChangeHistory/group usage anywhere; the string isn't in the shipped binary. Messaging is completely unaffected.
• Not TCC: verified granted with zero denials on our host. (So fix(rpc): do not block startup on undetermined Contacts auth #187's TTY-conditional contacts skip doesn't apply — an authorized headless daemon still loads contacts and still inherits this noise.)

Suggestion

A short note in docs/permissions.md (Contacts section) along the lines of: "With CardDAV accounts (Google/Yahoo/etc.), Apple's Contacts framework periodically writes benign Could not fetch group … :ABGroup reconciliation notes to the daemon's stderr. This is expected, harmless, and not produced by imsg. Host processes that capture imsg's stderr should not surface these lines at error level."

Context: OpenClaw currently blanket-logs imsg stderr at ERROR (openclaw/openclaw#79610, fix never merged — follow-up filed as openclaw/openclaw#119282), so every OpenClaw+imsg user with such accounts eventually walks this same diagnostic path. A docs note here would short-circuit it.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 5, 2026, 7:34 AM ET / 11:34 UTC.

Summary
Keep open as a focused documentation clarification: current main still loads Contacts for authorized RPC sessions, and the Permissions guide does not explain this reported CardDAV-related stderr diagnostic.

Reproducibility: no. live reproduction is available from this Linux review environment; current source does confirm that authorized RPC sessions load the macOS Contacts resolver before serving requests.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
The one-file documentation update has a clear boundary; verify the wording with a redacted macOS/CardDAV capture before publishing it.

Review details

Best possible solution:

Add a narrowly scoped Contacts-permissions troubleshooting note that distinguishes the named CardDAV diagnostic from imsg failures and advises stderr collectors not to treat it as an imsg error.

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

No live reproduction is available from this Linux review environment; current source does confirm that authorized RPC sessions load the macOS Contacts resolver before serving requests.

Is this the best way to solve the issue?

Yes; a qualified Permissions note is the narrowest maintainable response because no owned parsing or message-delivery behavior is implicated.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The Apple diagnostic was not reproducible from this Linux checkout, so the documentation should remain qualified to the named CardDAV/macOS condition and avoid promising universal framework behavior.

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

Label changes

Label justifications:

• P3: A small documentation clarification reduces misleading host-log alerts without changing message delivery.
• impact:ux-friction: The framework noise can cause avoidable operator confusion when host software surfaces stderr as an error.

Evidence reviewed

Acceptance criteria:

• make lint
• make test
• On an affected macOS/CardDAV host, capture a redacted imsg rpc --json stderr example and confirm normal message operations remain unaffected.

What I checked:

• Documentation gap on current main: The Contacts permissions section describes authorization and unavailable-name behavior but does not mention CardDAV-related framework diagnostics or their stderr implications. (docs/permissions.md:37, 9392815f76f0)
• Authorized Contacts path remains active: When Contacts authorization is granted, the resolver loads the system contact store; this is the path that can invoke Apple Contacts.framework during RPC startup. (Sources/IMsgCore/ContactResolver.swift:97, 9392815f76f0)
• RPC initializes the resolver before serving: RPC creates the contact resolver before constructing and running its server, while only the undetermined-permission path is skipped for headless stdin. (Sources/imsg/Commands/RpcCommand.swift:45, 9392815f76f0)
• Relevant feature history: The current RPC Contacts-policy behavior dates to the merged headless-Contacts change, which is adjacent to but does not address this authorized-Contacts diagnostic. (Sources/imsg/Commands/RpcCommand.swift:46, 2fac78e96c1c)
• Release boundary checked: The latest tagged release, v0.13.4, predates the adjacent RPC Contacts-policy commit; no tag in this checkout contains that commit, so it does not establish that the requested documentation is already shipped. (CHANGELOG.md:14, 2fac78e96c1c)

Likely related people:

• SebTardif: Authored the merged current-main RPC Contacts startup policy that owns the adjacent resolver initialization behavior. (role: recent RPC Contacts-path contributor; confidence: high; commits: 2fac78e96c1c; files: Sources/imsg/Commands/RpcCommand.swift, Tests/imsgTests/RpcCommandContactsPolicyTests.swift)
• Peter Steinberger: Current Permissions-guide lines blame to the v0.13.4 release preparation, and recent main history includes repository documentation work. (role: recent documentation and release contributor; confidence: medium; commits: 1d8b679cc3a3, 9392815f76f0; files: docs/permissions.md, README.md)

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.