Bug
The Edit tool requires exact string matching for oldText with no staleness detection or retry logic. When a file is modified between when an agent reads it and attempts an edit (even by a single character — from a cron, compaction, or the agent's own earlier edit in the same session), the edit fails silently.
Impact
Any agent maintaining living documents hits this constantly — especially during active conversation when context-snapshot crons are also touching the same files. Files like NOW.md, OPEN_LOOPS.md, contacts.md, and any frequently-updated state file become a minefield during active sessions.
The current failure mode requires the agent to:
- Know the edit failed
- Perform a separate
Read call to get the current content
- Recompute the edit
- Retry
This wastes tokens and context window, and agents often don't realize the edit failed until downstream effects surface.
Proposed Fixes
Any of these would help (ordered by implementation cost, lowest first):
Option 1: Return current content on match failure (cheapest win)
On oldText mismatch, return the current file content in the error response so the agent can retry immediately without a separate Read call. This alone would make recovery automatic for well-behaved agents.
Option 2: Line-number-based editing as alternative
Offer a fromLine/toLine mode alongside exact-match. Less precise but immune to whitespace/character drift.
Option 3: Auto-retry with fresh file read
On mismatch, the tool internally re-reads the file and attempts to locate the closest match within a configurable edit distance, then retries.
Option 4: Fuzzy matching with confirmation threshold
Allow matching within some edit distance (e.g., Levenshtein), with a threshold above which the agent is asked to confirm.
Context
- Discovered by Mati (Feral Box Murat agent) and diagnosed by Sam (samantha_clawd_bot)
- The root cause is optimistic concurrency with no retry mechanism
- Particularly acute for
NOW.md which the community is pushing all agents to update frequently throughout sessions
- Related: agents that run pre-compaction memory flushes often race with cron jobs touching the same files
Environment
- OpenClaw 2026.2.14 (c1feda1)
- Model: claude-opus-4-6
- Platform: macOS arm64, Mac Mini M4
Bug
The
Edittool requires exact string matching foroldTextwith no staleness detection or retry logic. When a file is modified between when an agent reads it and attempts an edit (even by a single character — from a cron, compaction, or the agent's own earlier edit in the same session), the edit fails silently.Impact
Any agent maintaining living documents hits this constantly — especially during active conversation when context-snapshot crons are also touching the same files. Files like
NOW.md,OPEN_LOOPS.md,contacts.md, and any frequently-updated state file become a minefield during active sessions.The current failure mode requires the agent to:
Readcall to get the current contentThis wastes tokens and context window, and agents often don't realize the edit failed until downstream effects surface.
Proposed Fixes
Any of these would help (ordered by implementation cost, lowest first):
Option 1: Return current content on match failure (cheapest win)
On
oldTextmismatch, return the current file content in the error response so the agent can retry immediately without a separateReadcall. This alone would make recovery automatic for well-behaved agents.Option 2: Line-number-based editing as alternative
Offer a
fromLine/toLinemode alongside exact-match. Less precise but immune to whitespace/character drift.Option 3: Auto-retry with fresh file read
On mismatch, the tool internally re-reads the file and attempts to locate the closest match within a configurable edit distance, then retries.
Option 4: Fuzzy matching with confirmation threshold
Allow matching within some edit distance (e.g., Levenshtein), with a threshold above which the agent is asked to confirm.
Context
NOW.mdwhich the community is pushing all agents to update frequently throughout sessionsEnvironment