fix(imessage): honor block streaming config by jmissig · Pull Request #91449 · openclaw/openclaw

jmissig · 2026-06-08T14:59:45Z

Summary

What problem does this PR solve?

Fixes the iMessage bug where enabling the existing, schema-valid flat config channels.imessage.blockStreaming: true did not make iMessage send interim/progress block replies before the final answer.
Routes iMessage inbound reply dispatch through the shared block-streaming resolver so the configured block-streaming decision is applied consistently instead of depending on the old iMessage-only direct field check.
Adds iMessage support for the shared nested/canonical delivery streaming config shape, including channels.imessage.streaming.block.enabled, because moving iMessage onto the shared resolver path needs the shared shape to pass schema/config validation and precedence tests.
Preserves explicit account-level flat blockStreaming opt-ins/opt-outs when inheriting channel-level nested streaming config.
Keeps focused coverage around iMessage monitor dispatch, channel delivery streaming schema, chunk mode resolution, and block-streaming coalescing lookup.

Why does this matter now?

In the local real iMessage environment, channels.imessage.blockStreaming: true was enabled and valid, but iMessage still behaved as if block streaming was off: longer turns often produced no visible outbound iMessage until the final answer.
This PR starts from that flat-config behavior bug. The nested/canonical support is included so iMessage can use the same validated shared resolver path as other channels; it is not the user-facing reason for the fix and does not require users to migrate config.

What is the intended outcome?

Existing flat channels.imessage.blockStreaming: true config works for iMessage delivery.
iMessage can use the same delivery streaming config resolver as other channels.
Existing flat blockStreaming settings continue to work.
Nested streaming.block.enabled and mixed channel/account configs behave predictably because the shared resolver path requires those cases to be valid and tested.

What is intentionally out of scope?

Requiring users to migrate to nested streaming.block.enabled for iMessage block streaming.
Reworking block streaming delivery semantics across all channels.
Full local broad-suite validation; broad validation is left to Testbox/CI.

What does success look like?

With existing flat channels.imessage.blockStreaming: true, iMessage can emit interim/progress replies before final answers.
The iMessage monitor uses the shared block-streaming config resolver.
iMessage schema/types accept the shared nested delivery streaming shape required by that resolver path.
Flat and nested channel/account precedence is covered by focused tests.

What should reviewers focus on?

Whether the shared resolver is the right way to make iMessage honor existing flat block-streaming config.
Whether the nested schema/type additions are the right minimal support needed for shared config validation.
Whether maintainers accept the flat/nested precedence contract for iMessage.
Whether the iMessage account merge preserves explicit account overrides while inheriting channel streaming settings.

Linked context

Which issue does this close?

N/A

Which issues, PRs, or discussions are related?

Related #62387

Was this requested by a maintainer or owner?

No public issue link yet; this came from local real-world iMessage behavior while preparing the fix.

Real behavior proof (required for external PRs)

Behavior addressed: Enabling the existing flat iMessage config channels.imessage.blockStreaming: true did not work in real iMessage delivery: iMessage could stay silent until the final answer instead of sending interim/progress block replies.

Real environment tested: Local OpenClaw running on Saga with the real iMessage channel and Apple Messages delivery. The local behavior evidence used the installed schema-valid config shape channels.imessage.blockStreaming: true, channels.imessage.streaming: null, channels.imessage.chunkMode: "newline".

Exact steps or command run after this patch:

node scripts/run-vitest.mjs run extensions/imessage/src/config-schema.test.ts src/auto-reply/chunk.test.ts src/auto-reply/reply/block-streaming.test.ts extensions/imessage/src/monitor.last-route.test.ts
npm run config:channels:check
node scripts/run-bundled-extension-oxlint.mjs
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test.tsbuildinfo

Evidence after fix: Redacted Apple Messages chat.db timestamp extract from the real iMessage channel, cross-checked with the OpenClaw session/log snippet text:

After-fix evidence - Sun 2026-06-07, real iMessage channel
Config evidence:
channels.imessage.blockStreaming: true
channels.imessage.streaming: null
channels.imessage.chunkMode: "newline"

Apple Messages chat.db:
08:32:02 inbound from user: [redacted weather forecast follow-up]
08:32:15 outbound from Robut: [progress/ack begins: "I'll sanity-check the latest Bay Area forecast..."]
08:33:27 outbound from Robut: [final answer begins: "Yep, the forecast basically..."]
First outbound gap: about 13 seconds after inbound.
Final answer gap: about 72 seconds after the first outbound.
Apple Messages shows platform-visible outbound iMessages leaving during the reply, before the final answer.

OpenClaw-side log:
15:32:03Z session started / prompt submitted for iMessage group turn
15:32:15Z message tool call: "I'll sanity-check the latest Bay Area forecast..."
15:32:22Z first research/tool command after visible progress reply
15:32:28Z web_search call after visible progress reply
15:32:35Z..15:33:12Z clime/weather/API/web evidence-gathering tool calls
15:33:27Z message tool call: "Yep, the forecast basically..."
15:33:29Z model completed / session ended

Observed result after fix: In the local real iMessage environment, the existing flat channels.imessage.blockStreaming: true setup produced an interim/progress iMessage before the final answer.

What was not tested: Full pnpm build && pnpm check && pnpm test was not run locally; broad validation is delegated to Testbox/CI. No gateway restart was performed during the local config correction.

Proof limitations or environment constraints: Apple Messages chat.db proves platform-visible send timing, not the exact in-process object lookup. Current main source has an apparent direct flat lookup, but the real flat-config behavior remained broken. This patch moves iMessage to the shared resolver path, keeps flat config supported, and adds the nested/canonical schema/type support needed for shared validation tests and precedence coverage.

Before evidence (optional but encouraged):

Pre-change config evidence:
channels.imessage.blockStreaming: true
channels.imessage.streaming: null
channels.imessage.chunkMode: "newline"

Example 1 - Sat 2026-06-06, real iMessage channel
Apple Messages chat.db:
10:52:50 inbound from user: [redacted Saturday review follow-up]
10:54:54 first outbound from Robut: [final answer begins: "Done. I patched both Saturday jobs..."]
Gap: about 124 seconds.
Apple Messages had no outbound Robut iMessage rows between the inbound and first outbound rows.

OpenClaw-side session log:
17:52:51Z user prompt: [redacted Saturday review follow-up]
17:53:00Z first internal cron/tool call
17:53:17Z..17:54:43Z multiple internal cron/bash/apply_patch calls completed before any visible message send
17:54:54Z first assistant text: "Done. I patched both Saturday jobs..."
17:54:58Z later tool/message work after the first visible text
No `message` tool call appears between the user prompt and the final answer text.

Example 2 - Sat 2026-06-06, real iMessage channel
Apple Messages chat.db:
11:24:15 inbound from user: [redacted lunch/place recommendation follow-up]
11:26:12 first outbound from Robut: [final recommendation answer begins]
Gap: about 117 seconds.
Apple Messages had no outbound Robut iMessage rows between the inbound and first outbound rows.

OpenClaw-side session log:
18:24:16Z user prompt: [redacted lunch/place recommendation follow-up]
18:24:51Z first internal bash/tool call
18:25:00Z..18:26:07Z local Swarm queries plus web_search calls completed before any visible message send
18:26:12Z first assistant text: [final recommendation answer begins]
18:26:17Z later tool/message work after the first visible text
No `message` tool call appears between the user prompt and the final answer text.

Tests and validation

Which commands did you run?

node scripts/run-vitest.mjs run extensions/imessage/src/config-schema.test.ts src/auto-reply/chunk.test.ts src/auto-reply/reply/block-streaming.test.ts extensions/imessage/src/monitor.last-route.test.ts
npm run config:channels:check
node scripts/run-bundled-extension-oxlint.mjs
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test.tsbuildinfo

What regression coverage was added or updated?

iMessage monitor coverage asserts flat blockStreaming true/false, nested true/false, and unset block-streaming config are passed through to reply dispatch.
iMessage account coverage asserts account-level flat blockStreaming opt-ins/opt-outs override inherited channel-level nested streaming.block.enabled when the account lacks its own nested block setting.
iMessage account coverage asserts channel-level nested streaming.block.enabled survives partial account-level streaming overrides such as chunkMode or block.coalesce.
iMessage config schema coverage accepts the shared structured delivery streaming shape so the shared resolver path has a valid nested representation to test.
Shared chunk/block-streaming coverage checks channel/account scoped delivery streaming settings and coalescing lookup.

What failed before this fix, if known?

Real local behavior: with schema-valid flat channels.imessage.blockStreaming: true, multiple iMessage turns had no visible outbound iMessage until the final answer.
Source-level current main gap: iMessage schema/types do not accept the shared nested delivery streaming object, and the monitor does not use the shared resolver.
Current main source has an apparent direct flat blockStreaming lookup, but the real flat-config behavior remained broken; this PR keeps the flat behavior supported and covered while moving iMessage to the shared resolver path.

If no test was added, why not?

Not applicable; focused regression tests were added.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes. iMessage should now honor the existing flat block-streaming config in real delivery and can also honor nested/canonical block streaming config, allowing interim/progress replies before final answers when the effective config enables block streaming.

Did config, environment, or migration behavior change? (Yes/No)

Yes. iMessage now accepts the shared nested streaming delivery config shape so shared config validation and precedence coverage can exercise that path. Existing flat blockStreaming config remains supported and does not require migration.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No.

What is the highest-risk area?

iMessage reply delivery timing/config resolution. The risk is accidentally disabling block streaming when a user configured it, or enabling it when a user explicitly disabled it.

How is that risk mitigated?

The iMessage monitor now uses the shared resolver and tests cover enabled, disabled, nested, unset, account flat override, and account-inherited nested cases before dispatch.

Current review state

What is the next action?

Wait for CI/Testbox and maintainer review.

What is still waiting on author, maintainer, CI, or external proof?

CI/Testbox: broad validation such as pnpm build && pnpm check && pnpm test.
Maintainer/reviewer: confirm the scoped resolver use and flat/nested precedence contract are the right fix shape.

Which bot or reviewer comments were addressed?

Local codex review --base origin/main first found one P2 around partial account-level nested streaming overrides dropping inherited channel-level streaming.block.enabled. Addressed by deep-merging the iMessage delivery streaming subtree during account config resolution and adding focused account-inheritance monitor tests.
ClawSweeper then found that account-level flat blockStreaming opt-outs could be overridden by inherited channel nested config. Addressed by preserving explicit account-level flat blockStreaming when inheriting nested channel streaming and adding focused regression coverage.
ClawSweeper later asked for the PR body to distinguish current main's apparent flat lookup from the novel nested/canonical support. Addressed by starting the body from the real flat-config breakage, and by framing nested support as required for shared resolver validation rather than as the user-facing fix.

Follow-up codex review --base origin/main result: no actionable regressions found.

clawsweeper · 2026-06-08T15:01:58Z

Codex review: needs maintainer review before merge. Reviewed June 8, 2026, 12:04 PM ET / 16:04 UTC.

Summary
The PR routes iMessage inbound dispatch through the shared streaming block resolver, adds nested iMessage delivery streaming config support, and extends focused schema, resolver, chunking, and monitor tests.

PR surface: Source +97, Tests +314, Generated +1. Total +412 across 10 files.

Reproducibility: yes. for the source-level gap: current main's iMessage monitor only reads flat accountInfo.config.blockStreaming, while the shared resolver can honor nested streaming.block.enabled and flat fallback. The real pre/post iMessage timing proof is supplied in the PR body rather than reproduced locally in this read-only review.

Review metrics: 1 noteworthy metric.

iMessage config surface: 1 nested delivery streaming subtree added. The PR makes channels.imessage.streaming and account-level iMessage streaming config schema-valid, which is compatibility-sensitive even though flat blockStreaming remains supported.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P2] Resolve or explain the current failing checks-node-agentic-commands-status-tools check-run before merge.
Have maintainers explicitly accept the iMessage nested streaming config and flat/nested precedence contract.

Mantis proof suggestion
A short real iMessage or desktop Messages proof would materially demonstrate the visible interim-message behavior, although the supplied redacted database/log proof is already sufficient for ClawSweeper's evidence gate. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: verify iMessage with channels.imessage.blockStreaming=true sends an interim/progress message before the final reply.

Risk before merge

[P1] This PR adds and accepts a new nested channels.imessage.streaming delivery config subtree, so maintainers should explicitly accept the flat/nested precedence contract before merge.
[P1] The change intentionally makes iMessage send interim/progress replies before the final answer when effective block streaming is enabled; that is desired for the bug but still changes visible delivery timing.
[P1] Latest head still has one failing check-run, checks-node-agentic-commands-status-tools, which should be resolved or confirmed unrelated before landing.

Maintainer options:

Accept the iMessage streaming contract before merge (recommended)
Maintainers can accept the added nested channels.imessage.streaming shape and the tested precedence that nested account config wins, then flat account blockStreaming overrides inherited channel nested config.
Keep only the flat bug fix for now
If the nested config surface is not ready, ask for a narrower revision that routes flat blockStreaming through a shared helper without accepting the new iMessage streaming subtree.
Pause until CI is clean
If the current failing check remains unexplained, hold merge until the failing checks-node-agentic-commands-status-tools lane is green or clearly unrelated.

Next step before merge

[P2] No narrow ClawSweeper repair remains; maintainers need to accept the compatibility-sensitive iMessage config contract and ensure required checks are green.

Security
Cleared: The diff changes iMessage config resolution, schema/types, generated config metadata, and tests; I found no new secrets, dependency, workflow, install, or code-execution surface.

Review details

Best possible solution:

Land this after maintainer acceptance of the iMessage flat/nested streaming precedence contract and green required checks, keeping flat blockStreaming supported while using the shared resolver path.

Do we have a high-confidence way to reproduce the issue?

Yes for the source-level gap: current main's iMessage monitor only reads flat accountInfo.config.blockStreaming, while the shared resolver can honor nested streaming.block.enabled and flat fallback. The real pre/post iMessage timing proof is supplied in the PR body rather than reproduced locally in this read-only review.

Is this the best way to solve the issue?

Yes, with maintainer acceptance of the config contract: using the existing shared resolver is the cleanest owner-boundary fix, and the latest account merge preserves flat account overrides. The only safer alternative is a narrower flat-only fix if maintainers reject adding nested iMessage streaming config now.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 57633c42b647.

Label changes

Label changes:

add proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies after-fix real iMessage proof from Apple Messages chat.db timing plus OpenClaw logs showing an interim outbound message before the final reply with flat block streaming enabled.

Label justifications:

P2: This is a normal-priority iMessage delivery/config correctness fix with limited channel blast radius but real user-visible impact.
merge-risk: 🚨 compatibility: The diff adds a new accepted iMessage config subtree and defines precedence between nested and flat channel/account settings.
merge-risk: 🚨 message-delivery: The diff changes when iMessage sends visible interim/progress replies before final answers for users with block streaming enabled.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (logs): The PR body supplies after-fix real iMessage proof from Apple Messages chat.db timing plus OpenClaw logs showing an interim outbound message before the final reply with flat block streaming enabled.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies after-fix real iMessage proof from Apple Messages chat.db timing plus OpenClaw logs showing an interim outbound message before the final reply with flat block streaming enabled.

Evidence reviewed

PR surface:

Source +97, Tests +314, Generated +1. Total +412 across 10 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	5	101	4	+97
Tests	4	330	16	+314
Docs	0	0	0	0
Config	0	0	0	0
Generated	1	13	12	+1
Other	0	0	0	0
Total	10	444	32	+412

Acceptance criteria:

[P1] node scripts/run-vitest.mjs run extensions/imessage/src/config-schema.test.ts src/auto-reply/chunk.test.ts src/auto-reply/reply/block-streaming.test.ts extensions/imessage/src/monitor.last-route.test.ts.
[P1] npm run config:channels:check.
[P1] node scripts/run-bundled-extension-oxlint.mjs.
[P1] node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo.
[P1] node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test.tsbuildinfo.

What I checked:

Current main flat-only dispatch: Current main computes iMessage disableBlockStreaming directly from accountInfo.config.blockStreaming, so nested streaming.block.enabled cannot affect the monitor dispatch path. (extensions/imessage/src/monitor/monitor-provider.ts:1207, 538d36eaaaa6)
Shared resolver precedence: The shared resolver checks streaming.block.enabled first and then falls back to flat blockStreaming, matching the PR's intended canonical/nested then legacy-flat precedence. (src/channels/streaming.ts:672, 57633c42b647)
PR head dispatch change: At PR head, iMessage resolves configured block streaming once through resolveChannelStreamingBlockEnabled(accountInfo.config) and inverts that result for reply dispatch. (extensions/imessage/src/monitor/monitor-provider.ts:1136, 78595d98d69c)
PR head account precedence repair: The latest PR head merges channel and account streaming objects while preserving explicit flat account blockStreaming overrides when the account does not set nested streaming.block.enabled, addressing the earlier review comment. (extensions/imessage/src/accounts.ts:52, 78595d98d69c)
Focused regression coverage: PR-head monitor tests cover flat true/false, nested true/false, unset config, flat account override of channel nested config, and partial account streaming overrides that inherit channel block enablement. (extensions/imessage/src/monitor.last-route.test.ts:406, 78595d98d69c)
Config/schema surface added: PR head adds a ChannelDeliveryStreamingConfigSchema and wires it into IMessageAccountSchemaBase, making channels.imessage.streaming.{chunkMode,block} and account-level equivalents accepted config. (src/config/zod-schema.providers-core.ts:111, 78595d98d69c)

Likely related people:

steipete: Current-main blame and GitHub commit metadata show the flat-only iMessage dispatch line and the shared streaming/block resolver were introduced in commit 538d36e as part of the session metadata SQLite refactor. (role: introduced current shared/iMessage monitor behavior; confidence: medium; commits: 538d36eaaaa6; files: extensions/imessage/src/monitor/monitor-provider.ts, src/auto-reply/reply/block-streaming.ts, src/channels/streaming.ts)
omarshahine: The most recent iMessage monitor change in current main is commit fc6400e for always-on inbound recovery and dedupe, making this person relevant for adjacent iMessage monitor routing review. (role: recent iMessage area contributor; confidence: medium; commits: fc6400ede389; files: extensions/imessage/src/monitor/monitor-provider.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ae002d0b74

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-06-08T15:09:20Z

+    (cfg.channels?.imessage as Record<string, unknown> | undefined)?.streaming,
+    (accountConfig as Record<string, unknown> | undefined)?.streaming,
+  );
+  return streaming !== undefined ? ({ ...merged, streaming } as IMessageAccountConfig) : merged;


Preserve flat account blockStreaming overrides

When a channel opts into the new channels.imessage.streaming.block.enabled=true, this merge always carries that nested streaming object onto each account unless the account also has a nested streaming object. An existing account-level accounts.<id>.blockStreaming=false is then present alongside inherited streaming.block.enabled=true; resolveChannelStreamingBlockEnabled(accountInfo.config) checks the nested value before the flat flag, so dispatch receives disableBlockStreaming=false and block replies are sent for an account that explicitly disabled them. Since blockStreaming remains an accepted iMessage account config key, mixed old/new configs lose per-account opt-outs.

Useful? React with 👍 / 👎.

jmissig · 2026-06-08T15:30:21Z

updated original post with more detailed logs as proof — I am living on this change with my family's local OpenClaw and it's often giving me at least one intermediary message before final reply. Without this change I only ever see final reply.

My family primarily uses OpenClaw via iMessage and the timing difference with this change is easy to feel.

Route iMessage inbound reply dispatch through the shared block-streaming resolver so the channel respects schema-valid channels.imessage.blockStreaming values instead of bypassing them on the monitor path. Also keep the iMessage streaming schema/tests aligned with the shared channel delivery streaming shape.

omarshahine · 2026-06-08T19:07:32Z

Merged via squash.

Prepared head SHA: 6e4e04f
Merge commit: a7847ac
Maintainer fix added before merge: preserved channel-level nested coalesce fields when account-level nested or legacy flat coalesce overrides only set partial fields.
Local proof run after the fix:
- node scripts/run-vitest.mjs run extensions/imessage/src/config-schema.test.ts src/auto-reply/chunk.test.ts src/auto-reply/reply/block-streaming.test.ts extensions/imessage/src/monitor.last-route.test.ts
- npm run config:channels:check
- pnpm build
- git diff --check
- .agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main --prompt-file /tmp/openclaw-pr-91449-autoreview-context.txt
GitHub CI passed on the merged head.

Thanks @jmissig!

omarshahine · 2026-06-08T20:28:00Z

@clawsweeper re-review

clawsweeper · 2026-06-08T20:28:03Z

🦞🧹
ClawSweeper could not start a re-review for this item.

Reason: re-review requires an open issue or PR.

@omarshahine

Merged via squash. Prepared head SHA: 6e4e04f Co-authored-by: jmissig <1448107+jmissig@users.noreply.github.com> Co-authored-by: omarshahine <10343873+omarshahine@users.noreply.github.com> Reviewed-by: @omarshahine

