fix(edit): preserve unrelated lines during fuzzy text matching by SebTardif · Pull Request #90060 · openclaw/openclaw

SebTardif · 2026-06-03T23:42:59Z

Summary

When applyEditsToNormalizedContent needed fuzzy matching for any edit, it normalized the entire file via normalizeForFuzzyMatch and used that as the base for all splicing. This silently rewrote every line: stripping trailing whitespace, replacing smart quotes/em dashes with ASCII, and applying NFKC normalization to lines the edit never touched. The diff and on-disk output were both derived from this fully normalized base, so the collateral damage was invisible to both the model and the TUI preview.

Fix

Instead of normalizing the entire file when a fuzzy match is needed, the fix:

Keeps the original content as baseContent (always)
Adds a mapNormalizedOffsetToOriginal helper that maps character positions from fuzzy-normalized space back to original space using a line-based offset table
For each fuzzy-matched edit, maps the match start/end positions back to the original content before splicing

This works because normalizeForFuzzyMatch preserves line count and performs 1:1 character replacements within each line (smart quotes, dashes, special spaces, NFKC). The only length-changing operation is trimEnd(), which only affects line endings and is accounted for by the per-line offset mapping.

Real behavior proof

Behavior addressed: A single fuzzy edit silently normalizes and rewrites every line in the file, corrupting smart quotes, em dashes, and trailing whitespace on lines the edit never touched.

Real environment tested: macOS 15.5, Node v26.0.0, OpenClaw built from patched source at /tmp/wt-89994.

Exact steps or command run after this patch:

Step 1. Build from branch and verify fix in compiled dist:

cd /tmp/wt-89994
pnpm install --frozen-lockfile
pnpm build
grep -n "mapNormalizedOffsetToOriginal" dist/sessions-Vxbh9RFF.js

Step 2. Run tsx proof script that exercises the production code path:

npx tsx proof-89994.ts

Evidence after fix: terminal output from the patched build:

The fix is active in the production bundle:

$ grep -n "mapNormalizedOffsetToOriginal" dist/sessions-Vxbh9RFF.js
5204:function mapNormalizedOffsetToOriginal(origLines, normLines, normalizedOffset) {
5245:const origStart = mapNormalizedOffsetToOriginal(origLines, normLines, matchResult.index);
5246:const origEnd = mapNormalizedOffsetToOriginal(origLines, normLines, matchResult.index + matchResult.matchLength);

Terminal confirms fuzzy edits now preserve unrelated lines:

$ npx tsx proof-89994.ts
=== BEFORE (original file content) ===
  Line 1: "const greeting = \"Hello world\";   "
  Line 2: "const name = \u2018Alice\u2019;"
  Line 3: "const dash = \"foo\u2014bar\";"
  Line 4: "const end = 42;"

=== What normalizeForFuzzyMatch would do to the ENTIRE file ===
  Line 1 CHANGED: "const greeting = \"Hello world\";   " -> "const greeting = \"Hello world\";"
  Line 2 CHANGED: "const name = \u2018Alice\u2019;" -> "const name = 'Alice';"
  Line 3 CHANGED: "const dash = \"foo\u2014bar\";" -> "const dash = \"foo-bar\";"
  3 lines would be silently modified

=== Applying fuzzy edit: change smart-quoted name ===
=== AFTER (result) ===
  Line 1: "const greeting = \"Hello world\";   "
  Line 2: "const name = \"Bob\";"
  Line 3: "const dash = \"foo\u2014bar\";"
  Line 4: "const end = 42;"

=== Verification ===
Trailing whitespace on line 1 preserved: PASS
Em dash on line 3 preserved: PASS
Edit correctly applied on line 2: PASS
baseContent is original (not normalized): PASS

ALL CHECKS PASSED: fuzzy edit only affects the matched region

Observed result after fix: Terminal output confirms that after the fix, fuzzy-matched edits only modify the targeted region. Line 1 retains its 3 trailing spaces, line 3 retains its em dash (U+2014), and only line 2 (the edit target) is changed. Before this fix, all 3 lines would have been silently normalized.

What was not tested: Live gateway with real agent sessions editing files with mixed Unicode content. The fix was verified via direct function calls and the compiled dist bundle.

clawsweeper · 2026-06-03T23:45:14Z

Codex review: needs maintainer review before merge. Reviewed July 1, 2026, 3:00 PM ET / 19:00 UTC.

Summary
The PR changes the shared edit-diff helper to keep original LF-normalized content as the write/diff base, map fuzzy-normalized offsets back to original content, and add regression tests for Unicode and trailing-whitespace preservation.

PR surface: Source +123, Tests +233. Total +356 across 2 files.

Reproducibility: yes. Source-level reproduction is high-confidence: current main replaces the write/diff base with whole-file normalizeForFuzzyMatch output whenever any edit uses fuzzy matching, and edit.ts writes that returned newContent; I did not execute tests in this read-only pass.

Review metrics: none identified.

Stored data model
Persistent data-model change detected: serialized state: src/agents/sessions/tools/edit-diff.ts, unknown-data-model-change: src/agents/sessions/tools/edit-diff.test.ts, unknown-data-model-change: src/agents/sessions/tools/edit-diff.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #89994
Summary: This PR is the open candidate fix for the canonical fuzzy-edit whole-file normalization corruption issue; nearby edit diagnostic PRs are adjacent, and closed same-title attempts were not merged replacements.

Members:

canonical: Bug: a fuzzy edit silently normalizes and rewrites unrelated lines across the whole file #89994 - The PR body uses closing syntax for this issue and changes the implicated edit-diff helper.
partial_overlap: edit 工具稳定性改进：4 重防护机制 #62863 - The older issue requested broader edit fuzzy/whitespace behavior; this PR fixes a corruption side effect in that same area.
duplicate: fix(edit): preserve unrelated lines during fuzzy text matching #96636 - This closed-unmerged PR attempted the same fuzzy-edit preservation fix and explicitly built on this PR.
duplicate: fix: scope fuzzy-edit normalization to matched region only (#89994) #96814 - This closed-unmerged PR attempted another fix for the same canonical fuzzy-edit preservation bug.
adjacent_distinct: Suggest closest edit match when oldText is missing #88531 - That open PR changes closest-match hints when oldText is missing, not fuzzy replacement preservation.
2 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

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

Rank-up moves:

[P2] Let the current required CI jobs complete and inspect any touched-surface failures before merge.

Risk before merge

[P1] The diff changes central edit splice offset mapping; if the custom NFKC mapper is wrong, fuzzy edits can still write the wrong bytes to user files.
[P1] Live PR status was mergeable but unstable, with broad CI still in progress at review time, so landing should wait for required checks and maintainer inspection.

Maintainer options:

Finish mapper validation before landing (recommended)
Wait for the current CI/Testbox results and have a maintainer review the NFKC offset mapping before merging the data-corruption fix.
Use an equivalent narrower mapper if preferred
If maintainers are uncomfortable with this mapper shape, preserve the same original-base behavior and tests in an equivalent shared-helper implementation.
Accept the splice-mapper risk
Maintainers may intentionally land with the remaining mapper risk if they judge the tests and proof adequate for the P0 corruption fix.

Next step before merge

No automated repair is identified; the PR should proceed through maintainer review and CI because the remaining risk is validation of a custom file-write offset mapper.

Security
Cleared: The diff changes TypeScript edit-tool logic and colocated tests only; no dependency, workflow, secret, package, or supply-chain surface is changed.

Review details

Best possible solution:

Land this PR, or an equivalent focused helper fix, after current CI and maintainer review confirm the Unicode offset mapper and regression coverage.

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

Yes. Source-level reproduction is high-confidence: current main replaces the write/diff base with whole-file normalizeForFuzzyMatch output whenever any edit uses fuzzy matching, and edit.ts writes that returned newContent; I did not execute tests in this read-only pass.

Is this the best way to solve the issue?

Yes. The PR fixes the shared helper used by both execution and preview, keeping the original base and mapping only fuzzy match offsets; fixing only edit.ts would leave preview/caller drift.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 5db7c3797de3.

Label changes

Label justifications:

P0: The PR targets silent on-disk file corruption in the core edit tool's fuzzy matching path.
merge-risk: 🚨 other: The patch changes custom Unicode offset mapping for file writes, where a subtle mapper error could splice the wrong bytes.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes terminal proof from a patched build and a direct production-helper exercise showing after-fix preservation of unrelated trailing whitespace and Unicode characters.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes terminal proof from a patched build and a direct production-helper exercise showing after-fix preservation of unrelated trailing whitespace and Unicode characters.

Evidence reviewed

PR surface:

Source +123, Tests +233. Total +356 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	140	17	+123
Tests	1	233	0	+233
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	373	17	+356

What I checked:

Repository policy read: Root AGENTS.md and scoped src/agents/AGENTS.md were read fully; their deep PR review, source/test proof, no-changelog, and agents test guidance shaped this review. (AGENTS.md:1, 5db7c3797de3)
Current main still has the reported splice base: Current main sets baseContent to normalizeForFuzzyMatch(normalizedContent) whenever any edit used fuzzy matching, then matches and splices against that normalized base. (src/agents/sessions/tools/edit-diff.ts:227, 5db7c3797de3)
Runtime caller writes the helper output: The edit tool writes restoreLineEndings(newContent) and generates both diff and patch from baseContent versus newContent, so the helper controls on-disk mutation and preview honesty. (src/agents/sessions/tools/edit.ts:443, 5db7c3797de3)
Latest release remains affected: v2026.6.11 resolves to e085fa1 and contains the same fuzzy-normalized baseContent selection. (src/agents/sessions/tools/edit-diff.ts:218, e085fa1a3ffd)
PR head fixes the shared helper layer: The PR head keeps baseContent as normalizedContent, lazily builds original and fuzzy-normalized line tables, and maps fuzzy match start/end offsets back before splicing. (src/agents/sessions/tools/edit-diff.ts:327, 5151cca255e4)
Regression coverage is focused on the corruption cases: The added tests cover unrelated trailing whitespace, smart quotes, em dashes, ligature expansion, combining-character composition, length-neutral NFKC shifts, Hangul Jamo composition, and original baseContent preservation. (src/agents/sessions/tools/edit-diff.test.ts:18, 5151cca255e4)

Likely related people:

vincentkoc: CONTRIBUTING.md lists Vincent Koc for Agents, and current path history includes a release commit touching the edit helper files. (role: adjacent owner; confidence: medium; commits: e085fa1a3ffd; files: CONTRIBUTING.md, src/agents/sessions/tools/edit-diff.ts, src/agents/sessions/tools/edit.ts)
zw-xysk: Merged PR fix(tools): treat no-op writes and edits as terminal tool-loop failures (fixes #96983) #97044 recently changed edit/write no-op behavior in the same session-tool path, including edit-diff.ts and edit.ts. (role: recent area contributor; confidence: medium; commits: ab966c214be0, e298dad76951; files: src/agents/sessions/tools/edit-diff.ts, src/agents/sessions/tools/edit.ts, src/agents/sessions/tools/edit.test.ts)
huangjianxiong: Current checkout blame attributes the central helper lines to a large snapshot-style commit that introduced the files in this history; routing confidence is low because the commit is broad. (role: recent area contributor; confidence: low; commits: 8abd5d40712d; files: src/agents/sessions/tools/edit-diff.ts, src/agents/sessions/tools/edit.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.

mapNormalizedOffsetToOriginal assumed 1:1 within-line character positions, but NFKC normalization can expand compatibility characters (e.g., U+FB03 to "ffi"). This caused the fuzzy match replacement to splice at the wrong position when a NFKC-expanding character appeared before the match target on the same line. Add mapLineOffsetThroughNfkc that walks original code points and tracks cumulative NFKC expansion to compute the correct original offset. Includes a fast path when NFKC does not change the line length. Addresses ClawSweeper P1 finding on PR openclaw#90060.

SebTardif · 2026-06-04T02:15:57Z

@clawsweeper re-review

clawsweeper · 2026-06-04T02:16:00Z

🦞🧹
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/26925962323
Updated: 2026-06-04T02:23:57.155Z

mapNormalizedOffsetToOriginal assumed 1:1 within-line character positions, but NFKC normalization can expand compatibility characters (e.g., U+FB03 to "ffi"). This caused the fuzzy match replacement to splice at the wrong position when a NFKC-expanding character appeared before the match target on the same line. Add mapLineOffsetThroughNfkc that walks original code points and tracks cumulative NFKC expansion to compute the correct original offset. Includes a fast path when NFKC does not change the line length. Addresses ClawSweeper P1 finding on PR openclaw#90060.

@SebTardif

Adopted from PR openclaw#90060 (by @SebTardif) with ClawSweeper P1 fix: The original PR's NFKC fast-path checked length equality (nfkcLine.length === origLine.length) to skip offset mapping. This is incorrect — NFKC can preserve total code-unit length while shifting internal positions. For example, "ﬁ X é" (U+FB01 + X + e+combining-acute) normalizes to "fi X é" — both are 6 code units, but X shifts from codepoint 2 to 3. Fixed by comparing string identity (nfkcLine === origLine) instead of length. Added regression test for this exact length-neutral mixed case. Also includes the original PR's 5 commits: - Preserve original content as baseContent (no whole-file normalization) - Map fuzzy-normalized offsets back to original via per-line segment mapper - Handle NFKC expansion, composition, and partial ligature matches - Use Array.from instead of spread for Unicode surrogate-pair safety Fixes openclaw#89994. Upstream PR: openclaw#90060

@SebTardif

Adopted from PR openclaw#90060 (by @SebTardif) with ClawSweeper P1 fix: The original PR's NFKC fast-path checked length equality (nfkcLine.length === origLine.length) to skip offset mapping. This is incorrect — NFKC can preserve total code-unit length while shifting internal positions. For example, "ﬁ X é" (U+FB01 + X + e+combining-acute) normalizes to "fi X é" — both are 6 code units, but X shifts from codepoint 2 to 3. Fixed by comparing string identity (nfkcLine === origLine) instead of length. Added regression test for this exact length-neutral mixed case. Also includes the original PR's 5 commits: - Preserve original content as baseContent (no whole-file normalization) - Map fuzzy-normalized offsets back to original via per-line segment mapper - Handle NFKC expansion, composition, and partial ligature matches - Use Array.from instead of spread for Unicode surrogate-pair safety Fixes openclaw#89994. Upstream PR: openclaw#90060

@SebTardif

Adopted from PR openclaw#90060 (by @SebTardif) with ClawSweeper P1 fix: The original PR's NFKC fast-path checked length equality (nfkcLine.length === origLine.length) to skip offset mapping. This is incorrect — NFKC can preserve total code-unit length while shifting internal positions. For example, "ﬁ X é" (U+FB01 + X + e+combining-acute) normalizes to "fi X é" — both are 6 code units, but X shifts from codepoint 2 to 3. Fixed by comparing string identity (nfkcLine === origLine) instead of length. Added regression test for this exact length-neutral mixed case. Also includes the original PR's 5 commits: - Preserve original content as baseContent (no whole-file normalization) - Map fuzzy-normalized offsets back to original via per-line segment mapper - Handle NFKC expansion, composition, and partial ligature matches - Use Array.from instead of spread for Unicode surrogate-pair safety Fixes openclaw#89994. Upstream PR: openclaw#90060

yetval · 2026-06-29T17:15:53Z

@SebTardif can you fix the rank up moves for this PR? Should get this PR ready for maintainer view.

SebTardif · 2026-06-30T01:13:14Z

@clawsweeper re-review

clawsweeper · 2026-06-30T01:13:17Z

🦞🧹
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.

When a fuzzy match was needed, applyEditsToNormalizedContent normalized the entire file content (stripping trailing whitespace, replacing smart quotes with ASCII, converting em dashes to hyphens, applying NFKC) and used that as the base for splicing. This silently rewrote every line in the file, not just the matched region. Fix: keep the original content as the base and map fuzzy match positions back to the original using a line-based offset table. normalizeForFuzzyMatch preserves line count and performs 1:1 character replacements within lines, so per-line column mapping is correct. Closes openclaw#89994 Signed-off-by: Sebastien Tardif <[email protected]>

mapNormalizedOffsetToOriginal assumed 1:1 within-line character positions, but NFKC normalization can expand compatibility characters (e.g., U+FB03 to "ffi"). This caused the fuzzy match replacement to splice at the wrong position when a NFKC-expanding character appeared before the match target on the same line. Add mapLineOffsetThroughNfkc that walks original code points and tracks cumulative NFKC expansion to compute the correct original offset. Includes a fast path when NFKC does not change the line length. Addresses ClawSweeper P1 finding on PR openclaw#90060.

Group each base character with its following combining marks before normalizing with NFKC, so cross-code-point composition (e.g., e + U+0301 combining acute accent composing to é) is mapped correctly. The previous per-code-point normalization missed these compositions and could splice the wrong original range. Add regression test with a decomposed combining character before a fuzzy match to cover the composition case. Signed-off-by: Sebastien Tardif <[email protected]>

…atches

Signed-off-by: Sebastien Tardif <[email protected]>

The fast path in mapLineOffsetThroughNfkc returned the normalized offset directly when origLine.length === nfkcLine.length. This is wrong because NFKC can shift character positions while preserving total length (e.g., U+FB01 expands 1->2 chars while e+U+0301 composes 2->1 chars, netting to zero). Changed the fast path to compare the full strings (nfkcLine === origLine) so length-neutral NFKC changes always go through the segment walker. Added a regression test using a line with both expansion (U+FB01) and composition (e+U+0301) that is length-neutral under NFKC.

…uping The mapLineOffsetThroughNfkc function previously only grouped base characters with following combining marks (\p{M}). NFKC can also compose adjacent non-mark code points (e.g., Hangul Compatibility Jamo U+3131 + U+314F compose to U+AC00). This caused offset miscalculation when such sequences appeared before a fuzzy-matched region. Replace the combining-mark-only grouping with a greedy approach that extends each segment as long as the next code point participates in NFKC composition (i.e., normalizing the extended segment differs from normalizing each part separately). Add a Hangul Jamo regression test that verifies correct offset mapping when Compatibility Jamo compose under NFKC. Signed-off-by: Sebastien Tardif <[email protected]>

SebTardif · 2026-07-01T18:49:11Z

@clawsweeper review

clawsweeper · 2026-07-01T18:49:14Z

🦞🧹
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.

openclaw-barnacle · 2026-07-16T04:28:44Z

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

SebTardif · 2026-07-16T11:03:53Z

Closing as completed.

The fuzzy-edit bug this PR targeted is fixed on main. Maintainer note on #89994: applyEditsToNormalizedContent now routes fuzzy matches through applyReplacementsPreservingUnchangedLines, preserving original bytes on untouched lines (landed via #99949 / related agent runtime work).

This branch is stale and conflicts with that path, so there is nothing useful left to land here. Thanks to everyone who reviewed and tested along the way.

openclaw-barnacle Bot added agents Agent runtime and tooling size: S proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 3, 2026

SebTardif force-pushed the fix/fuzzy-edit-preserve-unrelated-lines branch from dfe9550 to 7bd1c13 Compare June 4, 2026 02:15

openclaw-barnacle Bot added size: M and removed size: S proof: sufficient ClawSweeper judged the real behavior proof convincing. labels Jun 4, 2026

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 4, 2026

github-actions Bot mentioned this pull request Jun 4, 2026

🦞 OpenClaw 生态日报 2026-06-04 litang9/big_model_radar#12

Open

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 4, 2026

SebTardif force-pushed the fix/fuzzy-edit-preserve-unrelated-lines branch from dad5205 to 06626c4 Compare June 4, 2026 12:18

SebTardif force-pushed the fix/fuzzy-edit-preserve-unrelated-lines branch from 06626c4 to fd227bb Compare June 4, 2026 23:04

SebTardif added 6 commits June 29, 2026 20:02

fix(edit): snap end-of-match offset to segment end for partial NFKC m…

9b78ecd

…atches

fix(edit): use Array.from instead of spread on string for Unicode safety

882f8eb

Signed-off-by: Sebastien Tardif <[email protected]>

SebTardif force-pushed the fix/fuzzy-edit-preserve-unrelated-lines branch from ee15401 to 17ee761 Compare June 30, 2026 03:03

This was referenced Jul 3, 2026

fix(edit): fuzzy edit rewrites unrelated lines across the whole file #99573

Closed

Improve agent runtime correctness from upstream Pi audit #99924

Closed

fix: improve agent runtime correctness from upstream Pi #99949

Merged

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

SebTardif closed this Jul 16, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(edit): preserve unrelated lines during fuzzy text matching#90060

fix(edit): preserve unrelated lines during fuzzy text matching#90060
SebTardif wants to merge 7 commits into
openclaw:mainfrom
SebTardif:fix/fuzzy-edit-preserve-unrelated-lines

SebTardif commented Jun 3, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 3, 2026 •

edited

Loading

Uh oh!

SebTardif commented Jun 4, 2026

Uh oh!

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

yetval commented Jun 29, 2026

Uh oh!

SebTardif commented Jun 30, 2026

Uh oh!

clawsweeper Bot commented Jun 30, 2026 •

edited

Loading

Uh oh!

SebTardif commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading

Uh oh!

openclaw-barnacle Bot commented Jul 16, 2026

Uh oh!

SebTardif commented Jul 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

SebTardif commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Fix

Real behavior proof

Uh oh!

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

Uh oh!

Uh oh!

SebTardif commented Jun 4, 2026

Uh oh!

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

Uh oh!

Uh oh!

yetval commented Jun 29, 2026

Uh oh!

SebTardif commented Jun 30, 2026

Uh oh!

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

Uh oh!

Uh oh!

SebTardif commented Jul 1, 2026

Uh oh!

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

Uh oh!

Uh oh!

openclaw-barnacle Bot commented Jul 16, 2026

Uh oh!

SebTardif commented Jul 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SebTardif commented Jun 3, 2026 •

edited

Loading

clawsweeper Bot commented Jun 3, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 30, 2026 •

edited

Loading

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading