fix(tui): strip inbound metadata blocks from user text by Kansodata · Pull Request #22319 · openclaw/openclaw

Kansodata · 2026-02-21T01:34:53Z

Summary

Describe the problem and fix in 2–5 bullets:

Problem: TUI user messages could display inbound metadata envelopes (for example Conversation info (untrusted metadata) JSON blocks) instead of only user-authored text.
Why it matters: The chat log becomes noisy/confusing and leaks internal prompt-context scaffolding into the visible UX.
What changed: Added metadata-prefix stripping for role: "user" in src/tui/tui-formatters.ts, removing known inbound metadata blocks before rendering.
What did NOT change (scope boundary): No gateway/inbound metadata generation changes and no assistant-message rendering behavior changes.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes TUI renders inbound metadata block in user messages #22276
Related #

User-visible / Behavior Changes

In TUI, inbound metadata preface blocks are no longer shown for user messages loaded/rendered from stored conversation content.

Security Impact (required)

New permissions/capabilities? (Yes/No) No
Secrets/tokens handling changed? (Yes/No) No
New/changed network calls? (Yes/No) No
Command/tool execution surface changed? (Yes/No) No
Data access scope changed? (Yes/No) No
If any Yes, explain risk + mitigation:

Repro + Verification

Environment

OS: Windows 11 (PowerShell)
Runtime/container: Node 22 + pnpm
Model/provider: N/A
Integration/channel (if any): N/A
Relevant config (redacted): default dev setup

Steps

Prepare a user message payload whose text begins with one or more inbound metadata JSON blocks.
Render/extract message text via TUI formatter path (extractTextFromMessage).
Observe rendered text in chat log.

Expected

User-visible output contains only real user message text.

Actual

After this change, leading inbound metadata blocks are stripped for user role.

Evidence

Attach at least one:

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios:
- pnpm vitest run src/tui/tui-formatters.test.ts passes.
- New test confirms stripping multiple leading inbound metadata blocks for user messages.
Edge cases checked:
- Non-user (assistant) content with similar text is preserved.
What you did not verify:
- Full interactive TUI manual walkthrough in a live multi-channel runtime.

Compatibility / Migration

Backward compatible? (Yes/No) Yes
Config/env changes? (Yes/No) No
Migration needed? (Yes/No) No
If yes, exact upgrade steps:

Failure Recovery (if this breaks)

How to disable/revert this change quickly: revert commit fix(tui): strip inbound metadata blocks from user text.
Files/config to restore: src/tui/tui-formatters.ts, src/tui/tui-formatters.test.ts.
Known bad symptoms reviewers should watch for: legitimate user text unintentionally removed when it exactly matches metadata header+JSON fence format.

Risks and Mitigations

Risk: Over-stripping if a real user message intentionally starts with the exact metadata header + fenced JSON structure.
- Mitigation: Match only known inbound metadata headers and only strip leading blocks, leaving normal content untouched.

Greptile Summary

Adds metadata block stripping for TUI user messages to prevent internal scaffolding from appearing in the chat UI. The implementation correctly identifies and removes known inbound metadata headers (conversation info, sender, thread starter, replied message, forwarded context, chat history) that are prefixed to user messages, cleaning up the visual presentation while preserving the actual user text.

Key changes:

Added INBOUND_METADATA_HEADERS array matching the canonical source in src/auto-reply/reply/inbound-meta.ts:94-180
Implemented stripLeadingInboundMetadataBlocks() that loops to remove multiple consecutive metadata blocks
Applied stripping only to role: "user" messages in extractTextFromMessage(), preserving assistant messages unchanged
Added comprehensive test coverage for both user and assistant message scenarios

Observations:

Regex pattern correctly escapes special characters and handles both \r\n and \n line endings
The loop-based approach ensures multiple consecutive metadata blocks are all removed
Only one minor style suggestion about adding the multiline regex flag for clarity

Confidence Score: 5/5

This PR is safe to merge with minimal risk
Score reflects well-scoped bug fix with comprehensive tests, matching Swift implementation, and minimal risk of over-stripping due to specific header matching
No files require special attention

_{Last reviewed commit: 477c588}

* vincentkoc-code/security-fix-hono-2026.2.20: Security: bump hono for timing-safe auth hardening

greptile-apps

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

src/tui/tui-formatters.ts

* fix(docker): pin base images to SHA256 digests for supply chain security Pin all 9 Dockerfiles to immutable SHA256 digests to prevent supply chain attacks where a compromised upstream image could be silently pulled into production builds. Also add Docker ecosystem to Dependabot configuration for automated digest updates. Images pinned: - node:22-bookworm@sha256:cd7bcd2e7a1e6f72052feb023c7f6b722205d3fcab7bbcbd2d1bfdab10b1e935 - node:22-bookworm-slim@sha256:3cfe526ec8dd62013b8843e8e5d4877e297b886e5aace4a59fec25dc20736e45 - debian:bookworm-slim@sha256:98f4b71de414932439ac6ac690d7060df1f27161073c5036a7553723881bffbe - ubuntu:24.04@sha256:cd1dba651b3080c3686ecf4e3c4220f026b521fb76978881737d24f200828b2b Fixes openclaw#7731 Co-Authored-By: Claude Opus 4.5 <[email protected]> * test(docker): add digest pinning regression coverage --------- Co-authored-by: Claude Opus 4.5 <[email protected]>

…nclaw#21086) * fix: treat HTTP 503 as failover-eligible for LLM provider errors When LLM SDKs wrap 503 responses, the leading "503" prefix is lost (e.g. Google Gemini returns "high demand" / "UNAVAILABLE" without a numeric prefix). The existing isTransientHttpError only matches messages starting with "503 ...", so these wrapped errors silently skip failover — no profile rotation, no model fallback. This patch closes that gap: - resolveFailoverReasonFromError: map HTTP status 503 → rate_limit (covers structured error objects with a status field) - ERROR_PATTERNS.overloaded: add /\b503\b/, "service unavailable", "high demand" (covers message-only classification when the leading status prefix is absent) Existing isTransientHttpError behavior is unchanged; these additions are complementary and only fire for errors that previously fell through unclassified. * fix: address review feedback — drop /\b503\b/ pattern, add test coverage - Remove `/\b503\b/` from ERROR_PATTERNS.overloaded to resolve the semantic inconsistency noted by reviewers: `isTransientHttpError` already handles messages prefixed with "503" (→ "timeout"), so a redundant overloaded pattern would classify the same class of errors differently depending on message formatting. - Keep "service unavailable" and "high demand" patterns — these are the real gap-fillers for SDK-rewritten messages that lack a numeric prefix. - Add test case for JSON-wrapped 503 error body containing "overloaded" to strengthen coverage. * fix: unify 503 classification — status 503 → timeout (consistent with isTransientHttpError) resolveFailoverReasonFromError previously mapped status 503 → "rate_limit", while the string-based isTransientHttpError mapped "503 ..." → "timeout". Align both paths: structured {status: 503} now also returns "timeout", matching the existing transient-error convention. Both reasons are failover-eligible, so runtime behavior is unchanged. --------- Co-authored-by: Vincent Koc <[email protected]>

…verbose logs, and WebUI (openclaw#20704)

…0988) * fix(slack): pass recipient_team_id and recipient_user_id to streaming API calls The Slack Agents & AI Apps streaming API (chat.startStream / chat.stopStream) requires recipient_team_id and recipient_user_id parameters. Without them, stopStream fails with 'missing_recipient_team_id' (all contexts) or 'missing_recipient_user_id' (DM contexts), causing streamed messages to disappear after generation completes. This passes: - team_id (from auth.test at provider startup, stored in monitor context) - user_id (from the incoming message sender, for DM recipient identification) through to the ChatStreamer via recipient_team_id and recipient_user_id options. Fixes openclaw#19839, openclaw#20847, openclaw#20299, openclaw#19791, openclaw#20337 AI-assisted: Written with Claude (Opus 4.6) via OpenClaw. Lightly tested (unit tests pass, live workspace verification in progress). * fix(slack): disable block streaming when native streaming is active When Slack native streaming (`chat.startStream`/`stopStream`) is enabled, `disableBlockStreaming` was set to `false`, which activated the app-level block streaming pipeline. This pipeline intercepted agent output, sent it via block replies, then dropped the final payloads that would have flowed through `deliverWithStreaming` to the Slack streaming API — resulting in zero replies delivered. Set `disableBlockStreaming: true` when native streaming is active so the final reply flows through the Slack streaming API path as intended. Co-Authored-By: Claude Opus 4.6 <[email protected]> --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Vincent Koc <[email protected]>

…openclaw#21434)

…#11046) - Changed "cask" to "formula" in SKILL.md for consistency. - Enhanced formula parsing in frontmatter.ts to trim whitespace and fallback to cask if formula is not provided.

…claw#21336)

…penclaw#21447) Fixes the pairing required regression from openclaw#21236 for legacy paired devices created without roles/scopes metadata. Detects legacy paired metadata shape and skips upgrade enforcement while backfilling metadata in place on reconnect. Co-authored-by: Josh Avant <[email protected]> Co-authored-by: Val Alexander <[email protected]>

@gumadeiras

Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: 0427165 Co-authored-by: adhitShet <[email protected]> Co-authored-by: gumadeiras <[email protected]> Reviewed-by: @gumadeiras

@gumadeiras

…enclaw#21410) Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: 7b8fe75 Co-authored-by: adhitShet <[email protected]> Co-authored-by: gumadeiras <[email protected]> Reviewed-by: @gumadeiras

@gumadeiras

…claw#21408) Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: 993860b Co-authored-by: adhitShet <[email protected]> Co-authored-by: gumadeiras <[email protected]> Reviewed-by: @gumadeiras

@gumadeiras

…#21332) Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: b6c8d1e Co-authored-by: adhitShet <[email protected]> Co-authored-by: gumadeiras <[email protected]> Reviewed-by: @gumadeiras

@joshavant

…nclaw#21231) Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: 68adbf5 Co-authored-by: ahdernasr <[email protected]> Co-authored-by: joshavant <[email protected]> Reviewed-by: @joshavant

@gumadeiras

…law#21303) Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: 20d058d Co-authored-by: adhitShet <[email protected]> Co-authored-by: gumadeiras <[email protected]> Reviewed-by: @gumadeiras

@rodrigouroz

…18786) thanks @rodrigouroz Verified: - pnpm install --frozen-lockfile - pnpm build - pnpm check - pnpm test:macmini Co-authored-by: rodrigouroz <[email protected]> Co-authored-by: Tak Hoffman <[email protected]>

@Takhoffman

…openclaw#21533) thanks @Takhoffman Verified: - pnpm build - pnpm check - pnpm test:macmini Co-authored-by: Tak Hoffman <[email protected]>

@echoVic

…aw#20508) thanks @echoVic Verified: - pnpm build - pnpm check - pnpm test:macmini Co-authored-by: echoVic <[email protected]> Co-authored-by: Tak Hoffman <[email protected]>

openclaw-barnacle · 2026-02-21T02:03:46Z