OpenClaw's Silent-Default Bug Is a Reminder That Opt-Out Security Is Still a Security Problem
If you upgraded to OpenClaw v2026.4.26 sometime in the last 48 hours and suddenly cannot send a single message, you are not alone — and it is not your fault. A fresh bug report filed against the release describes a silent breaking change that is exactly the kind of thing that erodes operator trust faster than any feature gap. The release ships a bundled coding-agent skill and a codex provider that inserts openai/gpt-5.5 into the model's fallback chain — even on stacks that have never configured OpenAI authentication at all. The result is that every chat lane fails with a generic "No API key found for provider openai" before producing a reply, with no upgrade-time warning and no migration guide. The user who filed the report had a fully working primary-plus-fallback chain routing exclusively to DeepSeek and Ollama. None of those providers are OpenAI. It did not matter. The codex provider was synthesized into the candidate list anyway, and the first candidate that required OpenAI auth crashed the entire routing decision.
The workaround, as described in the issue, is not for the faint of heart. You need to strip the codex provider from models.json, remove OpenAI entries from the HuggingFace catalog, and explicitly disable the coding-agent skill in both the main and state-dir openclaw.json files. That is a lot of archaeology for an upgrade that was supposed to be routine. The bug is marked 100% reproducible on any v2026.4.26 install that does not have an OpenAI key configured.
The opt-out security problem
There is a version of this story that sounds reasonable from the inside of a release planning meeting. "We shipped a coding-agent skill and a codex provider. They're optional. If you don't want them, disable them." That framing treats the breaking change as an operator misconfiguration. The bug report shows that framing is wrong.
When a platform inserts a new provider into the fallback chain by default — a chain that was deliberately constructed to route around OpenAI — it is not offering an option. It is making an architectural decision on behalf of operators who did not consent to it. The difference matters because those operators built their routing topology for specific reasons: cost, latency, data residency, or just institutional preference for providers that do not require U.S.-based API keys. A silent insertion into that chain does not just add a feature. It potentially violates the constraints that justified the chain in the first place.
There is a broader pattern here worth naming. The AI tooling industry has developed a habit of framing everything as opt-out rather than opt-in when it comes to new capabilities. "We've added this model to the default routing" is presented as generosity. For operators running compliance-sensitive or cost-sensitive stacks, it is actually an unexpected perturbation that requires remediation. The bug report here is a specific instance of a general disease: platforms that grow by inserting themselves into places operators did not ask them to be.
What "bundled" actually means in practice
The coding-agent skill and codex provider are not external plugins. They ship with the release. That is a meaningful distinction because bundled components are harder to ignore than optional ones — they do not appear in a marketplace you can choose not to visit, and they do not announce themselves with clear feature flags that invite review. They just appear in the runtime's internal catalog because the release team decided they belong there.
The routing logic does not appear to check whether OpenAI credentials exist before inserting openai/gpt-5.5 into the fallback chain. That is the proximate bug. But the underlying issue is architectural: the system treats "this candidate exists in the catalog" as equivalent to "this candidate is a valid routing target," when those are actually different things. A catalog entry without credentials is not a candidate. It is a trapdoor.
The fact that this ships in a stable release is the real signal. Hotfix releases are where you find the bugs that escaped beta. This bug did not escape beta. It shipped as intended behavior and then got reported as a bug by someone whose system broke. That means either the release process did not catch a failure mode that is reproducible 100% of the time, or it caught it and decided the insertion was acceptable. Neither answer is comforting.
The workaround is the real story
The remediation steps in the bug report are instructive. Strip codex from models.json. Remove OpenAI entries from the HuggingFace catalog. Disable coding-agent in two separate openclaw.json files — one in the main config directory and one in the state directory. The state-dir config is particularly notable because it is not where most operators look first when something breaks. That is where runtime-derived configuration lives, and it is the kind of file that gets generated automatically and rarely touched by hand.
What the workaround is actually doing is surgically removing the inserted component from every place it landed. That is the correct characterization: not "configuration," not "tuning," but removal. The operator is undoing what the release did. That asymmetry is worth sitting with. If a feature genuinely respects operator boundaries, it should be removable without archaeology. The fact that this one requires tracing through multiple config layers and two separate JSON files suggests the insertion was not designed with removal in mind.
What operators should do
If you are running v2026.4.26 and your chat lanes are failing with OpenAI auth errors, the workaround is available but it should not be your long-term answer. The right response is to wait for an explicit acknowledgment from the project that this is unintended behavior — because a bug that ships in a stable release and is 100% reproducible should have a platform-level fix, not a per-operator workaround.
If you are evaluating OpenClaw for a stack that cannot have OpenAI credentials — cost-sensitive environments, non-U.S. deployments, air-gapped setups — this bug is worth adding to your pre-upgrade checklist. The question to ask before any upgrade is not "what did they add?" It is "what did they insert into places I did not explicitly configure?" That is a harder question to answer, but it is the one that tells you whether a release is actually safe to apply to a production-adjacent system.
The broader takeaway is not specific to OpenClaw. Any agent platform that ships bundled providers, skills, or catalog entries and inserts them into routing chains by default is making a decision on behalf of operators who may not share the platform's assumptions about what belongs in the chain. "Opt-out security" works fine when the thing you're opting out of is genuinely optional. It works poorly when the thing is quietly changing the shape of your routing topology without asking.
Sources: GitHub issue #73358