openclaw - ✅(Solved) Fix [Bug]: Task flow completion leaks internal routing metadata into Discord channel [1 pull requests, 1 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#59025Fetched 2026-04-08 02:29:44
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Participants
Timeline (top)
cross-referenced ×2

After upgrading to OpenClaw 2026.3.31, ACP task completion events leak internal routing metadata and system instructions into user-facing Discord channels as plain messages.

Root Cause

After upgrading to OpenClaw 2026.3.31, ACP task completion events leak internal routing metadata and system instructions into user-facing Discord channels as plain messages.

PR fix notes

PR #59649: fix(agent): close remaining internal-context leak paths

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

If this PR fixes a plugin beta-release blocker, title it fix(<plugin-id>): beta blocker - <summary> and link the matching Beta blocker: <plugin-name> - <summary> issue labeled beta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.

  • Problem: several adjacent user-facing task/status/followup surfaces still rendered raw internal runtime context, task-completion metadata, or raw exec approval followup text even after /status stale-row hardening.
  • Why it matters: internal runtime context and raw exec-denial/completion details can leak into visible chat surfaces across command/status flows, which is both noisy and a privacy/safety problem.
  • What changed: this PR centralizes task-status sanitization across /tasks, /subagents info, /acp status, task notification formatting, and run labels; strips legacy unmarked internal blocks even when embedded; and sanitizes or suppresses no-session exec approval followups instead of raw-sending them.
  • What did NOT change (scope boundary): this PR does not change task lifecycle semantics, approval routing/auth, session/task linkage, or broader streamed-reply sanitization outside these user-facing task/followup surfaces.

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 #58921
  • Related #44528, #39032, #59025, #51149, #58748, #58783, #58810
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause: user-facing task, command, and followup surfaces were formatting raw progressSummary, error, terminalSummary, runtime status text, and exec followup result text directly, while sanitization only existed in narrower /status-adjacent or final-reply paths.
  • Missing detection / guardrail: there was no regression coverage for contaminated task records and followup payloads across /tasks, /subagents info, /acp status, task notification formatting, run-label formatting, and no-session exec followups.
  • Prior context (git blame, prior PR, issue, or refactor if known): #58810 fixed stale completed task rows in status cards but did not sanitize neighboring task/followup surfaces; legacy internal-context stripping also only handled the start-of-string case before this change.
  • Why this regressed now: this appears to be a pre-existing leak family rather than a single fresh regression; partial hardening covered /status first, which left adjacent user-facing surfaces still leaking the same class of internals.
  • If unknown, what was ruled out: ruled out a stale-row-only explanation by reproducing/locking leaks in /tasks, /subagents info, /acp status, blocked task messages, run labels, and no-session exec followups with contaminated payloads.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should have caught this. Otherwise write N/A.

  • Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
  • Target test or file:
    • src/tasks/task-status.test.ts
    • src/tasks/task-executor-policy.test.ts
    • src/agents/pi-embedded-helpers.sanitizeuserfacingtext.test.ts
    • src/agents/bash-tools.exec-approval-followup.test.ts
    • src/auto-reply/reply/commands-status.test.ts
    • src/auto-reply/reply/commands-tasks.test.ts
    • src/auto-reply/reply/commands-acp.test.ts
    • src/auto-reply/reply/commands.test.ts
    • src/auto-reply/reply/reply-plumbing.test.ts
  • Scenario the test should lock in: contaminated legacy internal blocks and raw Exec denied (...) / Exec finished (...) payloads never reach /tasks, /status, /subagents info, /acp status, task notifications, formatted run labels, or no-session followup delivery as raw internal text.
  • Why this is the smallest reliable guardrail: these failures occur in formatter/command seams before channel delivery, so focused unit + command-surface tests catch the leak without requiring a live provider or channel integration.
  • Existing test that already covers this (if any): existing /status coverage already guarded the stale-row/status-card path; this PR extends coverage to the adjacent surfaces that were still leaking.
  • If no new test is added, why not: N/A (new tests added)

User-visible / Behavior Changes

List user-visible changes (including defaults/config). If none, write None.

  • /tasks, /status, /subagents info, and /acp status no longer expose internal runtime-context blocks or raw exec approval denial text from contaminated task/runtime records.
  • Blocked/failure task followups now present sanitized user-safe text instead of raw internal metadata.
  • No-session exec approval followups now suppress denied raw text and sanitize completed/failed raw summaries before direct delivery.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

Before:
[task/error/followup payload]
  -> [surface-specific formatter]
  -> [raw internal block / exec metadata reaches user-visible text]

After:
[task/error/followup payload]
  -> [shared sanitizeTaskStatusText / sanitizeUserFacingText]
  -> [surface formatter]
  -> [user-safe status/update text]

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: N/A

Repro + Verification

Environment

  • OS: Ubuntu Linux (ARM64 EC2 host)
  • Runtime/container: local repo checkout with Node/pnpm + Vitest
  • Model/provider: N/A (fixture-based sanitization paths; no live provider call required for verification)
  • Integration/channel (if any): simulated Telegram/Discord/Slack command and followup paths in tests
  • Relevant config (redacted): default repo test configuration; no config/env changes

Steps

  1. Create or load a task/followup payload containing a legacy OpenClaw runtime context (internal) block and/or raw Exec denied (...) / Exec finished (...) text.
  2. Render that payload through /tasks, /status, /subagents info, /acp status, task notification formatting, run-label formatting, or no-session exec approval followup delivery.
  3. Compare visible output before and after this PR.

Expected

  • Only sanitized, user-safe text is shown; embedded legacy internal blocks are removed and raw exec approval internals are redacted or suppressed.

Actual

  • Before this PR, raw internal runtime text and raw exec approval followup text could surface in those user-facing outputs.

Evidence

Attach at least one:

  • Failing test/log before + passing after

  • Trace/log snippets

  • Screenshot/recording

  • Perf numbers (if relevant)

  • Before (targeted combined run while gaps remained): failures reproduced in commands.test.ts, commands-acp.test.ts, commands-status.test.ts, commands-tasks.test.ts, reply-plumbing.test.ts, and task-status.test.ts on leaked internal-context / raw exec-detail cases.

  • After (post-fix sharded verification): touched-path suites passed 9 test files / 249 tests, and pnpm check passed at commit time.

Human Verification (required)

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

  • Verified scenarios: reviewed the rebased diff against upstream/main; ran pnpm check; ran focused post-rebase Vitest shards covering task status, task executor policy, /tasks, /status, /subagents info, /acp status, reply plumbing, and exec approval followups.
  • Edge cases checked: embedded legacy blocks with surrounding clean text preserved; ordinary mentions of internal marker strings remain intact; blocked task summaries carrying raw Exec denied (...); no-session exec followups with denied, finished-with-output, and finished-without-output cases; run-label sanitization fallback.
  • What you did not verify: full GitHub CI matrix; live manual Telegram/Discord/Slack end-to-end runs against a deployed gateway.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk: over-sanitizing legitimate user-visible text that resembles internal block headers or exec-denial text.
  • Mitigation: legacy stripping requires the canonical runtime header + event shape, tests preserve ordinary mentions, and exec-denial rewriting only applies in error/followup contexts.
  • Risk: no-session followups may now collapse raw completion metadata to a generic summary when no safe user-visible body remains.
  • Mitigation: successful visible output is preserved whenever safe body text exists; the generic fallback is only used when the remaining text is internal/noisy metadata.

Changed files

  • src/agents/bash-tools.exec-approval-followup.test.ts (modified, +55/-3)
  • src/agents/bash-tools.exec-approval-followup.ts (modified, +60/-3)
  • src/agents/internal-events.ts (modified, +40/-8)
  • src/agents/pi-embedded-helpers.sanitizeuserfacingtext.test.ts (modified, +120/-0)
  • src/agents/pi-embedded-helpers/errors.ts (modified, +195/-1)
  • src/auto-reply/reply/commands-acp.test.ts (modified, +87/-0)
  • src/auto-reply/reply/commands-acp/runtime-options.ts (modified, +19/-10)
  • src/auto-reply/reply/commands-status.test.ts (modified, +28/-0)
  • src/auto-reply/reply/commands-subagents/action-info.ts (modified, +13/-5)
  • src/auto-reply/reply/commands-tasks.test.ts (modified, +30/-0)
  • src/auto-reply/reply/commands-tasks.ts (modified, +7/-6)
  • src/auto-reply/reply/commands.test.ts (modified, +61/-0)
  • src/auto-reply/reply/reply-plumbing.test.ts (modified, +15/-0)
  • src/auto-reply/reply/subagents-utils.ts (modified, +2/-1)
  • src/tasks/task-executor-policy.test.ts (modified, +57/-0)
  • src/tasks/task-executor-policy.ts (modified, +23/-12)
  • src/tasks/task-status.test.ts (modified, +70/-0)
  • src/tasks/task-status.ts (modified, +71/-11)
RAW_BUFFERClick to expand / collapse

Description

After upgrading to OpenClaw 2026.3.31, ACP task completion events leak internal routing metadata and system instructions into user-facing Discord channels as plain messages.

Environment

  • OpenClaw version: 2026.3.31
  • Channel: Discord (guild channel with thread bindings enabled)
  • ACP backend: acpx with Codex
  • OS: macOS (Apple Silicon)

Steps to Reproduce

  1. In a Discord channel (e.g. #proj-bimaterial), have a conversation with the agent
  2. Agent spawns a Codex ACP session via sessions_spawn — a thread "🤖 codex" is created
  3. Codex completes the task successfully
  4. The channel receives "Background task done: ACP background task (run cdfe1eff)."
  5. Run /status in the channel

Observed Behavior

The agent posts multiple messages (5-6) into the channel containing:

  • The full raw task completion result (internal child result with <<<BEGIN_UNTRUSTED_CHILD_RESULT>>> / <<<END_UNTRUSTED_CHILD_RESULT>>> markers)
  • Internal runtime stats: Stats: runtime 6m14s • tokens 0 (in 0 / out 0)
  • Internal routing instructions: "Action: A completed subagent task is ready for user delivery. Convert the result above into your normal assistant voice and send that user-facing update now. Keep this internal context private..."
  • Runtime configuration metadata: "⚙️ Runtime: direct · Think: adaptive", "👥 Activation: mention · 🪢 Queue: collect (depth 0)"

This internal metadata should never reach user-facing channels.

Expected Behavior

  • Task completion results should be sanitized before delivery — only the human-readable summary should be sent
  • Internal routing instructions (Action: ...) should be stripped
  • Runtime metadata and stats should not be included in user-visible messages
  • The delivery should be a single, clean message summarizing what the agent accomplished

Timeline (UTC+8, 2026-04-01)

TimeEvent
20:47-20:52Normal conversation in channel
20:53Agent spawns Codex, thread "🤖 codex" created
20:59:33"Background task done: ACP background task" appears in channel
21:00:08-21:00:14User runs /status → agent dumps 5-6 messages with raw internal metadata into channel

Related

  • #50690 (pre-send policy layer for fake-progress messages)
  • #44492 (Telegram topic loses ACP routing after heavy bound turn)

Additional Context

This appears related to the new task flow routing introduced in 2026.3.31 ("route one-task ACP and subagent updates through a parent task-flow owner context"). The completion event is being delivered raw instead of being processed through the normal sanitization/rewriting pipeline.

extent analysis

TL;DR

The issue can be fixed by modifying the task flow routing to process completion events through the normal sanitization and rewriting pipeline.

Guidance

  • Review the changes introduced in OpenClaw 2026.3.31, specifically the new task flow routing, to understand how it affects the processing of completion events.
  • Check the configuration of the acpx backend with Codex to ensure that the sanitization and rewriting pipeline is enabled and properly configured.
  • Investigate the possibility of adding a pre-send policy layer to filter out internal metadata and routing instructions, as mentioned in related issue #50690.
  • Verify that the issue is not related to the interaction between the ACP backend and the Discord channel, by testing the same scenario with a different channel or backend configuration.

Example

No code snippet is provided as the issue seems to be related to the configuration and routing of the OpenClaw system, rather than a specific code implementation.

Notes

The issue appears to be specific to the OpenClaw 2026.3.31 version and the new task flow routing feature. The solution may involve modifying the configuration or adding additional processing steps to the completion event pipeline.

Recommendation

Apply a workaround by modifying the task flow routing configuration to process completion events through the normal sanitization and rewriting pipeline, until a permanent fix is available in a future version of OpenClaw.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING