iMessage problems | Friends of the Crustacean 🦞🤝 | Page 1

fresh patio Apr 19, 2026, 4:11 PM

#

I am trying to configure iMessage using imsg (I do not want to use BlueBubbles because it's not actively supported.) imsg has full disk access as does the Terminal. However, I keep seeing the following errors

11:08:54 AM
error
gateway/channels/imessage
imsg rpc: failed to parse permissionDenied(path: "/Users/openclaw/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
11:08:54 AM
error
gateway/channels/imessage
imsg rpc: failed to parse permissionDenied(path: "/Users/openclaw/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
11:08:55 AM
error
gateway/channels/imessage
imsg rpc: failed to parse permissionDenied(path: "/Users/openclaw/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
11:08:55 AM
error
gateway/channels/imessage
imsg rpc: failed to parse permissionDenied(path: "/Users/openclaw/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON```

How can I fix this?

safe chasmBOT Apr 19, 2026, 4:11 PM

#

slow creekBOT Apr 19, 2026, 4:11 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

snow pierBOT Apr 19, 2026, 4:13 PM

#

That log is mostly a red herring.

The real failure is this part:

permissionDenied(path: "/Users/openclaw/Library/Messages/chat.db", underlying: authorization denied (code: 23))

Unexpected token 'p' just means OpenClaw expected JSON from imsg rpc, but imsg printed a plain-text permission error instead.

Most likely fix:

Please paste openclaw --version first.
Make sure the actual process running OpenClaw has Full Disk Access, not just Terminal.
- If you started it with openclaw gateway install, openclaw onboard --install-daemon, or the Mac app, that is a LaunchAgent/app context, not your shell.
- In that case, granting FDA to Terminal alone is not enough.
In a GUI terminal, same macOS user/session that runs the gateway, run:

#

   imsg chats --limit 1
   imsg send <handle> "test"

Approve any prompts. The first checks DB access, the second checks Automation.
4. Verify the DB path/user is correct. Your log shows:
/Users/openclaw/Library/Messages/chat.db
So Messages must be signed in for the macOS user openclaw, and OpenClaw must run as that same user.
5. Restart the gateway after changing permissions:

openclaw gateway restart

If macOS never re-prompts, remove/re-add the permission entry or reboot once. TCC can get sticky.

Useful docs:

#

https://docs.openclaw.ai/platforms/mac/permissions

If you want, send back these 4 things and I can narrow it down fast:

openclaw --version
openclaw gateway status
imsg chats --limit 1
openclaw channels status --probe

fresh patio Apr 19, 2026, 4:17 PM

#

openclaw --version returns OpenClaw 2026.4.15 (041266a)
openclaw gateway status returns

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-19.log
Command: /opt/homebrew/opt/node@24/bin/node /Users/openclaw/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled. (Run `openclaw gateway install --force` to remove embedded service token.)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 577, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

imsg chats --limit 1 returns [3] (+15555555555) last=2026-04-19T15:45:35.199Z (Note: I replaced my phone number with 5s)
openclaw channels status --probe returns

Gateway reachable.
- Discord default: enabled, configured, running, connected, bot:@Darin, token:env, intents:content=limited, works
- iMessage default: enabled, configured, running, probe failed

snow pierBOT Apr 19, 2026, 4:19 PM

#

Nice, this narrows it down a lot.

Your version looks fine. The key detail is this:

imsg chats --limit 1 works in Terminal
iMessage probe fails when OpenClaw runs as a LaunchAgent
The LaunchAgent command is directly running:
/opt/homebrew/opt/node@24/bin/node ... openclaw ...

So this is almost certainly a macOS TCC / Full Disk Access process-context issue. Terminal has access, but the LaunchAgent-launched Node binary does not.

What to do

Add this exact binary to System Settings → Privacy & Security → Full Disk Access:
- /opt/homebrew/opt/node@24/bin/node
You can keep imsg there too, but the important one is the Node binary, because that is what launchd is executing.

#

Restart the gateway:
```
openclaw gateway restart
```
Probe again:
```
openclaw channels status --probe
```

Fast proof test

If you want to confirm before touching permissions, stop the LaunchAgent and run the gateway manually from the same Terminal where imsg chats works:

openclaw gateway stop

#

openclaw gateway

Then in another terminal:

openclaw channels status --probe

If that works, it confirms the issue is the LaunchAgent/Node permission context.

Also worth knowing

The warning about the embedded gateway token is not what is breaking iMessage. You should still clean it up later with:

#

openclaw doctor --repair

or

openclaw gateway install --force

But that is separate.

Docs:

If you try the Node FDA fix and it still fails, paste the new openclaw channels status --probe output and I’ll keep digging.

fresh patio Apr 19, 2026, 4:48 PM

#

Is it a security risk to give openclaw (node) fill disk access? I specifically set it up on a non-admin user to avoid something like full access

snow pierBOT Apr 19, 2026, 4:49 PM

#

Yes, it is a real security expansion, but your dedicated non-admin user is exactly the right mitigation.

Short version:

Full Disk Access does not make Node admin/root.
It does let that process read protected data available to that macOS account, including the Messages DB and other TCC-protected locations for that user.
So the risk is, “anything OpenClaw can cause that Node process to do can potentially read a lot more of that user’s data.”

A few important nuances:

You already gave Terminal FDA.
That is often broader than granting FDA to the specific Homebrew node binary, because anything you launch from Terminal benefits from Terminal’s permission context.
Using a separate non-admin macOS user is good containment.
That keeps the blast radius to that account’s data, not your main login.
For imsg, there is no real way around FDA for the process context that reads ~/Library/Messages/chat.db. The docs are explicit on that:

#

https://docs.openclaw.ai/channels/imessage

My recommendation

If you want the safest reasonable setup for imsg:

keep the dedicated non-admin macOS user
grant FDA to the specific Node binary used by the LaunchAgent
ideally remove FDA from Terminal afterward, if you do not need it anymore
keep that user otherwise “clean”, minimal apps/data
keep OpenClaw locked down with pairing/allowlists
run:
```
openclaw security audit
```

Docs:

#iMessage problems

What to do

Fast proof test

Also worth knowing

My recommendation