Pulse iMessage send broken on macOS 26.x — Messages.app AppleScript dictionary returns -1728

[janrenz]

Symptom

On macOS 26.5 (Messages.app 26.0), Pulse's iMessage module successfully receives messages via SQLite polling of ~/Library/Messages/chat.db, but fails to send replies. Every reply attempt logs:

Failed to send iMessage to <handle>: ShellError: Failed with exit code 1

The bot otherwise runs end-to-end: chat.db poll fires, allowlist passes, full SDK session executes (5 turns, ~/bin/zsh.61 in my repro), reply text is generated — then the final AppleScript step fails silently from the user's perspective.

Repro

1. Fresh PAI v5.0.0 install on macOS 26.5
2. PULSE.toml [imessage] with enabled = true and an allowed handle (your own phone in E.164 + Apple ID email)
3. Full Disk Access granted to /Users/<you>/.bun/bin/bun (the launchd-supervised binary)
4. Automation permission for bun → Messages granted (or attempted — see below)
5. Send an iMessage from another device with one of the allowlisted handles
6. Observe pulse-stderr.log for the send failure

Root cause: Apple deprecated the AppleScript dictionary entries Pulse relies on

lib/imessage-send.ts uses two paths, both broken on macOS 26.x:

Primary path (buddy-by-handle):

tell application "Messages"
  set targetService to 1st account whose service type = iMessage
  set targetBuddy to participant targetService handle "+..."
  send "..." to targetBuddy
end tell

Direct osascript probe of the dictionary surface returns AppleScript error -1728 ("can't read property"):

execution error: "Messages" got error: "name of account id \"7EF5A58E-...\"" can't read (-1728)

Fallback path (chat-id):

send "..." to chat id "iMessage;-;+..."

Same error class:

execution error: "Messages" got error: "chat id \"iMessage;-;+...\" can't read (-1728)"

Error -1728 is dictionary-level ("property doesn't exist"), not permission (-1743). Granting Automation, reinstalling Messages, restarting with a different Apple ID — none change the outcome on macOS 26.x. The AppleScript verbs themselves were removed/altered.

For context: tell application "Messages" to get name still works (returns "Messages"), so the basic AppleScript bridge is intact. Only the higher-level message-routing verbs are gone.

Suggested fix paths

Path	Effort	Notes
UI scripting via System Events	medium	Open Messages, focus chat for handle, paste text, return. Works on 26.5; window flashes; fragile against UI updates.
Swift CLI shim using IMCore	high	Compile a small native binary linked against the private IMCore framework. Most robust. Needs build infra + signing.
External-channel fallback	low	Make Pulse degrade gracefully: when send fails, surface the reply via voice + a web UI / Telegram instead of silently 502-ing.

A working UI scripting proof on macOS 26.5:

tell application "Messages" to activate
tell application "System Events" to tell process "Messages"
  -- ... navigate sidebar, click compose, type to: field, paste body, return ...
end tell

(Sketch only; the full version needs handle-to-conversation matching, focus management, and timing tolerance.)

Separate but related — a fix I already PR'd

While diagnosing this I found and PR'd an unrelated supervisor restart-loop bug in the same module: #1277. That landed reliably so I split it out — this issue is about the bigger Messages.app 26.x problem.

My environment

• macOS Darwin 25.5.0 / sw_vers ProductVersion: 26.5 / Build 25F71
• Messages.app 26.0
• PAI v5.0.0
• Pulse running as launchd agent com.pai.pulse exec'ing /Users/.../.bun/bin/bun
• Bun 1.3.11 arm64

Happy to test a candidate fix;

[danielmiessler]

Hey @janrenz, thanks for raising this, and sorry it sat for a while.

We're changing how LifeOS ships. Instead of cloning a full ~/.claude directory and running it as a complete system, LifeOS is becoming a skill you install through an agentic installer. The installer hands integration to your own AI, which reads your actual machine (your OS, your paths, your harness) and wires the hooks and system prompt in where they belong.

That's aimed right at what you hit here. The old "one directory, one layout, hope it matches your setup" approach is exactly what broke for so many people, and the new model should handle it far better because your AI does the integration per machine instead of us guessing.

So we're closing this in prep for that release. If it still bites you once the skill-based version is out, reopen or file a fresh one and we'll jump on it. Appreciate you taking the time.