openclaw - 💡(How to fix) Fix [Bug]: async exec completion relay asks user for missing logs after No session found [2 comments, 3 participants]

Bug type

Bug / async exec completion relay / user-visible internal followup

Summary

Async/background exec completion events can produce user-visible assistant messages that say the runtime cannot retrieve the completed command output because the referenced exec/session id no longer exists (No session found).

This is worse than a missing completion notice: the model asks the user to paste command output or explain what the command was, even though the command was launched by OpenClaw and should either have its result attached to the completion event or be consumed silently.

Environment

• OpenClaw: 2026.4.26 (be8c246)
• OS: Ubuntu / Linux 6.17.0-22-generic x64
• Install method: npm/global under linuxbrew
• Gateway: local systemd user service, loopback 127.0.0.1:18789
• Surface: Telegram direct chat
• Model: openai-codex/gpt-5.5 / default openai-codex/gpt-5.2
• Affected runner path: background exec completions and cron/heartbeat exec-event relay

Expected behavior

When a background exec completes, OpenClaw should do one of these:

1. Relay a completion summary with the command output/result attached, or
2. If output is missing/unavailable and exit code is success, consume the event silently / emit HEARTBEAT_OK internally, or
3. If output is missing for a failure, send a concise runtime error that includes enough stable metadata for debugging.

It should not ask the end user to provide command output that OpenClaw itself lost.

Actual behavior

The Telegram user receives messages like:

I got a completion notice for an earlier async command (“<short exec id>”, exit code 0), but the runtime didn’t include the command’s stdout/stderr, and I can’t retrieve logs for it (no matching session found).

If you tell me what that command was supposed to do (or paste its output if you have it), I’ll summarize the result and confirm everything looks right.

And:

I can’t retrieve the output for that completed command right now: the exec session id you provided (<opaque-event-id>) isn’t available (“No session found”), so there are no logs for me to relay.

If you paste the command output here (or tell me what command it was), I’ll summarize it cleanly and call out anything important.

This has happened repeatedly after successful background/cron-ish commands. The referenced ids are not available through the process/session tools by the time the relay model tries to inspect them.

Evidence / relevant local observations

Recent gateway logs around one incident show the async relay wake and the gateway operating normally, but no retrievable exec output is delivered to the model:

[heartbeat] using explicit accountId
[agent/embedded] [context-overflow-diag] sessionKey=<redacted-telegram-direct-session> provider=openai-codex/gpt-5.5 source=assistantError messages=199 ... error=Context overflow: estimated context size exceeds safe threshold during tool loop.
...
[gateway] ready
[heartbeat] started
[heartbeat] using explicit accountId

Earlier diagnostics show the same class of issue with orphan completion prompts. The relay prompt instructs the model to relay output, but the output/session is absent, causing the model to produce a helpdesk-style message to the user.

Relevant built artifact behavior in dist/heartbeat-events-filter-*.js:

function buildExecEventPrompt(pendingEvents, opts) {
  ...
  if (!eventText) return "An async command completion event was triggered, but no command output was found. Reply HEARTBEAT_OK only...";
  ...
  return "An async command you ran earlier has completed. The command completion details are:\n\n" + eventText + "\n\nPlease relay the command output to the user...";
}

And in dist/heartbeat-runner-*.js, exec completions are treated specially so skip handling is not applied the same way as normal heartbeat HEARTBEAT_OK replies:

const execFallbackText = hasExecCompletion && !normalized.text.trim() && replyPayload.text?.trim() ? replyPayload.text.trim() : null;
...
const shouldSkipMain = normalized.shouldSkip && !normalized.hasMedia && !hasExecCompletion;

That !hasExecCompletion exception appears to make exec-event turns more likely to leak user-visible fallback text even when there is no useful payload to relay.

Suspected root cause

Two separate problems seem to combine:

1. The exec completion system event contains only partial completion metadata, or references an exec/session id whose logs have already been cleaned up / are not visible to the relay session.
2. The heartbeat exec-event relay prompt asks the model to produce a user-facing summary even when the only available information is an id + exit code, so the model tries to retrieve logs and then sends the resulting No session found failure to the user.

This is related to async completion routing/session-targeting issues, but this specific failure mode is about missing completion payload + model-mediated relay leaking the absence of runtime context to the user.

Impact

• Confusing and unactionable Telegram noise after successful automations/background tasks.
• User is asked to paste output that OpenClaw should already have.
• Makes successful cron/background jobs look broken.
• Can repeat frequently when multiple automations/background execs are active.

Suggested fix direction

• Include durable stdout/stderr/result summary in the exec completion event before process/session cleanup, or persist a log reference that remains available to the relay.
• If an exec completion has exit code 0 and no output, treat it as silently successful by default.
• Only deliver user-visible async completion text when there is meaningful output, an error, or an explicit user-facing completion request.
• Remove the hasExecCompletion exception from heartbeat skip handling unless the event has a non-empty, relayable payload.
• Add regression coverage for: background exec exits 0 after process session cleanup; heartbeat/exec-event relay should not ask the user for missing logs.

Privacy note

Chat ids, session ids, hostnames, and opaque event ids are intentionally redacted here, but can be provided privately if maintainers need exact local logs.