OpenClaw's v2026.4.26 Also Breaks a Documented Config Override Path — Latency Workarounds Stop Working

Here is a scenario that should feel familiar if you have spent any time debugging production infrastructure. You have a working system. You read the documentation. You follow the recommended configuration. It works. Then you upgrade, and the documented configuration stops working, and the error message is not "your config is wrong" but "your config is ignored." That is the situation described in the second v2026.4.26 issue filed within hours of the first one, and it is in some ways the more frustrating of the two because it is a regression in a documented override path.

The bug targets the agents.defaults.params and agents.defaults.models[<id>].params configuration fields. Users who set params.transport: "sse" or params.openaiWsWarmup: false to address first-message latency issues are finding those fields stripped from openclaw.json approximately 13 seconds after gateway boot. The stripping coincides with a config hot-reload cycle. The Zod schema still accepts the field — no validation error, no warning. But by the time the gateway reaches the extra-params.ts handler that is supposed to use those values, the fields are gone. The runtime falls back to transport: "auto", which prefers WebSockets first, regardless of what the operator configured.

The latency issue this touches is real. Issue #73428 was the earlier report where users were experiencing slow first-message times with certain model and channel combinations, and the maintainer-suggested workaround was exactly the transport override: params.transport: "sse" or params.openaiWsWarmup: false. Those overrides were the official guidance. Users who applied them to fix a real problem are now stuck with the behavior they were trying to fix, because a subsequent release broke the very path that made the workaround possible.

Where the bug lives

The issue report traces the likely offender to the [reload]-driven persist path that re-emits agents.defaults without preserving the user's params keys. Specifically, the writeConfigFile chain in src/config/io.ts appears to be the culprit. When the gateway's hot reload fires — which it does automatically around 13 seconds after boot — the config write-back logic reads the in-memory config, serializes it, and writes it back to disk. But the serialization step seems to be dropping keys that the schema accepts but the persist logic does not know how to handle.

This is a specific flavor of a general class of bugs that appears repeatedly in systems with dynamic configuration schemas: the validation layer and the persistence layer have different models of what is allowed, and the gap only shows up at runtime after a reload cycle. The schema says the field is fine. The persistence layer strips it silently. The operator is left debugging why their working config is no longer working, without any indication that the file was modified between boot and runtime.

The 13-second timing is a useful diagnostic clue. It is not a magic number — it is just the reload interval. If your gateway is restarting or reloading frequently in production, this bug means your documented latency overrides are effectively non-functional even when they appear correctly in the config file on disk. The file looks right. The runtime is wrong. That is the worst kind of mismatch because the most obvious debugging step — reading the config file — returns the correct answer.

The "official workaround is now broken" problem

The irony here is that the affected users followed official guidance. They had a latency problem. They were told to set specific config values. They did. It worked. Then v2026.4.26 broke the override path while presumably fixing something else, and now they are back to the original latency problem but without the workaround that made it tolerable.

This is the hidden tax of documentation that points to configuration-based workarounds for platform behavior. Workarounds are by definition fragile. They depend on internal paths that are not part of the stable API contract, and they can break silently when those internals change. The platform team was probably not thinking "we need to break the transport override path" when they shipped v2026.4.26. More likely, the config write-back logic was touched for a different reason — a different bug fix, a refactor, a new feature — and the params stripping was an unintended side effect. That is how these things usually happen. But the impact on operators who trusted the documentation is real, and it is not fixed by reverting the change that caused it, because the operators have already upgraded.

What this says about config stability

The deeper issue is that OpenClaw's configuration system appears to lack a clear stability guarantee for the fields it documents. There is a difference between "this field passes schema validation" and "this field survives a full reload cycle and reaches its intended handler." That difference is not visible to operators reading the docs, and it is not enforced by the system's own test coverage unless there is a specific regression test that writes a config, triggers a reload, and verifies the field survived.

Absent that kind of test, the platform is essentially saying: "these config fields work, until they don't, and we will only know they don't work when you file a bug report." That is not a criticism unique to OpenClaw — it is a common maturity gap in rapidly evolving platforms. But it is worth naming because it affects how much trust operators should place in documented workarounds versus, say, filing issues and waiting for first-class fixes.

What operators should do

If you are running v2026.4.26 and relying on transport overrides for latency management, the situation is uncomfortable. The documented workaround is broken. The schema accepts the fields so they look correct in your config file. But the reload cycle strips them before they take effect. The most reliable short-term fix is to wait for a patch — this is the kind of bug that should have a fast-turnaround fix given that it breaks a documented path in a stable release.

If you need an immediate workaround and cannot wait, the options are limited. Disabling the config hot-reload entirely is theoretically possible but creates other risks — you lose dynamic config updates, which matters for production systems that rely on them. Monitoring your openclaw.json for unexpected modifications after boot is a diagnostic step, not a fix. The real answer is a platform patch that stops the persist path from dropping params keys, and ideally a regression test that prevents this class of bug from shipping again.

For the broader practice of running OpenClaw in production, this is another argument for pinning your release version and testing upgrades in a staging environment before applying them to anything that matters. Not because the project is unstable, but because documented workarounds can break in stable releases when internal implementation paths shift. That is not unique to OpenClaw. It is the reality of platforms that are still actively developing their configuration and runtime internals.

Sources: GitHub issue #73607