fix(bridge): repair group add/remove-member on macOS 26 (vend fallback + renamed selectors)

[oficiallyAkshay]

chat-add-member fails with Dylib error: Could not vend handle for every address — including confirmed-reachable iMessage numbers — while chat-create works fine. Root-caused live on macOS 26.0 / imsg 0.13.1 (SIP off, bridge v2) to two stacked bugs in the add path, plus the same class of bug in remove.

1. Handle vend used a no-fallback shortcut

handleAddParticipant called IMHandleRegistrar's IMHandleWithID: directly and bailed on nil. That selector returns nil for many reachable handles; getIMHandlesForID: still resolves them. create-chat already routes through the vendIMHandle() helper (tries both selectors + service match + fallback) — add-member took the shortcut. Fix: route add-member through the same vendIMHandle().

2. Participant-invite selector renamed on macOS 26

Once the vend was fixed, add failed with inviteParticipantsToiMessageChat:reason: not available. IMChat runtime introspection on macOS 26 (Tahoe) shows the selector is now inviteParticipants:reason: (same (NSArray*, NSInteger) shape). Fix: probe for the current selector, fall back to the old name for older macOS.

3. Remove has the identical rename

chat-remove-member fails with removeParticipantsFromiMessageChat:reason: not available; the current selector is removeParticipants:reason:. Fixed the same probe-with-fallback way so remove doesn't regress the instant add works.

Verification (live, macOS 26.0 / imsg 0.13.1)

imsg chat-add-member --chat 'any;+;<guid>' --address +1XXXXXXXXXX --json
=> {"address":"+1XXXXXXXXXX","chatGuid":"any;+;<guid>","added":true}

Participant confirmed in chat.db (chat_handle_join). create / rename / status unaffected.

🤖 Generated with Claude Code

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 18, 2026, 11:11 PM ET / July 19, 2026, 03:11 UTC.

Summary
The PR replaces direct handle lookup for group adds with the existing fallback-capable vending helper and selects modern or legacy IMChat participant-management selectors at runtime.

Reproducibility: no. a high-confidence live reproduction requires a macOS 26 Messages environment. The source path and the contributor's redacted add-member result make the failure mechanism credible, but the checkout cannot independently exercise it.

Review metrics: 1 noteworthy metric.

• Bridge surface: 1 file changed; 31 added, 13 removed. The repair is tightly scoped to the injected private-API bridge, making behavior proof more important than broad integration churn.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦐 gold shrimp
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted runtime proof for successful member removal on macOS 26.
• When available, show a successful run on an older supported macOS release that selects the legacy participant selector.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR body contains a redacted successful add-member result, but no inspectable artifact demonstrates the changed remove-member path or legacy-selector fallback; add redacted terminal output or logs before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P2] This changes calls into undocumented IMChat APIs; without redacted runtime proof of both add and remove on macOS 26 and the legacy fallback, a supported group-management workflow could remain broken after merge.

Maintainer options:

1. Prove both selector paths (recommended)
   Add redacted terminal output or runtime logs showing successful add and remove on macOS 26, and demonstrate the legacy selector fallback on an earlier supported macOS release when available.
2. Accept macOS 26-only evidence
   Maintainers may merge with the documented macOS 26 add/remove proof while explicitly accepting that the old-selector fallback remains source-checked rather than runtime-proven.

Next step before merge

• [P1] The remaining blocker is contributor-supplied real-behavior evidence, which an automated repair lane cannot generate for the contributor's macOS Messages setup.

Security
Cleared: The one-file Objective-C bridge change adds no dependency, workflow, permission, secret, or supply-chain surface.

Review details

Best possible solution:

Keep one shared handle-vending path and runtime selector probing, then land it after redacted evidence shows successful add and remove on macOS 26 plus a legacy-selector-compatible macOS run when available.

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

No; a high-confidence live reproduction requires a macOS 26 Messages environment. The source path and the contributor's redacted add-member result make the failure mechanism credible, but the checkout cannot independently exercise it.

Is this the best way to solve the issue?

Unclear; reusing the existing vending helper and probing selectors is the narrowest maintainable approach, but the remove path and older-runtime fallback still need direct behavior evidence.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P1: The report describes group member add/remove failing for real macOS 26 users, which blocks an established chat-management workflow.
• add merge-risk: 🚨 compatibility: The patch changes private-framework selector and handle-resolution compatibility behavior across macOS versions.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body contains a redacted successful add-member result, but no inspectable artifact demonstrates the changed remove-member path or legacy-selector fallback; add redacted terminal output or logs before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P1: The report describes group member add/remove failing for real macOS 26 users, which blocks an established chat-management workflow.
• merge-risk: 🚨 compatibility: The patch changes private-framework selector and handle-resolution compatibility behavior across macOS versions.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body contains a redacted successful add-member result, but no inspectable artifact demonstrates the changed remove-member path or legacy-selector fallback; add redacted terminal output or logs before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Current-main behavior: The PR diff is against current main commit ca91c41 and replaces the direct IMHandleWithID: add-member lookup plus single legacy participant selectors; this indicates the reported central behavior is not already implemented on main. (Sources/IMsgHelper/IMsgInjected.m:5775, ca91c41b47e0)
• Existing fallback implementation: The existing vendIMHandle helper probes both IMHandleWithID: and getIMHandlesForID:, prefers the requested service, and supports an explicit fallback, so reusing it avoids maintaining a second handle-resolution path. (Sources/IMsgHelper/IMsgInjected.m:3181, ca91c41b47e0)
• Proposed compatibility probe: Commit c7d269f changes one Objective-C bridge file and probes the newer and legacy add/remove selector names before invocation. (Sources/IMsgHelper/IMsgInjected.m:5775, c7d269fbb0cb)
• Contributor runtime claim: The PR body includes a redacted successful macOS 26 add-member command and reports a chat.db confirmation, but it does not provide inspectable output for the corresponding remove-member path or legacy-selector fallback. (c7d269fbb0cb)

Likely related people:

• unknown: The affected injected bridge is centralized in one file, but available review evidence did not establish a reliable current-main author or historical owner without guessing. (role: current-main bridge owner; confidence: low; commits: ca91c41b47e0; files: Sources/IMsgHelper/IMsgInjected.m)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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.