Why does imsg send return success but the message fails to send?

This is a common issue where the AppleScript bridge confirms the command was handed to the system, but the actual dispatch fails at the security layer because the gateway lacks Full Disk Access to the database.

Will granting FDA to Terminal.app solve this?

Yes, for manual execution. It allows the OpenClaw process to inherit the required permissions while debugging or running via a shell.

Is there a permanent fix for macOS 26?

There is no current patch for the underlying OS behavior. The community recommends running the gateway as a User Login Item rather than a system-level LaunchAgent.

Resolving iMessage FDA and Silent Send Issues in OpenClaw

TL;DR — Quick Fix

LaunchAgents lack the inherited Full Disk Access of your user session, preventing database access; run the gateway manually or via a GUI-based LaunchAgent to restore functionality.

Run Diagnostics

Next Step

Fix now, then reduce repeat incidents

If this issue keeps coming back, validate your setup in Doctor first, then harden your config.

Open Doctor Harden Config

Error Signal

imsg send: sent / successError: failed to read ~/Library/Messages/chat.db

What's Happening

You're seeing your imsg send commands return a success status, but the message never reaches the recipient. Simultaneously, your gateway is failing to read the local chat.db because it doesn't have the required permissions. This occurs because macOS 26 is strict about how permissions like Full Disk Access (FDA) are inherited by background processes. When you run OpenClaw as a standard LaunchAgent or a Login Item, it often lacks the necessary security context to interact with the Messages database, leading to silent failures.

The Fix

First, verify if the issue is permissions-related by launching the OpenClaw process directly from your terminal session rather than via the background agent. Run:

npm run start:gateway

If this works, your background agent is the culprit. Since macOS 26 does not allow LaunchAgents to easily inherit Full Disk Access from the system, you must wrap your startup process in a GUI-aware container or a persistent terminal session. Ensure you have granted the terminal emulator (iTerm2 or Terminal) Full Disk Access in System Settings > Privacy & Security > Full Disk Access.

For permanent resolution, avoid using raw LaunchAgents for tools requiring sensitive Apple API access. Use a Login Item application bundle instead of a raw binary, as the bundle approach allows macOS to associate the process with your user's permission set more reliably.

Why This Occurs

The imsg library relies on chat.db access. When your gateway boots in a non-interactive shell (via LaunchAgent), it is effectively sandboxed away from your Messages database. Even if the AppleScript bridge confirms the send command was received by the system, the underlying OS security layer drops the request silently because the originating process lacks the necessary security tokens granted by FDA.

Prevention

Always verify your FDA settings after a macOS update. If you notice silent failures, check your console logs immediately using log stream --predicate 'process == "imsg"'. This will show you exactly where the permission denial occurs. Moving forward, keep your imsg version current via Homebrew, as Apple frequently changes the private API requirements for iMessage integration in newer macOS versions.

Last Updated: March 2026

Did this guide solve your problem?