OpenClaw incident logs: keep the evidence, remove the private context

June 18, 2026 · Security · OpenClawBlog Team

An OpenClaw incident report usually fails in one of two directions. It says only that delivery failed, or it includes a whole transcript, shell output, and configuration file. The first leaves nobody enough to investigate. The second can turn a routine support request into a disclosure event.

The useful middle is a small record of events and timing, not a copy of the operator's private context. OpenClaw's security documentation says Gateway logs may contain tool summaries, errors, and URLs, while session transcripts can contain pasted secrets, file contents, command output, and links. Its preferred sharing surface is openclaw status --all, not an unreviewed raw log.

Keep a forensic copy and a support copy

Before collecting anything, decide which material is for restricted incident handling and which material may leave the machine. Keep those as separate copies.

The restricted copy can preserve the original log or transcript when your incident process requires it. Store it with owner-only permissions and do not place it in a normal ticket, Git working tree, chat room, or shared drive. Create a second artifact by selecting the fields needed to answer the support question. Do not edit the original in place. If you later discover that a pattern was too broad, you need the original to rebuild the packet.

This separation also clarifies the decision. A forensic record may need to establish what an attacker sent. A support report usually needs to establish which subsystem failed, when it failed, and whether the Gateway retried. Those are different disclosure budgets.

Decide what each data class needs

Tokens, message content, and private paths should not be treated as one generic redaction problem. They have different uses and different failure consequences.

OpenClaw's diagnostics export follows much of this model. Its documented privacy section says it keeps subsystem and provider identifiers, status codes, durations, byte counts, queue state, sanitized metadata, and config shape. It omits or redacts chat text, prompts, tool outputs, credentials, tokens, cookies, raw request and response bodies, account identifiers, message identifiers, raw session identifiers, hostnames, and local usernames. When content looks like a payload, the export keeps an omission marker and byte count instead. See the diagnostics export privacy model.

That list is useful, but it is not permission to publish every generated file. The same documentation says to treat a diagnostics ZIP like a secret until it has been reviewed.

Use the least revealing collection surface

Where the question is about an agent run or tool action, the current configuration reference describes a metadata-only audit ledger. It records identity, timing, tool names, and normalized outcomes without storing prompts, message bodies, tool arguments, results, or raw error text. It is a good first source for sequence and attribution when it is enabled, but it is best effort, not a lossless compliance archive. Plugin-local paths that bypass the shared boundaries may not appear. The caveats are documented in OpenClaw's audit and observability reference.

For a delivery or Gateway question, collect a status summary before opening a large log. If a bounded file slice is required, use explicit limits:

openclaw status --all
openclaw logs --plain --utc --limit 200 --max-bytes 250000 > ./incident-log.txt

The CLI reference documents --limit, --max-bytes, --plain, and --utc. The limits control collection size. They do not make arbitrary fields safe to share. A 200-line log can still contain one private URL or one command argument.

For a single support artifact, use the local diagnostics export with smaller bounds than its documented defaults:

openclaw gateway diagnostics export \
  --output ./openclaw-diagnostics.zip \
  --log-lines 200 \
  --log-bytes 250000

The export can include sanitized status, health, config shape, redacted log lines, and a stability bundle. If the incident concerns a crash, the stability data may matter. If it is only a routine delivery failure, omit that bundle when the installed command supports --no-stability-bundle. The available flags and their defaults are listed in the official export reference.

Do not raise exposure while collecting. The logging documentation says normal Gateway WebSocket logging is selective, while --verbose prints all request and response traffic. A remote --url target also skips automatically applied config credentials and may require an explicit token. Keep tokens out of command lines, URLs, shell history, and support transcripts. A more detailed capture is not automatically a better incident record.

Make redaction a configuration change, not a rescue step

OpenClaw states that sensitive-value redaction is always on across console output, file logs, OTLP records, and persisted session transcript text. Its logger masks explicit credential forms, authorization headers, URL credentials, and known token formats. For values at least 18 characters long, the documented mask can retain the first six and last four characters; shorter values become ***. That format can help correlate repeated values locally, but it is not the same as deleting the value from a shared report.

Use logging.redactPatterns for deployment-specific material such as an internal token format or private URL scheme. The configuration reference warns that this setting replaces the default string-regex list for log and transcript output, while built-in form-body, structured authorization-header, and bare AWS-key protections remain active. Tool-payload redaction follows a separate merge rule. Read the Gateway logging reference before changing the list.

A fictional example might look like this:

{
  "logging": {
    "redactPatterns": [
      "corp-[A-Za-z0-9]{32}",
      "https://internal[.][^ ]+"
    ]
  }
}

Keep the pattern definition under review, but never store a real credential beside it as a test value. Register actual secrets through the supported secret path when possible; do not rely on a field name such as token to identify every opaque value.

A public issue in the upstream repository is a useful warning. Issue #42982, opened March 11, 2026, reports that a custom email regex did not redact an email shown in a session log. The page is marked closed, but the opened record does not explain the resolution or establish the behavior of every current version. Treat it as evidence that a configured pattern needs a test, not as proof that current redaction is broken everywhere.

Apply a separate policy to private paths

Path removal deserves its own pass because a path can disclose a customer, project, username, operating system, or internal layout even when it contains no token. OpenClaw's triage documentation says failed-update excerpts redact secrets and local paths before truncation, and that paths inside the prompt are shown relative to ~ or $OPENCLAW_STATE_DIR. It also says the saved prompt path, archive path, and printed shell handoff retain real absolute paths. That distinction is easy to miss.

For a packet you intend to share, use an allowlist of operational fields. Keep the UTC timestamp, severity, subsystem, event name or code, status, duration, retry count, byte count, and a stable local alias for the affected channel or provider. Drop raw cwd, workspace, home, path, hostname, and username values unless the incident handler has a documented reason to retain one.

Replace identities consistently inside the local copy: gateway-a, channel-1, and <PATH:state> are usually enough to preserve relationships. Keep any alias map with the restricted original, not in the shared ZIP. This is a proposed sharing policy. It is stricter than assuming that a sanitized OpenClaw export removes every path emitted by a plugin or host-level error.

Review the sanitized copy with negative tests

Redaction review should ask two questions. Can another operator still reconstruct the failure sequence? Did any forbidden value survive?

For the first question, look for the incident time window, exact OpenClaw version, platform, profile alias, source type, subsystem, error code, retry state, durations, and any queue or byte-count facts needed to separate a transport failure from a content or policy failure. Do not restore the message body merely because it would make the narrative easier to read.

For the second question, test a synthetic fixture containing:

• a fake Gateway or provider token and an authorization header;
• a fake message, prompt, tool result, and URL query value;
• absolute paths containing a fake username and project name;
• cookies, passwords, account-like identifiers, and session-like identifiers.

Search the output for the exact synthetic values and for recognizable path prefixes. Inspect the archive manifest and filenames as well as the text. Run the check against the sanitized copy, and avoid printing matched values to a terminal or CI log. A passing fixture shows that this policy handled this fixture. It does not prove that an unknown plugin will never emit another sensitive shape.

If anything sensitive survives

Stop distribution as soon as a token, message body, command output, or private path appears in the proposed report. Mark that artifact as unsuitable for sharing and do not patch only the visible line while leaving the same source elsewhere in the archive.

If a credential was exposed, follow OpenClaw's incident-response sequence: stop the Gateway when appropriate, close external exposure, freeze risky DM or group access, rotate Gateway authentication, rotate remote-client secrets, and rotate provider or channel credentials. The documentation also recommends reviewing logs, transcripts, configuration changes, and rerunning openclaw security audit --deep. See the operator incident-response guide.

If only a path or message was exposed, regenerate the support copy with a narrower allowlist. If the artifact has already left the organization, treat the disclosure according to the organization's incident process; deleting a ticket attachment does not establish that nobody retained a copy.

Raw transcripts belong in a restricted investigation path. OpenClaw's response guide lists the relevant transcript and a short redacted log tail as possible evidence, while its storage documentation warns that transcripts can contain secrets, file contents, command output, and links. That is a reason to preserve access control, not a reason to paste the transcript into a general support channel.

What a shareable packet can contain

The following is a proposed format, not an OpenClaw export schema:

incident_id: inc-2026-06-18-a
observed_at_utc: 2026-06-18T14:22:00Z
openclaw_version: <exact installed value>
gateway: gateway-a
surface: channel-1
event_sequence: <ordered event aliases>
result: <status or error code>
redaction_policy: support-v1
review: passed synthetic secret and path checks

It preserves the facts another operator can act on while leaving the message and host identity behind. If the recipient needs more, expand one field at a time and repeat the review.

Know what the packet cannot prove

A healthy Gateway status does not prove that a provider accepted a message. A live channel probe does not prove that every route or reply condition succeeded. The diagnostics documentation also cautions that a WebSocket heartbeat timeout records the Gateway's local decision; it does not prove that a ping reached the peer or that the peer caused the failure.

There is a second limit. Filesystem access remains part of the trust boundary. OpenClaw documents session transcripts under the state directory and recommends tight permissions, full-disk encryption, and pruning old logs and transcripts that are no longer needed. Redaction reduces disclosure when an artifact is produced. It does not make the underlying state safe for every user or tenant.

The practical rule is simple: preserve sequence, timing, status, and failure mechanics. Remove identity, content, and credentials unless a restricted incident handler has a documented reason to retain them. A useful report is a carefully selected projection of the incident, not the incident directory in a ZIP.

Sources

1. OpenClaw Gateway logging. Accessed 2026-09-13.
2. OpenClaw diagnostics export. Accessed 2026-09-13.
3. OpenClaw secrets, storage, and logs. Accessed 2026-09-13.
4. OpenClaw audit, logging, diagnostics, and telemetry configuration. Accessed 2026-09-13.
5. OpenClaw CLI logs reference. Accessed 2026-09-13.
6. OpenClaw triage reference. Accessed 2026-09-13.
7. OpenClaw operator incident response. Accessed 2026-09-13.
8. OpenClaw issue #42982: redact logging not working properly. Opened 2026-03-11; accessed 2026-09-13.