imsg launch timeout

[crazytomautomation]

macOS 26.5 (25F71) on Apple Silicon.

SIP fully disabled.

imsg 0.9.0 installs and launches, but imsg launch times out waiting for Messages.app initialization.

Evidence collected:

• fs_usage confirms Messages opens imsg-bridge-helper.dylib
• lsof never shows stable dylib attachment
• vmmap $(pgrep Messages) reports:
  "dyld has initialized but libSystem has not"
• Messages appears stalled during bootstrap
• security logs show entitlement/access-group errors (Code=-34018)
• RPC backend launches but never becomes ready

This appears to be a bridge/runtime incompatibility with macOS 26.5 Messages internals rather than a SIP or permissions issue.

[Shelldon-26]

Having a similar issue. Basic functionality works, but not advanced features. imsg launch reports time out waiting for Messages.app even though it appears to be there and available instantly.

Troubleshooting:

• Checked both 'csrutil status' and 'csrutil authenticated-root status' are disabled
• Disabled FileVault
• Checked permissions for Full Disk Access, Accessibility, Automation

Running imsg 0.9.0 and MacOS Tahoe 26.5

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
Keep open under the repo's review-only issue policy, but this looks like the documented macOS 26/Tahoe advanced-IMCore bridge limitation rather than a narrow source fix: the launch path can time out when Apple's library-validation or entitlement gates prevent the helper from becoming ready.

Reproducibility: no. high-confidence live reproduction is available in this Linux review environment. Source inspection confirms the timeout path when the helper never writes the ready lock, and two macOS 26.5 reports provide consistent external evidence.

Ways to help us reproduce this

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

Next step
Needs maintainer/macOS validation rather than an automated PR because the evidence points at Apple-controlled injection or entitlement behavior and current docs already scope that path as unstable.

Review details

Best possible solution:

Let a maintainer decide whether this should remain the macOS 26.5 advanced-bridge tracking report or be closed as the documented Apple-controlled limitation; any code work should be limited to narrow detection or diagnostic improvements unless live macOS evidence shows a repo-fixable failure.

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

No high-confidence live reproduction is available in this Linux review environment. Source inspection confirms the timeout path when the helper never writes the ready lock, and two macOS 26.5 reports provide consistent external evidence.

Is this the best way to solve the issue?

Unclear. Treating this as a normal core bug fix is not currently supported because the docs and prior investigation frame this path as Apple-controlled; a maintainer-approved diagnostic or support-policy decision is safer unless live macOS testing identifies a source-level fix.

Label changes:

• add P3: The report affects optional advanced IMCore launch behavior on macOS 26.5 while normal send, history, and watch flows are documented as unaffected.
• add impact:crash-loop: The issue is about imsg launch timing out while Messages appears stalled during injected startup.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: The report affects optional advanced IMCore launch behavior on macOS 26.5 while normal send, history, and watch flows are documented as unaffected.
• impact:crash-loop: The issue is about imsg launch timing out while Messages appears stalled during injected startup.

Acceptance criteria:

• On macOS 26.5 with SIP disabled and the v0.9.0 helper installed, run imsg launch --json and imsg status --json while collecting redacted Console/security logs for library-validation or Code=-34018 entitlement errors.

What I checked:

• Reporter evidence: The reporter and one commenter both describe macOS 26.5/Tahoe with SIP disabled, basic functionality working, and imsg launch timing out while advanced bridge readiness never arrives.
• Launch timeout source path: imsg launch resolves the helper dylib and calls MessagesLauncher.ensureRunning; MessagesLauncher launches Messages with DYLD_INSERT_LIBRARIES, waits 15 seconds for .imsg-bridge-ready, and throws the exact initialization timeout when that lock never appears. (Sources/IMsgCore/MessagesLauncher.swift:124, c7ae79c1b195)
• CLI launch wrapper: The command surface prints Failed to launch from the thrown launcher error after ensureRunning() fails, matching the user-facing timeout report. (Sources/imsg/Commands/LaunchCommand.swift:109, c7ae79c1b195)
• Documented macOS 26 limitation: The advanced IMCore docs state that macOS 26/Tahoe can reject the injected helper through library validation and imagent private-entitlement checks, and that these features are research/testing oriented rather than stable production functionality. (docs/advanced-imcore.md:30, c7ae79c1b195)
• Troubleshooting scope: Troubleshooting says advanced IMCore failures are most likely SIP, library validation, or macOS 26 imagent entitlement gates, and calls those macOS-level gates that imsg cannot work around. (docs/troubleshooting.md:95, c7ae79c1b195)
• Related prior investigation: Typing indicators broken on macOS 26 (Tahoe) — imagent requires private entitlements #60 and feat: port BlueBubbles private-API surface as imsg bridge (fixes #60) #100 are the earlier Tahoe IMCore entitlement/bridge investigation and shipped bridge work; the remaining theme is the same Apple-controlled advanced-IMCore boundary, though this issue adds newer macOS 26.5 launch-specific evidence.

Likely related people:

• steipete: Current launch/docs blame points at the v0.9.0 release commit, and PR metadata shows follow-up bridge diagnostics, IPC, docs, and release work in this area. (role: recent area contributor; confidence: high; commits: b85e701f2b0b, caac981480df, bd2e036ea6b2; files: Sources/IMsgCore/MessagesLauncher.swift, Sources/IMsgCore/IMCoreBridge.swift, docs/advanced-imcore.md)
• omarshahine: Authored the merged BlueBubbles-inspired v2 bridge work that the current advanced IMCore launch path is trying to activate. (role: bridge feature contributor; confidence: medium; commits: 0ece0cc4d0e6, 574bb2cfa353, e8f3fed5bfc3; files: Sources/IMsgCore/IMsgBridgeClient.swift, Sources/IMsgCore/IMsgBridgeProtocol.swift, Sources/IMsgHelper/IMsgInjected.m)

Remaining risk / open question:

• I could not reproduce the macOS 26.5 launch path from this Linux review environment; the conclusion relies on source inspection plus two consistent reporter logs.
• If Apple library-validation or private-entitlement checks are the blocker, a repo-side fix may be limited to clearer diagnostics or documentation rather than restoring the bridge.

Codex review notes: model gpt-5.5, reasoning high; reviewed against c7ae79c1b195.

[m13v]

the 'not a permissions issue' read doesn't square with Code=-34018, which is errSecMissingEntitlement. SIP off doesn't bypass entitlement checks for IPC into system-signed apps like Messages, that's a separate enforcement path. and 'dyld initialized but libSystem has not' isn't a bridge incompatibility, it's a load-order bug, the helper is running before libSystem finishes bootstrapping. on 26.5 they tightened dyld init order around system apps. constructors touching objc/Foundation would've raced libSystem on older builds too, you just won that race more often.