fix(cron): respect recovered tool errors by Elarwei001 · Pull Request #84156 · openclaw/openclaw

Elarwei001 · 2026-05-19T14:00:48Z

Summary

Problem: cron isolated runs can mark a recovered task as failed when the final payload list only contains isError tool payloads, even though the agent produced terminal assistant-visible output.
Solution: separate fatal run signals from recoverable tool-error payloads before choosing the cron final status/output.
What changed: resolveCronPayloadOutcome now records errorPayloadRecovery and treats later payload output, message-delivery warnings, or terminal assistant-visible text as recovery paths when no typed fatal signal exists.
What did NOT change (scope boundary): meta.error, fatal failureSignal, denial markers, structured/media delivery payload handling, and real unrecovered trailing errors remain fatal.

Motivation

This closes a known cron false-negative path where a scheduled job can finish useful work but be persisted as error because an intermediate tool failure wins over the recovered final assistant result.
The behavior is already tracked in [Bug] Cron task summary ignores agent self-correction - picks tool error over final assistant reply #74807 and bug(cron): isolated-job status is non-deterministic when an agent recovers from a tool error #81514. This PR focuses on the cron outcome classifier instead of only changing summary text selection.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Bug] Cron task summary ignores agent self-correction - picks tool error over final assistant reply #74807
Related bug(cron): isolated-job status is non-deterministic when an agent recovers from a tool error #81514
Related fix(cron): prefer finalAssistantVisibleText over raw error text in task summary #74840
This PR fixes a bug or regression

Real behavior proof (required for external PRs)

Behavior or issue addressed: recovered cron output should persist as ok instead of error when the only remaining error evidence is recoverable tool payload text.
Real environment tested: local OpenClaw checkout on macOS, Node from the repository toolchain, branch fix/cron-recovered-tool-error at commit 3cb013e77a.
Exact steps or command run after this patch:

node --import tsx - <<'NODE'
import { resolveCronPayloadOutcome } from './src/cron/isolated-agent/helpers.ts';

const outcome = resolveCronPayloadOutcome({
  payloads: [
    { text: 'redacted tool failure', isError: true },
    { text: 'redacted retry failure', isError: true },
  ],
  finalAssistantVisibleText: 'Recovered final answer from the cron task.',
  preferFinalAssistantVisibleText: true,
});

console.log(JSON.stringify({
  hasFatalErrorPayload: outcome.hasFatalErrorPayload,
  status: outcome.hasFatalErrorPayload ? 'error' : 'ok',
  outputText: outcome.outputText,
  deliveryPayloads: outcome.deliveryPayloads,
  errorPayloadRecovery: outcome.errorPayloadRecovery,
  embeddedRunError: outcome.embeddedRunError ?? null,
}, null, 2));
NODE

Evidence after fix (copied live output):

{
  "hasFatalErrorPayload": false,
  "status": "ok",
  "outputText": "Recovered final answer from the cron task.",
  "deliveryPayloads": [
    {
      "text": "Recovered final answer from the cron task."
    }
  ],
  "errorPayloadRecovery": {
    "hadErrorPayload": true,
    "recovered": true,
    "recoveredBy": "terminalAssistantText"
  },
  "embeddedRunError": null
}

Observed result after fix: the recovered output is selected, hasFatalErrorPayload is false, and the final status derived by cron is ok.
What was not tested: a full scheduled daemon run against a live private cron job; the proof uses a redacted local reproduction of the outcome classifier to avoid exposing private task content.
Before evidence (optional but encouraged): the prior regression test expected the same all-error-payload shape to return only the last error payload even when finalAssistantVisibleText was present.

Root Cause (if applicable)

Root cause: resolveCronPayloadOutcome classified any last isError payload as fatal unless a later non-error payload existed, so all-error-payload runs could not be recovered by terminal assistant-visible text.
Missing detection / guardrail: there was no explicit recovery state distinguishing recoverable tool payload errors from fatal run-level signals.
Contributing context (if known): cron delivery already receives finalAssistantVisibleText, but fatal payload classification ran before that text could act as recovered terminal output.

Regression Test Plan (if applicable)

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/cron/isolated-agent.helpers.test.ts
Scenario the test should lock in: all payloads are isError, final assistant-visible text is present and preferred, no typed fatal signal exists, and cron resolves an ok outcome with recovered final text.
Why this is the smallest reliable guardrail: the bug is in the pure outcome classifier used by cron finalization and interim retry logic.
Existing test that already covers this (if any): existing tests covered later non-error payload recovery, message-delivery warning recovery, run-level fatal errors, and denial markers; this PR updates the all-error-payload regression case and adds a denial guard.
If no new test is added, why not: N/A.

User-visible / Behavior Changes

Cron runs that recover from intermediate tool errors can now be recorded as successful and surface the final assistant result instead of the last recoverable tool error.

Diagram (if applicable)

Before:
[tool error payloads] -> [final assistant recovered] -> [last error payload wins] -> [cron status: error]

After:
[tool error payloads] -> [final assistant recovered] -> [recovery classified] -> [cron status: ok]

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: macOS local checkout
Runtime/container: repository Node/pnpm toolchain
Model/provider: N/A for classifier reproduction
Integration/channel (if any): cron isolated-agent outcome classifier
Relevant config (redacted): preferFinalAssistantVisibleText: true

Steps

Pass redacted all-error payloads plus terminal assistant-visible text into resolveCronPayloadOutcome.
Verify hasFatalErrorPayload resolves false and output/delivery use final assistant text.
Run focused cron/helper validation and repository checks.

Expected

Recovered terminal assistant-visible text should produce a non-fatal cron outcome when no typed fatal signal exists.

Actual

After this patch, the redacted reproduction returns status: "ok", recoveredBy: "terminalAssistantText", and no embedded run error.

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:
- Recovered all-error payloads now prefer terminal assistant text and resolve non-fatal.
- Later successful payload recovery still resolves non-fatal.
- Message delivery warning recovery still resolves non-fatal.
- Denial text, run-level errors, and fatal failure signals remain fatal.
Edge cases checked:
- Structured/media payloads are not collapsed into final text.
- Earlier partial output plus a real trailing error remains fatal when final assistant text is only the same partial output.
What you did not verify:
- Full live private cron daemon run after patch.
- Full pnpm test; focused tests and pnpm build/pnpm check were run instead.
- codex review --base origin/main; the installed Codex CLI does not expose a review subcommand, and a read-only codex exec review attempt failed with 401 Unauthorized.

AI-assisted: yes. I understand the changed classifier path and the added tests.

Validation run locally:

node scripts/test-projects.mjs src/cron/isolated-agent.helpers.test.ts src/cron/isolated-agent/run.meta-error-status.test.ts src/cron/isolated-agent/run.message-tool-policy.test.ts src/agents/pi-embedded-runner/run/payloads.errors.test.ts
pnpm tsgo:test:src
pnpm check
pnpm build

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.

No bot review conversations were open when this PR body was updated.

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

Risk: terminal assistant text could hide a real fatal condition.
- Mitigation: recovery is blocked when meta.error, fatal failureSignal, denial markers, structured delivery payloads, or an unrecovered real trailing error should stay fatal.

clawsweeper · 2026-05-19T14:02:19Z

Codex review: found issues before merge. Reviewed June 30, 2026, 4:20 PM ET / 20:20 UTC.

Summary
The PR broadens cron isolated-agent payload classification so terminal assistant-visible text can recover all-error tool payload lists, and adds helper-test expectations for recovery metadata.

PR surface: Source +36, Tests +32. Total +68 across 2 files.

Reproducibility: yes. source-level: current main still has a helper test where all payloads are errors and preferred final assistant text exists, yet the last error payload wins and cron finalization derives status from this helper.

Review metrics: 1 noteworthy metric.

Recovered-error classifier surface: 1 fatality predicate broadened, 1 helper result field added. This helper decides whether cron persists a run as ok or error and whether normal delivery or failure notification runs.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦞 diamond lobster
Patch quality: 🧂 unranked krab
Result: blocked by patch quality or review findings.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Refresh the branch against current main and preserve the newer warning, metadata, structured-delivery, and fatal-signal safeguards.
[P2] Narrow terminal recovery to explicit non-terminal tool-warning evidence or add maintainer-approved status metadata/tests for the broader contract.

Mantis proof suggestion
A live cron-to-Telegram proof would materially verify the end-to-end user-visible delivery path affected by this classifier. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis telegram live: run an isolated cron with a recovered tool error and verify final assistant output is delivered instead of a failure notice.

Risk before merge

[P1] The branch is conflicting against current main, so the exact merge result must be refreshed before maintainers can review it as a landing candidate.
[P1] The proposed terminal-assistant recovery rule is broader than current main's warning/metadata-based recovery and could persist genuine payload-only failures as ok if no typed fatal signal is present.
[P1] The same fatality decision controls cron run status, delivery, failure notifications, and consecutive error state, so an overly broad predicate can misroute user-visible cron messages.
[P1] The related diagnostic path in Cron isolated session false positive: tool-level error marks run as failed despite successful execution #91532 may remain unresolved because agent-run diagnostics can still carry the same recovered tool error outside payload classification.

Maintainer options:

Refresh And Narrow Recovery (recommended)
Rebase onto current main and make terminal assistant text recover only explicit non-terminal warning evidence or maintainer-approved status metadata.
Accept Broader Cron Semantics
Maintainers can intentionally let final assistant text override more payload errors, but should own the monitoring and failure-alert contract before merge.
Pause For Canonical Contract
If the related false-error, false-OK, and duplicate-diagnostic reports need one design, pause this PR and consolidate around the canonical cron status issue.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Refresh the PR on current main and narrow the recovery predicate so terminal assistant-visible text only clears payload fatality for explicit non-terminal tool warnings/metadata or another maintainer-approved recovery marker; preserve current fatal run-level errors, fatal failure signals, structured delivery payloads, and true trailing error tests.

Next step before merge

[P2] Manual review is needed because the remaining blocker is the maintainer-owned cron status contract plus a conflicting branch, not a safe standalone automation repair.

Security
Cleared: The diff changes TypeScript cron classifier logic and tests only; it adds no dependency, workflow, permission, secret, package-resolution, or downloaded-code surface.

Review findings

[P1] Narrow terminal recovery to proven tool warnings — src/cron/isolated-agent/helpers.ts:305-315

Review details

Best possible solution:

Refresh on current main and land a maintainer-approved cron outcome contract that preserves true fatal run-level signals while treating explicitly recovered non-terminal tool errors as diagnostics instead of failed runs.

Do we have a high-confidence way to reproduce the issue?

Yes, source-level: current main still has a helper test where all payloads are errors and preferred final assistant text exists, yet the last error payload wins and cron finalization derives status from this helper.

Is this the best way to solve the issue?

No, not as submitted. The resolver is the right layer, but this branch is conflicting and its terminal recovery predicate is broader than current main's warning/metadata contract.

Full review comments:

[P1] Narrow terminal recovery to proven tool warnings — src/cron/isolated-agent/helpers.ts:305-315
This clears fatality for text-only error payloads whenever preferred final assistant text exists and no run-level or fatal signal is set. Current main only recovers recognized tool-warning or metadata-marked non-terminal paths; this broader predicate can persist a genuine terminal tool error as ok and route normal delivery instead of failure handling.
Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 640258d7b31d.

Label changes

Label justifications:

P2: This is a bounded cron reliability fix with real operator-visible status and delivery impact, but not a crash, security bypass, or unusable runtime.
merge-risk: 🚨 compatibility: The PR intentionally changes which recovered cron runs persist as ok instead of error, which can affect existing monitoring and alerting behavior.
merge-risk: 🚨 session-state: The changed classifier result feeds persisted cron run status, output text, diagnostics, and failure counters.
merge-risk: 🚨 message-delivery: The same fatality decision gates normal cron delivery versus failure notification delivery.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦞 diamond lobster and patch quality is 🧂 unranked krab.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body includes copied live output from invoking the real resolver in a local OpenClaw checkout at the PR head, showing the recovered status/output path.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied live output from invoking the real resolver in a local OpenClaw checkout at the PR head, showing the recovered status/output path.
mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The cron status decision can visibly change a Telegram announce from a failure notice to final assistant output, which a short live Telegram proof can show.

