Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix BlueBubbles inbound attachments broken after 2026.4.5 upgrade [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#61861•Fetched 2026-04-08 02:53:24
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
2
Author
jmnickelsjmnickels
Participants
jmnickelsjmnickelsJodameisterJodameister
Timeline (top)
commented ×1

Error Message

  1. Private network blocking (partially fixed): The upgrade introduced a security policy blocking localhost URL fetches. Error: [security] blocked URL fetch (bluebubbles-api) target=http://localhost:1234/api/v1/ping reason=Blocked hostname or private/internal/special-use IP address. Fixed by setting channels.bluebubbles.network.dangerouslyAllowPrivateNetwork: true.

Root Cause

Root cause investigation

  1. Private network blocking (partially fixed): The upgrade introduced a security policy blocking localhost URL fetches. Error: [security] blocked URL fetch (bluebubbles-api) target=http://localhost:1234/api/v1/ping reason=Blocked hostname or private/internal/special-use IP address. Fixed by setting channels.bluebubbles.network.dangerouslyAllowPrivateNetwork: true.

Fix Action

Workaround

None found. Images sent via iMessage are not visible to the agent.

PR fix notes

PR #67510: fix(bluebubbles): restore inbound image attachments and accept updated-message events

Description (problem / solution / changelog)

Summary

Four interconnected fixes for BlueBubbles inbound media that together restore image attachment handling on Node 22+:

  1. Strip bundled-undici dispatcher from non-SSRF fetch path — blueBubblesFetchWithTimeout's non-SSRF fallback was spreading a bundled-undici dispatcher into globalThis.fetch(), which Node 22's built-in undici rejects with TypeError: invalid onRequestStart method. This silently broke ALL inbound attachment downloads. (#64105, #61861, #67241, #62530)

  2. Accept updated-message events carrying attachments — BlueBubbles fires updated-message when attachments are indexed after the initial new-message (which may arrive with attachments: []). The webhook handler was filtering these out as non-reaction events. (#65430)

  3. Event-type-aware dedup key — the persistent GUID dedup now suffixes updated-message keys with :updated so follow-up attachment events aren't rejected as duplicates of the already-committed new-message. (Relates to #52277)

  4. Retry attachment fetch for empty arrays — when the initial webhook arrives with empty attachments (image-only messages or updated-message events), waits 2s and re-fetches from the BB API as a fallback. (Relates to #67437)

Test plan

  • pnpm tsgo — no new type errors
  • pnpm test extensions/bluebubbles/ — 434 tests pass (9 new tests added)
  • Manual: send standalone image via iMessage → agent receives and processes it
  • Manual: send text + image together → agent receives both
  • pnpm build — verify no [INEFFECTIVE_DYNAMIC_IMPORT] warnings

Issues closed

Closes #64105, closes #61861, closes #65430, closes #67241, closes #62530.

Related issues (not fixed by this PR)

  • #34749 — image attachments blocked by SSRF guard (localhost URL) — partially addressed by the dispatcher fix, but the broader SSRF allowlist for localhost BB servers is a separate concern
  • #57181 — SSRF guard blocks BB plugin internal API calls to private IP — same broader SSRF allowlist issue
  • #59722 — SSRF allowlist doesn't cover reactions — separate SSRF scope gap
  • #60715 — BB health check fails on LAN/private serverUrl — separate SSRF/health-check issue

Superseded PRs

  • #66120 — accept updated-message events carrying attachments (fully subsumed by fix #2)
  • #67437 — retry attachment fetch when webhook arrives with empty array (fully subsumed by fix #4)
  • #66108 — route fetchImpl through bundled undici fetch on Node 24+ (different approach to same dispatcher issue, subsumed by fix #1)

Related PRs

  • #52277 — dedupe webhook replays without dropping edits (assigned to @omarshahine, complementary finer-grained edit dedup)

🤖 Generated with Claude Code

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/bluebubbles/src/attachments.test.ts (modified, +88/-1)
  • extensions/bluebubbles/src/attachments.ts (modified, +52/-2)
  • extensions/bluebubbles/src/inbound-dedupe.test.ts (modified, +36/-0)
  • extensions/bluebubbles/src/inbound-dedupe.ts (modified, +15/-3)
  • extensions/bluebubbles/src/monitor-normalize.ts (modified, +5/-1)
  • extensions/bluebubbles/src/monitor-processing.ts (modified, +50/-6)
  • extensions/bluebubbles/src/monitor.ts (modified, +13/-3)
  • extensions/bluebubbles/src/types.ts (modified, +9/-1)
  • scripts/check-no-raw-channel-fetch.mjs (modified, +1/-1)

Code Example

{
  "channels": {
    "bluebubbles": {
      "enabled": true,
      "serverUrl": "http://localhost:1234",
      "webhookPath": "/bluebubbles-webhook",
      "network": {
        "dangerouslyAllowPrivateNetwork": true
      },
      "mediaLocalRoots": ["/Users/jovie/.openclaw/media"]
    }
  }
}
RAW_BUFFERClick to expand / collapse

BlueBubbles inbound attachments broken after 2026.4.5 upgrade

Environment

  • OpenClaw 2026.4.5 (upgraded from 2026.3.22)
  • BlueBubbles 1.9.9, Private API enabled
  • macOS 26.3.1, Apple Silicon (M3 Ultra)
  • BB webhook registered with new-message event, delivering to http://127.0.0.1:18789/bluebubbles-webhook

Problem

After upgrading to 2026.4.5, inbound iMessage images are no longer delivered to the agent. Messages arrive with <media:image> placeholder tags but no actual image data or file path. The ~/.openclaw/media/inbound/ directory shows no new files since the upgrade.

Root cause investigation

  1. Private network blocking (partially fixed): The upgrade introduced a security policy blocking localhost URL fetches. Error: [security] blocked URL fetch (bluebubbles-api) target=http://localhost:1234/api/v1/ping reason=Blocked hostname or private/internal/special-use IP address. Fixed by setting channels.bluebubbles.network.dangerouslyAllowPrivateNetwork: true.

  2. Attachments still not downloading: Even after enabling private network access, no attachment download attempts appear in gateway logs. The BB webhook payload includes the message text but OpenClaw doesn't attempt to fetch the attachment from BB's API. No errors related to attachment downloads appear in gateway.err.log.

  3. BB server is healthy: GET /api/v1/server/info returns 200, Private API is active, webhook is registered with correct events.

Expected behavior

Inbound images should be downloaded from BB and saved to ~/.openclaw/media/inbound/, then delivered as image content to the agent (as they were on 2026.3.22).

Config

{
  "channels": {
    "bluebubbles": {
      "enabled": true,
      "serverUrl": "http://localhost:1234",
      "webhookPath": "/bluebubbles-webhook",
      "network": {
        "dangerouslyAllowPrivateNetwork": true
      },
      "mediaLocalRoots": ["/Users/jovie/.openclaw/media"]
    }
  }
}

Workaround

None found. Images sent via iMessage are not visible to the agent.

extent analysis

TL;DR

Enable debugging logs for the BlueBubbles channel to investigate why attachment downloads are not being attempted.

Guidance

  • Verify that the mediaLocalRoots configuration is correctly set and the directory ~/.openclaw/media/inbound/ is writable by the OpenClaw process.
  • Check the BlueBubbles API documentation to ensure that the new-message event includes the necessary information for OpenClaw to download attachments.
  • Investigate the OpenClaw gateway logs for any errors or warnings related to the BlueBubbles channel or attachment handling, even if not immediately apparent.
  • Consider adding additional logging or debugging statements to the OpenClaw code to trace the flow of incoming messages and attachment handling.

Example

No code snippet is provided as the issue does not imply a specific code change.

Notes

The root cause of the issue is unclear, and further investigation is needed to determine why attachment downloads are not being attempted. The provided configuration and setup appear to be correct, but additional logging and debugging may be necessary to identify the issue.

Recommendation

Apply workaround by enabling debugging logs for the BlueBubbles channel to gather more information about the issue. This will help to identify the root cause and potentially lead to a solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Inbound images should be downloaded from BB and saved to ~/.openclaw/media/inbound/, then delivered as image content to the agent (as they were on 2026.3.22).

#api#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING