Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Exec follow-up fallback should retry session resume and avoid user-facing internal prefix [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#72143•Fetched 2026-04-27 05:34:16
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
ahmednasr999ahmednasr999
Participants
ahmednasr999ahmednasr999
Timeline (top)
cross-referenced ×2referenced ×2

When an async/background exec approval follow-up cannot resume the original agent session, OpenClaw falls back to direct delivery and currently exposes an internal prefix to the user:

Automatic session resume failed, so sending the status directly.

This is confusing because the underlying command may have succeeded. The failure is in the session handoff/delivery path, not necessarily in the command.

Error Message

  • Background/approved exec completes.
  • Follow-up path attempts to resume the original agent session.
  • If resume/follow-up fails, direct delivery is sent with the internal fallback prefix.
  • The user sees the prefix in Telegram/DM output, sometimes while investigating approval/session issues.

Root Cause

The current prefix makes successful command completions look like command failures. It also creates a noisy feedback loop: approval/follow-up failures surface while trying to diagnose approval/follow-up failures.

Fix Action

Fix / Workaround

We applied a local runtime mitigation by changing that return to return "";, but that is intentionally local and will be overwritten by updates.

Local workaround used

Runtime-only local patch:

PR fix notes

PR #72148: fix(exec): drop "Automatic session resume failed" prefix from approval followup (#72143)

Description (problem / solution / changelog)

Summary

Fixes #72143.

When an async exec approval follow-up cannot resume the original agent session, the user previously saw:

``` Automatic session resume failed, so sending the status directly.

<actual command output> \`\`\`

This leaks operator-level state into Telegram / DM surfaces and is confusing because the underlying command often succeeded — only the session handoff failed. The reporter tested a local mitigation (`return "";` from `buildSessionResumeFallbackPrefix`) and confirmed it works.

Fix: drop the user-facing prefix entirely; log the resume failure as a warn line (with `approvalId` + error message) so ops can still debug the handoff issue without it leaking to users.

Pre-implement audit (skill v6 rules)

RuleStatusNotes
Existing-helper checkPASS`logWarn` already imported in adjacent `bash-tools.exec-host-shared.ts` / `bash-tools.exec-runtime.ts`; reusing same logger pattern
Shared-helper-caller checkPASS`buildSessionResumeFallbackPrefix` had exactly one caller in this file; removal is local
Broader-fix-rival scanPASSNo rival PR for #72143

Test plan

  • `pnpm exec vitest run src/agents/bash-tools.exec-approval-followup.test.ts` — 14/14 pass
  • Two existing tests asserting the old prefix updated to assert prefix-free content (their setup paths exercise the resume-failed branch via `mockRejectedValueOnce`)
  • `pnpm exec oxfmt --check` — clean (after auto-format on import order)
  • `pnpm exec oxlint` — 0 warnings/errors
  • CI green

Note on retry-with-backoff

The reporter also requested retry-with-backoff before the fallback (their expected-behavior #1). I held that back to keep this diff focused on the user-visible regression — the retry change touches the gateway tool call surface and warrants its own PR with backoff timing + metrics. The prefix removal matches the reporter's tested mitigation and resolves the user-reported bug today.

Files

file+−
`CHANGELOG.md`10
`src/agents/bash-tools.exec-approval-followup.ts`174
`src/agents/bash-tools.exec-approval-followup.test.ts`93

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/bash-tools.exec-approval-followup.test.ts (modified, +43/-3)
  • src/agents/bash-tools.exec-approval-followup.ts (modified, +32/-4)

Code Example

Automatic session resume failed, so sending the status directly.

---

/usr/lib/node_modules/openclaw/dist/bash-tools-MqL7r1OX.js:215:
return "Automatic session resume failed, so sending the status directly.\n\n";

---

return "";
RAW_BUFFERClick to expand / collapse

Summary

When an async/background exec approval follow-up cannot resume the original agent session, OpenClaw falls back to direct delivery and currently exposes an internal prefix to the user:

Automatic session resume failed, so sending the status directly.

This is confusing because the underlying command may have succeeded. The failure is in the session handoff/delivery path, not necessarily in the command.

Observed behavior

  • Background/approved exec completes.
  • Follow-up path attempts to resume the original agent session.
  • If resume/follow-up fails, direct delivery is sent with the internal fallback prefix.
  • The user sees the prefix in Telegram/DM output, sometimes while investigating approval/session issues.

In the installed runtime we found the string in the bash-tools chunk, not dist/index.js:

/usr/lib/node_modules/openclaw/dist/bash-tools-MqL7r1OX.js:215:
return "Automatic session resume failed, so sending the status directly.\n\n";

We applied a local runtime mitigation by changing that return to return "";, but that is intentionally local and will be overwritten by updates.

Expected behavior

  1. Retry session resume/follow-up with short backoff before falling back, for example 500ms, 1500ms, 3000ms.
  2. If direct delivery fallback is still needed, do not prefix the user-facing message with internal session-resume failure text.
  3. Log the resume failure internally with enough metadata to debug, for example follow-up id, original session key/id, delivery target, and error cause.
  4. Preserve the command result/status content in the fallback delivery.

Why this matters

The current prefix makes successful command completions look like command failures. It also creates a noisy feedback loop: approval/follow-up failures surface while trying to diagnose approval/follow-up failures.

Local workaround used

Runtime-only local patch:

return "";

This only suppresses the user-facing prefix. It does not fix the deeper session handoff resilience issue.

Suggested fix

Implement retry/backoff around the agent-session resume/follow-up call in the exec approval follow-up path, then fall back to direct delivery silently if all retries fail, with internal-only logging for the resume failure.

extent analysis

TL;DR

Implement a retry mechanism with backoff for the agent-session resume/follow-up call to improve session handoff resilience and remove the internal prefix from user-facing messages.

Guidance

  • Modify the exec approval follow-up path to include a retry mechanism with exponential backoff (e.g., 500ms, 1500ms, 3000ms) for the agent-session resume/follow-up call.
  • If all retries fail, fall back to direct delivery without prefixing the user-facing message with internal session-resume failure text.
  • Log the resume failure internally with relevant metadata (e.g., follow-up id, original session key/id, delivery target, error cause) for debugging purposes.
  • Ensure the command result/status content is preserved in the fallback delivery.

Example

const retryDelays = [500, 1500, 3000]; // example backoff delays
let retryCount = 0;

function resumeSession() {
  // attempt to resume session
  // ...
  if (/* resume fails */) {
    if (retryCount < retryDelays.length) {
      setTimeout(() => {
        retryCount++;
        resumeSession();
      }, retryDelays[retryCount - 1]);
    } else {
      // fall back to direct delivery without prefix
      deliverDirectly();
    }
  }
}

Notes

The suggested fix aims to address the session handoff resilience issue and improve user experience by removing the internal prefix from user-facing messages. However, the exact implementation details may vary depending on the specific requirements and constraints of the OpenClaw system.

Recommendation

Apply the suggested fix by implementing a retry mechanism with backoff for the agent-session resume/follow-up call, as it addresses the root cause of the issue and provides a more robust solution.

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

  1. Retry session resume/follow-up with short backoff before falling back, for example 500ms, 1500ms, 3000ms.
  2. If direct delivery fallback is still needed, do not prefix the user-facing message with internal session-resume failure text.
  3. Log the resume failure internally with enough metadata to debug, for example follow-up id, original session key/id, delivery target, and error cause.
  4. Preserve the command result/status content in the fallback delivery.
#tool integration#LLM response#prompt template#agent execution#callback error

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 Exec follow-up fallback should retry session resume and avoid user-facing internal prefix [1 pull requests, 1 participants]