OpenClaw’s Config API Still Has a Secret-Leak Problem, Just in a New Place

Secret leaks in agent platforms rarely happen because nobody thought secrets mattered. They happen because one more subsystem got bolted on, one more config shape looked harmless, and one more redaction rule turned out to be a naming convention in a trench coat. OpenClaw’s newly filed browser.cdpUrl issue is a clean example. According to issue #67656, the config API can still return plaintext remote browser credentials because CDP URLs fall through every existing redaction gate.

The report is unusually solid. It does not just say “this looks bad.” It maps the miss across three separate controls. First, browser.cdpUrl and browser.profiles.*.cdpUrl are not registered as sensitive in the schema. Second, they do not match the project’s path-name suffix rules, which catch fields ending in things like token or apiKey. Third, they are not covered by the URL-path checks in isSensitiveUrlConfigPath(), even though other credential-bearing URL fields are. The result, per the issue, is that config.get may expose these values across all five snapshot surfaces: raw, parsed, sourceConfig, runtimeConfig, and resolved.

That matters because remote CDP URLs are not decorative strings. OpenClaw’s own browser docs already treat them as secrets. And they should. A URL like https://chrome.browserless.io?token=<secret> is a bearer credential. A URL like https://user:[email protected] is literally username and password in transport form. In the current agent stack, browser automation is not a fringe feature. It is core plumbing for scraping, testing, research, and any workflow that needs a real browser state. Leaking those URLs through a read-scoped config endpoint is not a minor paperwork error. It is handing out keys to a very capable piece of infrastructure.

The deeper problem is architectural consistency. OpenClaw already has multiple redaction mechanisms, which sounds reassuring until you look closer. One mechanism depends on schema registration. Another depends on naming patterns. Another depends on special-case URL path lists. That can work for a while in a smaller system. It works a lot less well once the platform is juggling model providers, browser pools, MCP servers, gateways, webhooks, and plugin-defined config. At that point, secret handling starts to behave probabilistically. If a new field happens to look like something the heuristics expect, great. If it arrives under a slightly different name, it leaks until somebody notices.

The issue’s field audit makes that painfully clear. Provider base URLs, MCP server URLs, gateway tokens and passwords, webhook tokens, and skill API keys are already covered. CDP URLs are not. That is not because remote browser credentials are harmless. It is because they landed in the gap between three partial systems. This is what happens when “secret redaction” is treated as a growing collection of exceptions instead of a single coherent classification model.

There is also a category-wide point worth making. Agent platforms are rapidly absorbing more infrastructure responsibilities than the average app framework ever had to care about. They now mediate LLM credentials, browser control, scheduled tasks, gateways, plugin marketplaces, internal tools, and external APIs. The config layer has effectively become an operations control plane. Once that happens, config hygiene stops being a developer-experience nicety and becomes a runtime security feature. Operators query config endpoints during debugging. Internal dashboards call them. UIs render them. Support tooling snapshots them. If redaction is inconsistent, the leak path multiplies fast.

For practitioners running OpenClaw, the immediate action is boring and urgent. Do not assume read-only config surfaces are safe to expose broadly. Limit who can hit them. Audit whether any internal tooling logs or persists config snapshots. If you are using Browserless or any remote CDP endpoint, rotate the credential if there is any chance the config API output was exposed to people or systems that should not have seen it. And if you are building extensions or wrappers around OpenClaw, treat URL-shaped credentials as secrets by default, not only when the field name says the quiet part out loud.

The more important engineering lesson is for platform authors. Secret classification should not depend on suffix folklore forever. If a field can authenticate to a remote system, it needs first-class sensitivity metadata that follows it through every surface, every serialization path, and every debug view. Better yet, credentials should be stored in typed secret references wherever possible, with raw values isolated from ordinary config reads entirely. That is harder than patching one path. It is also the difference between a platform that can keep growing and one that keeps rediscovering its own blind spots.

This is not OpenClaw’s first redaction issue, and that is part of the story. The report explicitly ties the bug to earlier issues around unredacted config data and remote CDP credential leakage. When the same class of problem keeps returning in slightly different wrappers, the right response is not just “add another path to the list.” The right response is to ask whether the list-based design is the bug.

That is the real editorial takeaway here. URL-shaped credentials are still credentials. Browser control endpoints are still privileged infrastructure. And once an agent platform starts acting like an operating environment, every config API becomes a security surface whether the product team likes that framing or not. OpenClaw’s latest issue does not reveal a shocking new secret-handling principle. It reveals that the old principle still has not been applied uniformly enough.

In other words, this is not really a browser bug. It is a platform maturity test. The teams that pass it are the ones that stop teaching their secret system new exceptions and start giving it one job it can do reliably.

Sources: OpenClaw issue #67656, OpenClaw issue #59793, OpenClaw issue #53433, OpenClaw browser docs