Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: iMessage (imsg) channel - binary length prefix leaking into message content [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#63868•Fetched 2026-04-10 03:41:43
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
clawrenceandthemachineclawrenceandthemachine
Participants
clawrenceandthemachineclawrenceandthemachineneeravmakwananeeravmakwana
Timeline (top)
commented ×1cross-referenced ×1

When receiving messages via the iMessage channel (using the imsg provider), every incoming message has binary junk prepended to the text content. This appears to be a length-prefix from the underlying protobuf/gRPC communication that is not being properly stripped.

Root Cause

Root Cause Hypothesis

The imsg bridge communicates with OpenClaw using protobuf/gRPC. The message payload includes a length-prefix (varint) that should be consumed during deserialization, but it's being passed through to the content instead. The binary bytes appear to be a protobuf varint length prefix that isn't being stripped by the channel handler.

Fix Action

Fixed

PR fix notes

PR #64000: fix(imessage): strip length-prefixed UTF-8 from imsg rpc text

Description (problem / solution / changelog)

Summary

  • Problem: Inbound iMessage notifications from imsg rpc sometimes include a protobuf-style length-delimited UTF-8 blob inside the JSON text (and reply_to_text) string. Those bytes were passed through to the agent as literal prefix garbage.
  • Why it matters: Wastes tokens, breaks tools expecting clean text, and matches reports in #63868.
  • What changed: After validating the RPC payload, strip a leading varint length plus exactly that many following UTF-8 bytes only when they consume the entire field; otherwise leave the string unchanged. Applied to text and reply_to_text.
  • What did NOT change: JSON-RPC transport, outbound send path, and behavior when the field is already plain text.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #63868
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: Upstream imsg may embed a length-delimited UTF-8 payload inside the JSON string; OpenClaw previously forwarded that field with only trim().
  • Missing detection / guardrail: No normalization of text / reply_to_text after parse.
  • Contributing context (if known): Conservative strip only when varint + payload exactly matches full UTF-8 byte length of the string.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: extensions/imessage/src/monitor/strip-imsg-length-prefixed-text.test.ts, extensions/imessage/src/monitor/parse-notification.test.ts
  • Scenario the test should lock in: Length-prefixed wrapper removed; plain text and non-matching layouts preserved.
  • Why this is the smallest reliable guardrail: Pure string transformation with no I/O.
  • Existing test that already covers this (if any): N/A
  • If no new test is added, why not: N/A — tests added.

User-visible / Behavior Changes

Inbound iMessage text and quoted reply text may no longer show a short binary or mojibake prefix when the imsg bridge included a length-delimited UTF-8 wrapper inside the JSON field.

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? (No)
  • New network endpoints or listeners? (No)
  • Touches auth/secrets/pairing? (No)

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/imessage/src/monitor/parse-notification.test.ts (added, +34/-0)
  • extensions/imessage/src/monitor/parse-notification.ts (modified, +12/-1)
  • extensions/imessage/src/monitor/strip-imsg-length-prefixed-text.test.ts (added, +52/-0)
  • extensions/imessage/src/monitor/strip-imsg-length-prefixed-text.ts (added, +80/-0)

Code Example

��Mrrrrow! 🐱 Ich bin wach und bereit!

---

Mrrrrow! 🐱 Ich bin wach und bereit!
RAW_BUFFERClick to expand / collapse

Bug Report: iMessage (imsg) Channel - Binary Length Prefix Leaking into Message Content

Description

When receiving messages via the iMessage channel (using the imsg provider), every incoming message has binary junk prepended to the text content. This appears to be a length-prefix from the underlying protobuf/gRPC communication that is not being properly stripped.

Symptom

Every received message starts with binary characters (hex: variable varint-encoded length prefix) followed by the actual message text.

Example of raw message content:

��Mrrrrow! 🐱 Ich bin wach und bereit!

Expected:

Mrrrrow! 🐱 Ich bin wach und bereit!

Environment

  • OpenClaw version: 2026.4.9 (npm latest)
  • OS: macOS 26.3.1 (arm64)
  • Node: v22.22.1
  • Channel: iMessage (channel: imessage, provider: imsg)
  • imsg CLI: Installed via Homebrew at /opt/homebrew/bin/imsg
  • Gateway: local mode, running via LaunchAgent

Root Cause Hypothesis

The imsg bridge communicates with OpenClaw using protobuf/gRPC. The message payload includes a length-prefix (varint) that should be consumed during deserialization, but it's being passed through to the content instead. The binary bytes appear to be a protobuf varint length prefix that isn't being stripped by the channel handler.

Reproduction Steps

  1. Configure iMessage channel with imsg provider
  2. Send any message to the agent via iMessage
  3. Observe that the message field in context contains binary prefix characters
  4. The prefix is consistent across all messages (typically 2-4 bytes)

Impact

  • Functional: Low - text is still readable
  • UX: High annoyance factor
  • Compatibility: May break tools expecting clean text input
  • Token usage: Wastes tokens on binary data

Related Issues

May be related to other binary injection issues:

  • #5327 - Audio: raw binary injected into context
  • #6869 - Audio files incorrectly detected as text/plain
  • #7333 - Voice message binary leaks into context

Suggested Fix

The iMessage channel handler should properly strip the protobuf length prefix before passing message content to the agent context.

To submit this bug report:

  1. Go to https://github.com/openclaw/openclaw/issues/new?template=bug_report.yml
  2. Copy the content above into the form
  3. Submit the issue

extent analysis

TL;DR

The iMessage channel handler should be updated to properly strip the protobuf length prefix from incoming message content.

Guidance

  • Verify that the imsg provider is correctly configured and updated to the latest version.
  • Check the OpenClaw documentation for any specific settings or configurations related to handling protobuf/gRPC communication with the iMessage channel.
  • Inspect the imsg bridge code to ensure it is correctly consuming the varint length prefix during deserialization.
  • Consider implementing a temporary workaround to strip the binary prefix from incoming messages, such as using a regular expression to remove non-text characters from the beginning of the message content.

Example

// Example of stripping binary prefix using a regular expression
const messageContent = 'Mrrrrow! 🐱 Ich bin wach und bereit!';
const cleanedContent = messageContent.replace(/^[\x00-\x1F]+/, '');
console.log(cleanedContent); // Output: "Mrrrrow! 🐱 Ich bin wach und bereit!"

Notes

The provided example is a temporary workaround and may not be a robust solution. A proper fix would require updating the iMessage channel handler to correctly handle the protobuf length prefix.

Recommendation

Apply workaround: Implement a temporary fix to strip the binary prefix from incoming messages, such as the example provided, until a proper fix can be implemented in the iMessage channel handler.

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…
#inference speed#output truncation#response parsing#generation error#database connection

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: iMessage (imsg) channel - binary length prefix leaking into message content [1 pull requests, 1 comments, 2 participants]