Problem

OpenClaw's redact-D4nea1HF.js automatically replaces apiKey / token / secret values with redacted placeholders ("***" for short values, "<prefix>…<suffix>" for long values) in tool outputs before passing them to the agent model. This redaction is completely transparent to the agent — there is no signal or marker indicating that the output has been redacted.

This creates a serious risk:

• Agents that read config files via tools (terminal("cat openclaw.json"), file-read tool, etc.) see "apiKey": "***" as if it were the real value
• Agents that then modify the config (e.g. change a different field via json.load → edit → json.dump) inadvertently write the redacted placeholder back to disk
• All apiKey fields in the file become "***" — the config is now poisoned
• Next startup: all providers return 401

Evidence

Real incident on 2026-04-18: An agent tried to update an unrelated model setting in openclaw.json. Its read of the file returned redacted values. Its write (full-file json.dump) overwrote 6 real apiKeys with "***". OpenClaw's subsequent .bak rotation fixated the pollution. The system was 401-failing for ~14 hours before root cause was identified (see #68423 for the related backup validation issue).

Proposed Fix

Make redaction explicit to downstream agents by emitting a machine-readable marker alongside the redacted output.

Option A: Structured tool response

{
  "output": "...",
  "redacted": true,
  "redacted_fields": ["models.providers.bailian.apiKey", "plugins.entries.brave.config.webSearch.apiKey"],
  "warning": "Output contains redacted values. DO NOT write this back to config files without re-fetching real values via openclaw config get <path> or environment variables."
}

Option B: Text marker appended to output

... (normal output) ...

[OPENCLAW-REDACTED] Fields redacted in this output: models.providers.bailian.apiKey, plugins.entries.brave.config.webSearch.apiKey
[OPENCLAW-REDACTED] These placeholders are NOT real values. Do not write them back to files.

Option C: Combined (structured + text)

Use a structured response when the tool protocol supports it, fall back to a text marker otherwise. Critical that the marker is always machine-parseable (stable prefix, no localization) so safety skills and linters can detect it reliably.

Why This Matters

Downstream safety measures (skills like config-safety, runtime linters) can detect redacted values in source files — but they cannot help if the agent writes them in the first place. An explicit redaction marker at the tool-output boundary would prevent an entire class of "agent writes back redacted value" incidents at the root.

Related

• [Feature]: 希望支持敏感数据脱敏 #64046 proposes stronger redaction in logs and UI — this issue asks that existing redaction be made visible to agents, which is orthogonal but complementary
• [Bug]: skills.update echoes raw apiKey and env secrets in gateway response #66769 notes skills.update echoes raw apiKey in gateway response — opposite failure mode (not enough redaction) but same underlying design gap (redaction state is implicit)