openclaw - 💡(How to fix) Fix iMessage remote-SSH pattern can fail when macOS assigns Automation permission to sshd-keygen-wrapper

Summary

The documented iMessage "Remote Mac over SSH" / dedicated bot macOS user pattern can fail for outbound sends on macOS when Automation permission is assigned to /usr/libexec/sshd-keygen-wrapper and the System Settings UI does not allow enabling Messages for that client.

In this state, inbound/read/probe flows work, but any outbound send through the SSH wrapper fails with AppleEvents -1743.

Environment

• OpenClaw v2026.5.6
• imsg 0.5.0
• macOS host with two users:
  • gateway user runs OpenClaw
  • bot user is signed into Messages/iMessage
• channels.imessage.cliPath points to an SSH wrapper that runs imsg as the bot user on the same Mac:

#!/usr/bin/env bash
exec ssh -o BatchMode=yes -T [email protected] /opt/homebrew/bin/imsg "$@"

Representative config:

{
  "channels": {
    "imessage": {
      "enabled": true,
      "cliPath": "/Users/<gateway-user>/.openclaw/scripts/imsg-bot",
      "remoteHost": "[email protected]",
      "dbPath": "/Users/bot/Library/Messages/chat.db"
    }
  }
}

What works

• imsg chats --limit 1 through the wrapper
• openclaw channels status --probe
• Direct OpenClaw probeIMessage(...)
• watch.subscribe / watch.unsubscribe through imsg rpc
• Inbound iMessage processing reaches OpenClaw

What fails

Outbound sends through the same wrapper fail:

appleScriptFailure("835:879: execution error: Not authorized to send Apple events to Messages. (-1743)")

OpenClaw logs also show final replies failing with:

imessage final reply failed: Error: Internal error: code=-32603 AppleScript failed: 835:879: execution error: Not authorized to send Apple events to Messages. (-1743)

TCC / Automation observations

The bot user's TCC database records Automation for Messages under the SSH server-side process, not under imsg itself:

kTCCServiceAppleEvents | /usr/libexec/sshd-keygen-wrapper | client_type=1 | auth_value=0 | auth_reason=9 | com.apple.MobileSMS

Other local GUI contexts can be allowed, e.g. Terminal -> Messages, but that does not help the SSH wrapper context.

Attempted doc-style recovery:

1. Log into the bot macOS GUI session.
2. Run the same SSH command from an interactive bot Terminal:

ssh -T [email protected] /opt/homebrew/bin/imsg send --chat-id 1 --text "OpenClaw setup test"

1. Reset AppleEvents with tccutil reset AppleEvents and retry.
2. Try enabling Messages for sshd-keygen-wrapper in System Settings -> Privacy & Security -> Automation.

Result: the command continues to fail with -1743, and the UI shows/records the sshd-keygen-wrapper client but does not allow enabling Messages for it.

Expected behavior / docs request

The docs currently say the SSH wrapper pattern is supported and that missed macOS permission prompts can be fixed by re-running in an interactive GUI terminal in the same user/session context.

It would be helpful for the docs to call out this macOS edge case explicitly:

• Remote-SSH iMessage may be able to read/watch but fail to send if AppleEvents permission lands on /usr/libexec/sshd-keygen-wrapper.
• The System Settings UI may not provide a usable way to grant Messages Automation to that client.
• Recommended fallback may be to run the OpenClaw gateway / imsg in the logged-in bot user's local process context using the local Mac fast path, or to keep using BlueBubbles where it already has Automation approval.

Docs referenced:

• https://docs.openclaw.ai/channels/imessage#remote-mac-over-ssh
• https://docs.openclaw.ai/channels/imessage#requirements-and-permissions-macos