…26.6.6) (#1040) This PR contains the following updates: | Package | Update | Change | |---|---|---| | [ghcr.io/openclaw/openclaw](https://openclaw.ai) ([source](https://github.com/openclaw/openclaw)) | patch | `2026.6.5` → `2026.6.6` | --- ### Release Notes <details> <summary>openclaw/openclaw (ghcr.io/openclaw/openclaw)</summary> ### [`v2026.6.6`](https://github.com/openclaw/openclaw/blob/HEAD/CHANGELOG.md#202666) [Compare Source](openclaw/openclaw@v2026.6.5...v2026.6.6) ##### Highlights - Security boundaries are substantially tighter across transcripts, sandbox binds, host environment inheritance, MCP stdio, Codex HTTP access, native search policy, elevated sender checks, deleted-agent ACP bypasses, loopback tools, Discord moderation, and Teams group actions; exec approvals now fail closed on timeout. ([#91529](openclaw/openclaw#91529), [#91618](openclaw/openclaw#91618), [#91615](openclaw/openclaw#91615), [#91619](openclaw/openclaw#91619), [#91741](openclaw/openclaw#91741), [#91745](openclaw/openclaw#91745), [#91746](openclaw/openclaw#91746), [#91748](openclaw/openclaw#91748), [#91749](openclaw/openclaw#91749), [#91750](openclaw/openclaw#91750), [#91751](openclaw/openclaw#91751), [#91752](openclaw/openclaw#91752), [#91763](openclaw/openclaw#91763), [#89938](openclaw/openclaw#89938)) Thanks [@joshavant](https://github.com/joshavant), [@pgondhi987](https://github.com/pgondhi987), [@mmaps](https://github.com/mmaps), [@eleqtrizit](https://github.com/eleqtrizit), [@shakkernerd](https://github.com/shakkernerd), and [@drobison00](https://github.com/drobison00). - Telegram delivery is safer and more coherent: account-scoped topics route to the right agent, streamed text survives tool calls, `/compact` works on generic ingress, callback handling uses concrete APIs, draft chunking is shared, durable dispatch dedupe moved into the SDK, and unauthorized DM text stays out of cache and prompt context. ([#91189](openclaw/openclaw#91189), [#88682](openclaw/openclaw#88682), [#89588](openclaw/openclaw#89588), [#90212](openclaw/openclaw#90212), [#91876](openclaw/openclaw#91876), [#91874](openclaw/openclaw#91874), [#91904](openclaw/openclaw#91904), [#91478](openclaw/openclaw#91478), [#91915](openclaw/openclaw#91915)) Thanks [@codysai001](https://github.com/codysai001), [@alexzhu0](https://github.com/alexzhu0), [@joelnishanth](https://github.com/joelnishanth), [@snowzlm](https://github.com/snowzlm), [@obviyus](https://github.com/obviyus), and [@sallyom](https://github.com/sallyom). - iMessage recovery and delivery now cover always-on inbound restart, durable echo markers, block streaming, idle approval discovery, hardened outbound transport, and actionable inbound startup diagnostics. ([#91335](openclaw/openclaw#91335), [#91449](openclaw/openclaw#91449), [#88969](openclaw/openclaw#88969), [#88530](openclaw/openclaw#88530), [#91783](openclaw/openclaw#91783), [#91785](openclaw/openclaw#91785)) Thanks [@omarshahine](https://github.com/omarshahine), [@jmissig](https://github.com/jmissig), and [@colmbrogan](https://github.com/colmbrogan). - Browser and MCP connectivity gained existing-session CDP support, discovered WebSocket validation, default-profile `cdpUrl` handling, safer browser-output boundaries, Streamable HTTP loopback transport, corrected OAuth/SSE authorization handling, and broader schema compatibility. ([#91422](openclaw/openclaw#91422), [#89851](openclaw/openclaw#89851), [#91736](openclaw/openclaw#91736), [#91747](openclaw/openclaw#91747), [#91451](openclaw/openclaw#91451), [#80143](openclaw/openclaw#80143)) Thanks [@pgondhi987](https://github.com/pgondhi987), [@anagnorisis2peripeteia](https://github.com/anagnorisis2peripeteia), [@lifuyue](https://github.com/lifuyue), [@eleqtrizit](https://github.com/eleqtrizit), [@LiuwqGit](https://github.com/LiuwqGit), and [@HemantSudarshan](https://github.com/HemantSudarshan). - Control UI startup and first-reply latency are lower through cached model metadata, removal of the startup catalog wait, lazy slash-command loading, and first-event tracing with slow-reply diagnostics. ([#91531](openclaw/openclaw#91531), [#91538](openclaw/openclaw#91538), [#91568](openclaw/openclaw#91568), [#91583](openclaw/openclaw#91583), [#91598](openclaw/openclaw#91598)) - Provider support expands with OpenRouter OAuth onboarding and Claude Fable 5 adaptive thinking, while Codex sessions keep correct compaction ownership, local models skip guardian review, dynamic tool progress normalizes cleanly, and Gemma 4 reasoning replay is preserved. ([#91830](openclaw/openclaw#91830), [#91882](openclaw/openclaw#91882), [#91590](openclaw/openclaw#91590), [#88630](openclaw/openclaw#88630), [#88768](openclaw/openclaw#88768), [#91696](openclaw/openclaw#91696)) Thanks [@Patrick-Erichsen](https://github.com/Patrick-Erichsen), [@joshavant](https://github.com/joshavant), [@bdjben](https://github.com/bdjben), and [@Coder-Wangyankun](https://github.com/Coder-Wangyankun). ##### Changes - CLI progress: emit Claude CLI commentary progress events and bridge inter-tool commentary into channel progress without exposing internal protocol scaffolding. ([#89834](openclaw/openclaw#89834), [#90883](openclaw/openclaw#90883)) Thanks [@anagnorisis2peripeteia](https://github.com/anagnorisis2peripeteia). - Observability: allow trusted diagnostics channels to capture tool input/output content, add first-assistant-event traces, and warn on slow initial replies. ([#91256](openclaw/openclaw#91256), [#91568](openclaw/openclaw#91568), [#91583](openclaw/openclaw#91583)) Thanks [@amknight](https://github.com/amknight). - Plugins/ClawHub: dogfood reusable package publishing, let dry runs skip publish approval, allow declared installed trusted hooks, report managed plugin version drift, and warn instead of failing on retired Skill Workshop configuration. ([#91574](openclaw/openclaw#91574), [#91591](openclaw/openclaw#91591), [#90004](openclaw/openclaw#90004), [#90927](openclaw/openclaw#90927), [#90838](openclaw/openclaw#90838)) Thanks [@Patrick-Erichsen](https://github.com/Patrick-Erichsen), [@brokemac79](https://github.com/brokemac79), and [@lonexreb](https://github.com/lonexreb). - Memory/providers: move the local llama.cpp runtime into its provider plugin, batch embeddings across files, persist the agent model catalog cache, and keep QMD JSON search one-shot while filtering stale REM recall previews. ([#91324](openclaw/openclaw#91324), [#89138](openclaw/openclaw#89138), [#90457](openclaw/openclaw#90457), [#91837](openclaw/openclaw#91837), [#91851](openclaw/openclaw#91851)) Thanks [@osolmaz](https://github.com/osolmaz), [@mushuiyu886](https://github.com/mushuiyu886), [@ai-hpc](https://github.com/ai-hpc), and [@TurboTheTurtle](https://github.com/TurboTheTurtle). - Channels/mobile: add the QQBot group mention toggle, improve iPad and iPhone control surfaces, and expose the active connection host in the TUI footer. ([#91423](openclaw/openclaw#91423), [#91557](openclaw/openclaw#91557), [#89909](openclaw/openclaw#89909)) Thanks [@cxyhhhhh](https://github.com/cxyhhhhh), [@Solvely-Colin](https://github.com/Solvely-Colin), and [@baskduf](https://github.com/baskduf). - Performance: prewarm TUI runtime plugins, deduplicate plugin auto-enable fanout, trim dense text-delta snapshots, and reuse prepared startup model metadata. ([#90782](openclaw/openclaw#90782), [#89978](openclaw/openclaw#89978), [#91580](openclaw/openclaw#91580), [#91531](openclaw/openclaw#91531)) Thanks [@RomneyDa](https://github.com/RomneyDa) and [@ai-hpc](https://github.com/ai-hpc). ##### Fixes - Agent/session recovery: drop stale approval follow-ups after session rebind, remove drained reply-queue items by identity, recover stale main and visible replies, preserve Codex context-engine compaction ownership, lower the default compaction timeout to 180 seconds while respecting explicit configuration, and keep provider-failure terminal lifecycle state correct. ([#85679](openclaw/openclaw#85679), [#91450](openclaw/openclaw#91450), [#91566](openclaw/openclaw#91566), [#91840](openclaw/openclaw#91840), [#91590](openclaw/openclaw#91590), [#91361](openclaw/openclaw#91361), [#91895](openclaw/openclaw#91895)) Thanks [@openperf](https://github.com/openperf), [@yetval](https://github.com/yetval), [@joshavant](https://github.com/joshavant), [@wangmiao0668000666](https://github.com/wangmiao0668000666), and [@TurboTheTurtle](https://github.com/TurboTheTurtle). - User-visible content boundaries: suppress Codex/Harmony protocol artifacts, neutralize browser and LanceDB memory media directives, redact transcript images, and preserve native `/compact` replies through source suppression. ([#89151](openclaw/openclaw#89151), [#91422](openclaw/openclaw#91422), [#91425](openclaw/openclaw#91425), [#91529](openclaw/openclaw#91529), [#90212](openclaw/openclaw#90212)) Thanks [@joelnishanth](https://github.com/joelnishanth), [@pgondhi987](https://github.com/pgondhi987), [@joshavant](https://github.com/joshavant), and [@snowzlm](https://github.com/snowzlm). - Channel delivery: keep WhatsApp captured replies attached to the successor controller after restart, retry Feishu rate limits, preserve Mattermost thread replies, canonicalize LINE webhook paths, restore Discord reply hydration and runtime timeout exports, and show OpenAI Realtime WebRTC assistant transcripts. ([#85823](openclaw/openclaw#85823), [#89659](openclaw/openclaw#89659), [#91684](openclaw/openclaw#91684), [#91649](openclaw/openclaw#91649), [#90263](openclaw/openclaw#90263), [#91686](openclaw/openclaw#91686), [#90426](openclaw/openclaw#90426)) Thanks [@itsuzef](https://github.com/itsuzef), [@ladygege](https://github.com/ladygege), [@jacobtomlinson](https://github.com/jacobtomlinson), [@fuller-stack-dev](https://github.com/fuller-stack-dev), and [@shushushv](https://github.com/shushushv). - Cron: cancel active task runs cleanly, preserve terminal timeout/cancel state, and recover no-deliver tool warnings instead of silently losing the outcome. ([#90666](openclaw/openclaw#90666), [#90678](openclaw/openclaw#90678)) Thanks [@ai-hpc](https://github.com/ai-hpc). - Gateway/config/auth: share the approval runtime socket token, replace arrays explicitly in `config.patch`, skip the deleted-agent guard only for valid ACP harness sessions, surface headless LaunchAgent state, verify SQLite auth migration before cleanup, and arm QMD startup maintenance. ([#87105](openclaw/openclaw#87105), [#91551](openclaw/openclaw#91551), [#91219](openclaw/openclaw#91219), [#91614](openclaw/openclaw#91614), [#91740](openclaw/openclaw#91740), [#91978](openclaw/openclaw#91978)) Thanks [@fuller-stack-dev](https://github.com/fuller-stack-dev) and [@scotthuang](https://github.com/scotthuang). - Providers/Codex: clarify quota errors, restore the Codex synthetic usage line, canonicalize Codex protocol assets, require API-key auth for realtime voice, normalize ACP model refs, preserve Gemma 4 `reasoning_content`, and avoid guardian review for local models. ([#91390](openclaw/openclaw#91390), [#91709](openclaw/openclaw#91709), [#91507](openclaw/openclaw#91507), [#91567](openclaw/openclaw#91567), [#88630](openclaw/openclaw#88630), [#91696](openclaw/openclaw#91696)) Thanks [@hxy91819](https://github.com/hxy91819), [@brokemac79](https://github.com/brokemac79), [@RomneyDa](https://github.com/RomneyDa), [@joshavant](https://github.com/joshavant), and [@Coder-Wangyankun](https://github.com/Coder-Wangyankun). - Updates/builds: recover package Gateway restarts after refresh failure, expose plugin convergence repair, fall back to Corepack in PATH-less pnpm environments, seed the correct Docker store packages, and keep ClawHub dry-run and publish paths reusable. ([#91581](openclaw/openclaw#91581), [#91599](openclaw/openclaw#91599), [#91547](openclaw/openclaw#91547), [#91591](openclaw/openclaw#91591)) Thanks [@fuller-stack-dev](https://github.com/fuller-stack-dev), [@sallyom](https://github.com/sallyom), and [@Patrick-Erichsen](https://github.com/Patrick-Erichsen). - UI: require explicit user intent before opening chat sessions and drain restored chat queues after session switches. ([#91480](openclaw/openclaw#91480)) Thanks [@TurboTheTurtle](https://github.com/TurboTheTurtle). - Android: avoid the `dataSync` foreground-service type for persistent nodes. ([#80082](openclaw/openclaw#80082)) Thanks [@davelutztx](https://github.com/davelutztx). - Native hooks: bound relay lifetimes so abandoned native hook connections cannot linger indefinitely. ([#91550](openclaw/openclaw#91550)) Thanks [@joshavant](https://github.com/joshavant). </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).  Reviewed-on: https://git.erwanleboucher.dev/eleboucher/homelab/pulls/1040

openclaw-barnacle Bot added channel: imessage Channel integration: imessage size: M proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 8, 2026

jmissig marked this pull request as ready for review June 8, 2026 15:05

chatgpt-codex-connector Bot reviewed Jun 8, 2026

View reviewed changes

openclaw-codex Bot force-pushed the imessage-block-streaming-config branch from ae002d0 to cc32d16 Compare June 8, 2026 15:11

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 8, 2026

openclaw-codex Bot force-pushed the imessage-block-streaming-config branch from cc32d16 to 28f7918 Compare June 8, 2026 15:26

openclaw-codex Bot force-pushed the imessage-block-streaming-config branch from 28f7918 to 7183e7a Compare June 8, 2026 15:42

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 8, 2026

openclaw-codex Bot force-pushed the imessage-block-streaming-config branch from 7183e7a to 78595d9 Compare June 8, 2026 15:45

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 8, 2026

fix(imessage): preserve coalesce override precedence

6e4e04f

openclaw-barnacle Bot added size: L and removed size: M labels Jun 8, 2026

omarshahine merged commit a7847ac into openclaw:main Jun 8, 2026
166 of 168 checks passed

github-actions Bot mentioned this pull request Jun 8, 2026

📡 Upstream Digest — 2026-06-08 20:03 UTC curtismercier/openclaw-mods#1040

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(imessage): honor block streaming config#91449

fix(imessage): honor block streaming config#91449
omarshahine merged 2 commits into
openclaw:mainfrom
jmissig:imessage-block-streaming-config

jmissig commented Jun 8, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 8, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Jun 8, 2026

Uh oh!

jmissig commented Jun 8, 2026 •

edited

Loading

Uh oh!

Uh oh!

omarshahine commented Jun 8, 2026

Uh oh!

omarshahine commented Jun 8, 2026

Uh oh!

clawsweeper Bot commented Jun 8, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jmissig commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Linked context

Real behavior proof (required for external PRs)

Tests and validation

Risk checklist

Current review state

Uh oh!

clawsweeper Bot commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jun 8, 2026

Choose a reason for hiding this comment

Uh oh!

jmissig commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

omarshahine commented Jun 8, 2026

Uh oh!

omarshahine commented Jun 8, 2026

Uh oh!

clawsweeper Bot commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jmissig commented Jun 8, 2026 •

edited

Loading

clawsweeper Bot commented Jun 8, 2026 •

edited

Loading

jmissig commented Jun 8, 2026 •

edited

Loading

clawsweeper Bot commented Jun 8, 2026 •

edited

Loading