Evidence reviewed

PR surface:

Source +36, Tests +32. Total +68 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	46	10	+36
Tests	1	35	3	+32
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	81	13	+68

What I checked:

PR diff: The PR adds errorPayloadRecovery and lets terminal assistant-visible text recover all-error payload lists when no run-level error, fatal failure signal, structured delivery payload, or denial text is present. (src/cron/isolated-agent/helpers.ts:305, 3cb013e77a12)
Current main recovery gates: Current main already recovers later successful payloads, presentation warnings, metadata-marked non-terminal tool warnings, and tool-warning-shaped error payloads, but it does not trust generic all-error payloads solely from final assistant text. (src/cron/isolated-agent/helpers.ts:259, 640258d7b31d)
Current main source reproduction: Current main still has a helper test where two error payloads plus preferred finalAssistantVisibleText return the last error payload, so this PR's central requested behavior is not already implemented. (src/cron/isolated-agent.helpers.test.ts:326, 640258d7b31d)
Cron finalization caller: runCronIsolatedAgentTurn feeds payloads, run-level error, failure signal, and final assistant text into resolveCronPayloadOutcome, then persists status and delivery behavior from hasFatalErrorPayload. (src/cron/isolated-agent/run.ts:1186, 640258d7b31d)
User-visible delivery state: Cron service maps status: error into not-delivered state, failure notification state, and consecutive error counters, so the helper predicate affects operator-visible behavior. (src/cron/service/timer.ts:600, 640258d7b31d)
Latest release behavior: The v2026.6.11 tag contains the same all-error-payload test expectation as current main, so the central recovery behavior has not shipped. (src/cron/isolated-agent.helpers.test.ts:326, e085fa1a3ffd)

Likely related people:

Agustin Rivera: Current blame attributes the inspected helper/test recovery gates in this checkout to commit 6ead092. (role: recent area contributor; confidence: medium; commits: 6ead09230284; files: src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent.helpers.test.ts)
steipete: Peter Steinberger authored the May 2026 commit keeping cron final output over tool warnings in the same helper/test boundary. (role: adjacent cron output contributor; confidence: high; commits: c8a953af9371; files: src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent.helpers.test.ts)
abnershang: Merged PR history for commit 6048cd4 credits abnershang on recovered tool-warning diagnostic handling in this helper area. (role: adjacent recovery behavior contributor; confidence: medium; commits: 6048cd43a5ab; files: src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent.helpers.test.ts, src/cron/run-diagnostics.ts)
sercada: Sergio Cadavid authored the fatal structured-error completion suppression work that shares the same cron finalization and delivery boundary. (role: adjacent fatal-delivery behavior contributor; confidence: high; commits: 0c7220f5da78; files: src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent/run.ts)
welfo-beo: welfo-beo authored the cron Telegram final announce delivery commit that introduced final assistant output handling in this surface. (role: adjacent delivery feature contributor; confidence: medium; commits: 81c7304a18b8; files: src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent/run.ts, src/cron/isolated-agent.helpers.test.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Elarwei001 · 2026-05-19T14:10:25Z

@clawsweeper re-review

clawsweeper · 2026-05-19T14:12:26Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26102875741
Updated: 2026-05-19T14:19:51.987Z

clawsweeper · 2026-05-23T04:43:22Z

ClawSweeper PR egg

✨ Hatched: 🌱 uncommon Brave Shellbean

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

Merged PRs are hatchable.
Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🌱 uncommon.
Trait: purrs at green checks.
Image traits: location proof lagoon; accessory lint brush; palette seafoam, black, and opal; mood focused; pose stepping out of a freshly hatched shell; shell woven fiber shell; lighting calm overcast light; background tiny shells and proof notes.
Share on X: post this hatch
Copy: My PR egg hatched a 🌱 uncommon Brave Shellbean in ClawSweeper.

What is this egg doing here?

Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

wangwllu · 2026-06-13T13:55:33Z

Friendly nudge — this PR has been waiting on review since 2026-05-19; ran into another repro of the underlying bug today (full data on #91532 comment).

One thing the new repro surfaced that may be worth folding into this PR's scope before merge: the failed cron run had two diagnostics entries with identical text but different sources:

{ "source": "tool",      "severity": "error", "message": "⚠️ 🩹 Apply Patch failed" }
{ "source": "agent-run", "severity": "error", "message": "⚠️ 🩹 Apply Patch failed" }

resolveCronPayloadOutcome (what this PR teaches to recover) seems to only cover the tool/payload path. The agent-run-severity diagnostic looks like it's collected separately and ends up driving deliveryError / failureNotificationDelivery.error even when terminal assistantText is a clear success ("PR opened: …"). If that's a separate code path, the recovery story may still be incomplete after this lands.

Happy to share the full trajectory + run JSON if useful — just ping.

(Real behavior proof is the only red check; everything else is green.)

openclaw-barnacle · 2026-07-15T04:21:00Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

openclaw-barnacle · 2026-07-22T04:28:58Z

Closing due to inactivity.
If you believe this PR should be revived, post in #clawtributors on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

fix(cron): respect recovered tool errors

3cb013e

Elarwei001 mentioned this pull request May 19, 2026

[Bug] Cron task summary ignores agent self-correction - picks tool error over final assistant reply #74807

Open

openclaw-barnacle Bot added size: S triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 19, 2026

openclaw-barnacle Bot added proof: supplied External PR includes structured after-fix real behavior proof. and removed triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 19, 2026

clawsweeper Bot mentioned this pull request May 20, 2026

feat(cron): honor ===DONE_OK=== sentinel for cron-success classification #72135

Closed

3 tasks

clawsweeper Bot mentioned this pull request Jun 9, 2026

Cron isolated session false positive: tool-level error marks run as failed despite successful execution #91532

Open

clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels Jun 15, 2026

This was referenced Jun 18, 2026

Cron run drops a produced deliverable when an ancillary backgrounded tool exits non-zero #94533

Closed

bug(cron): isolated-job status is non-deterministic when an agent recovers from a tool error #81514

Open

clawsweeper Bot had a problem deploying to qa-live-shared June 21, 2026 01:00 Failure

clawsweeper Bot mentioned this pull request Jun 22, 2026

fix(cron): allow recovered early tool errors to succeed delivery (#94846) #94862

Closed

openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Jul 15, 2026

openclaw-barnacle Bot closed this Jul 22, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(cron): respect recovered tool errors#84156

fix(cron): respect recovered tool errors#84156
Elarwei001 wants to merge 1 commit into
openclaw:mainfrom
Elarwei001:fix/cron-recovered-tool-error

Elarwei001 commented May 19, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 19, 2026 •

edited

Loading

Uh oh!

Elarwei001 commented May 19, 2026

Uh oh!

clawsweeper Bot commented May 19, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 23, 2026

Uh oh!

wangwllu commented Jun 13, 2026

Uh oh!

openclaw-barnacle Bot commented Jul 15, 2026

Uh oh!

openclaw-barnacle Bot commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

Elarwei001 commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Motivation

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Real behavior proof (required for external PRs)

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

clawsweeper Bot commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Elarwei001 commented May 19, 2026

Uh oh!

clawsweeper Bot commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented May 23, 2026

Hatch command

Uh oh!

wangwllu commented Jun 13, 2026

Uh oh!

openclaw-barnacle Bot commented Jul 15, 2026

Uh oh!

openclaw-barnacle Bot commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Elarwei001 commented May 19, 2026 •

edited

Loading

clawsweeper Bot commented May 19, 2026 •

edited

Loading

clawsweeper Bot commented May 19, 2026 •

edited

Loading