How to Use OpenClaw Diffs Tool

OpenClaw diffs is an optional plugin tool for turning changes into reviewable artifacts. It is not an editor. It accepts before and after text or a unified patch, then returns a read-only viewer URL, a rendered file, or both. That makes it useful when an agent needs to show a proposed change clearly before a human approves it.

30-second answer

Enable the diffs plugin, then call it with either before plus after, or a patch. Pick mode view for a canvas-first viewer, file for a rendered PNG or PDF, or both when you want both outputs. Use the viewer URL with canvas present, or send the rendered file through message when a chat review artifact is better.

Good fit

Use diffs for code review, markdown review, proposal review, and before/after explanations. If a teammate asks “what changed?” a visual diff is often better than a paragraph. It also helps when the final recipient should not see raw internal logs, but does need to inspect the actual change.

Inputs and modes

The tool accepts original text and updated text, or a unified patch. Optional fields include path, lang, title, theme, layout, expandUnchanged, fileFormat, fileQuality, and fileScale. The docs mention view, file, and both modes. The older image alias behaves like file for compatibility, but new workflows should use the clearer mode names.

Security posture

Because diffs is read-only, it is a safe presentation layer. It does not apply patches or write files. That separation matters. Generate the review artifact, let the human or workflow decide, then use apply_patch or file-editing tools only after approval if approval is required.

Prompt guidance

The plugin can prepend concise usage guidance into system-prompt space. If you want the tool enabled but do not want that built-in prompt injection, set plugins.entries.diffs.hooks.allowPromptInjection to false. If you want neither guidance nor tool, disable the plugin entirely.

Playbook angle

The Playbook pattern is to make changes easy to review. Agents earn trust when they can show the exact diff without burying the human in implementation chatter.

Runbook checklist

Before you automate this, run one small acceptance test with harmless input. Confirm the tool is available to the right agent, the credential is loaded from config or environment, the output shape matches the workflow, and the failure message is understandable to a tired operator. If the feature touches money, public channels, logged-in browsers, host commands, or customer data, put a review step before the side effect. If it only reads data, still record the source and timestamp so future sessions do not treat stale context as fresh truth. Keep the first version narrow, then expand once the logs show the agent is choosing the right tool for the right reason. When the docs are incomplete, prefer a conservative sentence over a clever invented shortcut that future agents cannot reliably verify. Add one monitoring habit as well: after the first real run, check the transcript or logs for missing prerequisites, broad prompts, stale assumptions, and accidental side effects. Tighten the instruction while the failure is fresh. The best OpenClaw workflows improve in small, documented passes instead of one giant rewrite after something breaks in public. For SEO pages, that same discipline matters: do not promise hidden capabilities, paid-provider limits, or setup shortcuts unless the current docs say so. Trust compounds when the guide is accurate even in the boring operational edge cases that matter during real maintenance windows.

Operator note

How to Use OpenClaw Diffs Tool works best when it is written into a small runbook instead of treated as a magic switch. Record who owns the workflow, which config keys are allowed, which credentials are required, what the agent may do without approval, and what counts as a failure. OpenClaw gives agents broad tools, but the reliable version is boring: one source of truth, one verification step, and one rollback path when a provider or channel behaves differently than expected.