Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Control UI shows async exec system events inline as if authored by the user [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#70373•Fetched 2026-04-23 07:25:33
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
ghitafilalighitafilali
Participants
ghitafilalighitafilali
Timeline (top)
cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #70379: fix(exec-events): frame async exec completions as assistant-started

Description (problem / solution / changelog)

Summary

Fixes #70373 (part — the wording side). The system-prompt fragment `buildExecEventPrompt` in `src/infra/heartbeat-events-filter.ts` told the agent:

An async command you ran earlier has completed.

Read literally, you is the agent — but when the agent then relays the result to the user, it parrots that phrasing back into chat, which reads to the user as if they started the command:

An async command you ran earlier has completed...

The assistant is the one that kicked off the background exec (via async tool call). Framing it as user-initiated is confusing in Control UI and can cause alarm when a `SIGKILL` surface appears without context.

Fix

Rephrase both the deliver-to-user and internal-only prompt variants to explicitly frame the command as started by the assistant:

A background command you (the assistant) started earlier has completed.

For the user-relay mode, also add a nudge asking the agent to frame the output as its own follow-up rather than something the user ran.

Test

  • Existing tests continue to pass unchanged (they assert on the delivery-mode-differentiating substrings `Please relay the command output to the user` and `Handle the result internally`, both preserved).
  • Added one regression test asserting the new framing (`you (the assistant)`) is present and the old misleading phrase (`async command you ran earlier`) is gone, for both delivery modes.

oxlint clean.

Scope note

The issue also suggests moving these events out of the main chat transcript entirely (or into a separate system area). That's a broader Control UI change; keeping this PR scoped to the wording fix that addresses the user-facing "you" confusion directly. Happy to follow up on the UI-layer separation if the wording fix isn't sufficient.

Closes #70373 (wording side).

Changed files

  • src/infra/heartbeat-events-filter.test.ts (modified, +14/-0)
  • src/infra/heartbeat-events-filter.ts (modified, +13/-4)
RAW_BUFFERClick to expand / collapse

Problem

In the Control UI, async background exec completion/failure events are rendered inline in the main conversation stream in a way that makes them look like they were authored by the human user.

This is confusing and misleading.

Example surfaced text:

  • System (untrusted): [timestamp] Exec completed ...
  • System (untrusted): [timestamp] Exec failed ...
  • An async command you ran earlier has completed...

The wording especially is wrong from the user's point of view: the human did not run that command. The assistant did.

Why this is bad

  • It visually reads like part of the normal chat flow instead of internal runtime activity.
  • It can be mistaken for something the user typed or triggered directly.
  • The phrase "you ran earlier" is misleading in assistant-driven flows.
  • It leaks low-level implementation noise into the user experience.
  • It creates unnecessary alarm when failures like SIGKILL appear without context.

Expected behavior

One of these should happen instead:

  1. Do not show these events in the normal chat transcript at all.
  2. Show them in a clearly separate system/activity area, visually distinct from user and assistant messages.
  3. If they must appear in-chat, label them explicitly as assistant-started background command events.

Suggested wording change

Instead of:

An async command you ran earlier has completed.

Use something like:

A background command started by the assistant has completed.

Or better, keep this out of the visible chat stream entirely.

Notes

This was observed multiple times during normal OpenClaw usage in the Control UI while the assistant was running background exec/process commands.

extent analysis

TL;DR

Modify the Control UI to either exclude async background exec events from the main conversation stream or display them in a visually distinct system/activity area.

Guidance

  • Review the current implementation of rendering async background exec events in the Control UI and consider alternative approaches that better distinguish these events from user-authored messages.
  • Update the wording of event messages to accurately reflect the role of the assistant, such as using phrases like "A background command started by the assistant has completed."
  • Investigate the possibility of displaying these events in a separate system/activity area, rather than inline with user and assistant messages.
  • Consider filtering out low-level implementation details, such as SIGKILL failures, to prevent unnecessary alarm and improve the overall user experience.

Example

No specific code snippet is provided, as the issue description does not include explicit code references.

Notes

The suggested changes aim to improve the clarity and accuracy of the Control UI, reducing confusion and misleading information. However, the optimal solution may depend on specific requirements and constraints of the OpenClaw system.

Recommendation

Apply a workaround by updating the event message wording and considering alternative display approaches, as a more comprehensive solution may require significant changes to the Control UI implementation.

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

One of these should happen instead:

  1. Do not show these events in the normal chat transcript at all.
  2. Show them in a clearly separate system/activity area, visually distinct from user and assistant messages.
  3. If they must appear in-chat, label them explicitly as assistant-started background command events.
#index setup#retrieval issue#search optimization#API routing#API middleware

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 Control UI shows async exec system events inline as if authored by the user [1 pull requests, 1 participants]