OpenClaw config.get Raw Null: Why Your Raw Config Comes Back Empty

TL;DR: OpenClaw config.get raw null, with "exists": true and a populated parsed object, means your config loaded fine and the gateway deliberately withheld the raw file text. It strips secrets from that text by find-and-replace, and when a secret value also appears somewhere that is not secret, the result no longer matches your config, so it sends null instead. Nothing is wrong with your config, and moving the secret into an environment variable placeholder or making it unique brings raw back.

Contents

• The Output You Are Looking At
• The Four States config.get Can Report
• Why OpenClaw config.get Raw Null Happens
• What We Reproduced on OpenClaw 2026.9.4
• How to Get the Raw Config Back
• When It Is Not This At All
• Key Takeaways
• Frequently Asked Questions

The Output You Are Looking At

You, or an agent acting for you, asked the gateway for its config and got back something shaped like this:

{
  "ok": true,
  "result": {
    "path": "/home/node/.openclaw/openclaw.json",
    "exists": true,
    "raw": null,
    "parsed": {
      "env": { "OPENROUTER_API_KEY": "__OPENCLAW_REDACTED__" },
      "agents": { "defaults": { "model": { "primary": "openrouter/..." } } }
    }
  }
}

That is the response to the gateway’s config.get method, the same call the Control UI makes when it opens the config page and the one an agent’s gateway tool makes when you ask it to read its own settings. Four fields matter:

• path is the config file the gateway read. In a typical Docker install that is /home/node/.openclaw/openclaw.json.
• exists says whether that file was there.
• raw is meant to be the file’s text (JSON or JSON5) with every secret replaced by a placeholder.
• parsed is the same config as a structured object, with the same secrets replaced.

ok: true means the call succeeded. A null in raw is not an error. It is the gateway telling you it chose not to send the text.

The Four States config.get Can Report

raw: null shows up in more than one situation, and the fields around it tell you which one you are in. These come from the config snapshot and redaction code in OpenClaw 2026.9.4:

If your output matches the third row, which is what most people pasting this envelope have, the rest of this guide explains exactly why.

Why OpenClaw config.get Raw Null Happens

OpenClaw never sends a secret to a client. Before any config leaves the gateway, it is redacted twice, once in each form:

1. The structured copy (parsed) is walked field by field, and any field on a sensitive path, such as an API key, a token or a password, has its value swapped for __OPENCLAW_REDACTED__, which is precise because it knows which field it is looking at.
2. The text copy (raw) is a string, so it cannot be walked like that. The gateway collects every secret value it found in step 1 and does a find-and-replace of each one across the whole file text, longest first.

Find-and-replace does not know which field it is in. If the same string also appears somewhere that is not a secret, that copy is replaced too, and the redacted text now says something your config does not.

So the gateway checks its own work: it parses the redacted text, restores the real secrets into it, and compares the result with your actual config. If they are not identical, or the restore fails, it throws the redacted text away and sends raw: null.

Sending nothing is the safe choice: the alternative is handing a client text that is quietly wrong, which the client might then save back over your real file.

This round-trip check has been in OpenClaw’s config code since a March 2026 change titled “avoid raw redaction collisions on round-trip”. Its effect is that raw: null is almost always a sign that one of your secret values is not unique in the file.

What We Reproduced on OpenClaw 2026.9.4

We called the gateway’s own redaction function inside a running 2026.9.4 container with small test configs, to see exactly which shapes trigger it:

Two patterns account for nearly every real case:

• Short or common secret values. A token that is a short word or a small number is very likely to appear elsewhere in a real config, as an agent id, a model name fragment, a port, or a limit. The find-and-replace hits the other copy.
• The same string reused in a non-secret place. Copying a key into a label, a comment-like field, or a URL that the schema does not mark as sensitive is enough.

The same key used in two secret fields is fine, because both copies are supposed to be redacted, so the round trip still matches.

How to Get the Raw Config Back

You do not have to fix anything. The gateway runs on the parsed config either way, and raw: null changes nothing on disk. If you want raw back, for example because a tool or agent depends on reading the text, remove the collision:

1. Move secrets into environment variables and reference them in the config as ${VAR_NAME}. OpenClaw does not treat an unexpanded placeholder as a concrete secret to find-and-replace, so there is nothing to collide, and the file stops containing live keys.
2. Replace short or reused tokens with long, unique ones. A gateway token of a few characters is weak and is also the most likely cause of a collision. Rotate it to a long random value.
3. Find the duplicate. Search the file on the gateway host for each secret value and see which one appears more than once, on the host rather than by pasting the file anywhere.
4. Call config.get again. When no secret string appears outside its own field, raw returns with each secret shown as __OPENCLAW_REDACTED__.

If you only need to read the real file, read it on the gateway host at the path shown in the response. Remember that the file on disk contains your live secrets, which is exactly what config.get was protecting.

When It Is Not This At All

• parsed is null too. Your config did not load. That is a validation problem, and config validation failed: unrecognized key covers the most common one.
• The call itself failed with a permission error writing or reading the config file. See OpenClaw EACCES permission denied.
• You are in the Control UI and it says a schema node is unsupported, or tells you to use Raw mode. That is the form editor, not config.get. See unsupported schema node. use raw mode..
• The gateway will not start at all because there is no config. See gateway start blocked: missing gateway.mode.

For everything else, the OpenClaw errors explained catalogue lists each message with its cause.

Key Takeaways

• OpenClaw config.get raw null with exists: true and a populated parsed means the config is valid and only the raw text was withheld.
• The gateway redacts secrets from the raw text by find-and-replace, then proves the result still matches your config. If it does not, it sends null rather than wrong text.
• The usual cause is a secret value that also appears somewhere non-secret: a short token equal to an agent id, a numeric token equal to a limit, or a reused key.
• The same key in two secret fields is fine, and ${VAR} placeholders never collide.
• raw: null with parsed: null is different: the config failed to load, and you need to read the issues.
• The fix is optional: move secrets to environment variables or make them unique, then call config.get again.

Need help running OpenClaw in production?

Kaxo runs OpenClaw agents in production and verifies behaviour like this against the running code rather than the docs. If your agents are reading and writing their own config and you want that done safely, book a discovery call to scope it, or see how we approach AI agent development.