OpenClaw Diagnostic Redaction Was Rewriting Model-Visible Tool Results
Broad diagnostic redaction rewrote source code inside tool results, corrupting later reads and edits. A merged fix confines redaction to diagnostics while preserving the security boundary.
PR #127697 fixes a boundary mistake with an unusual casualty list: the model’s view of its own work. OpenClaw’s diagnostic redaction — the machinery that masks secrets in logs and operator-facing output — was also rewriting model-visible tool results. Source expressions like API_TOKEN = computeToken() reached the model as API_TOKEN = ***. The agent then read and edited text that did not exist in any file, and its edits landed against corrupted context.
Why this cut both ways
Redaction exists to keep secrets out of transcripts, logs, and screenshots that leave the machine. Applied to tool results, though, it didn’t just hide secrets from humans — it falsified evidence the model itself reasons over. Two failure classes follow:
- Corrupted self-correction. An agent reading back a file it had just written saw masked content instead of what was on disk. Later edits were computed from phantom text.
- False suspicion of leakage. Operators inspecting transcripts saw
***where source code should be and could reasonably conclude a secret had leaked into the transcript, when the underlying data never contained one.
The merged fix separates the two audiences: diagnostic surfaces keep their redaction; model-visible tool results are preserved verbatim so downstream reads and edits operate on real bytes.
The security question this raises
Any change to a redaction boundary deserves scrutiny, because the obvious attack is to relabel secret-bearing channels as “model-visible” and slip them past masking. The merged record shows the author reviewed exactly this concern — the PR notes AI-assisted development with human review of the changed redaction boundary before merge. The design principle it lands on is the right one: redact at the point of human/egress exposure, not by mutating shared data in place.
Interpretation: operators should treat this as a correctness repair that narrows an over-broad control rather than a weakening. The secret still must not appear in logs or exports; it now also no longer poisons the model’s input. What changes is who sees *** — diagnostics yes, the model no.
Operator actions
- After upgrading, have an agent read back a scratch file containing a fake credential-shaped string plus ordinary code. Confirm the model reports the ordinary code accurately (the fix working) and check your logs still mask the fake credential (the boundary intact).
- Re-examine any incident where an agent produced wrong edits around credential-like identifiers on affected builds — pre-fix, the model may have been editing against masked text, and blaming prompt drift would have missed the mechanism.
- Keep secret-scanning on transcripts enabled. The fix moves where masking applies; it does not make transcripts a safe place for real credentials.
Limits
The change covers the diagnostic-redaction path feeding tool results. It does not alter exec-approval policy, sandboxing, or any other control governing what tools may run. Environments relying on the old behavior as an accidental last-ditch scrubber for tool output lose that accident — deliberately.
Bottom line
This fix restores a basic invariant: the model should reason about the same bytes the filesystem holds. Upgrade when it reaches your channel, then run the read-back test above once — you are verifying both halves of the contract, that code reads true to the model and that diagnostics still keep secrets out of human reach.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF