openclaw - 💡(How to fix) Fix agents.defaults.params and agents.defaults.models[].params stripped from openclaw.json by gateway runtime (v2026.4.26) [2 comments, 3 participants]

Bug type

Configuration not honored / runtime drops user-provided config field

Beta release blocker

No

Summary

agents.defaults.params and agents.defaults.models["<provider>/<model>"].params are documented overrides (docs/concepts/model-providers.md:88, docs/concepts/model-providers.md:90) — accepted by the zod schema (src/config/zod-schema.agent-defaults.ts:43-71) — but the gateway runtime rewrites openclaw.json ~13s after start and strips both fields. As a result, settings like params.transport: "sse" and params.openaiWsWarmup: false never reach extra-params.ts and the runtime falls back to transport: "auto" (WS-first).

Steps to reproduce

1. Run ghcr.io/openclaw/openclaw:2026.4.26 with default openai/gpt-5.4 primary.
2. Edit openclaw.json (or write it via your config generator) to include either:

   {
     "agents": {
       "defaults": {
         "params": { "transport": "sse", "openaiWsWarmup": false }
       }
     }
   }

   or the per-model form documented in model-providers.md:90:

   {
     "agents": {
       "defaults": {
         "models": {
           "openai/gpt-5.4": { "params": { "transport": "sse", "openaiWsWarmup": false } }
         }
       }
     }
   }

3. Start the gateway.
4. After ~15s, read openclaw.json from disk. The params / models[<id>].params field is gone.

Expected behavior

The persisted openclaw.json keeps the user-provided agents.defaults.params (and agents.defaults.models[<id>].params) intact across boot and config hot-reload. extra-params.ts then reads transport and openaiWsWarmup from those fields.

Actual behavior

Field is stripped from disk ~13s after container start (which roughly coincides with [reload] config change detected; evaluating reload (agents.list, bindings) in our logs). The runtime falls back to transport: "auto" and creating streamFn wrapper with params: {"transport":"auto","openaiWsWarmup":false} is logged regardless of what the original file contained.

What we verified

• generate-config.mjs (and a hand-edited openclaw.json) emit the field correctly when written
• cat /Users/randytran/.../openclaw.json shortly after writing shows the field present; mtime advances ~13s into gateway boot; subsequent cat shows it gone
• AgentDefaultsSchema (src/config/zod-schema.agent-defaults.ts:43-71) accepts both shapes (params: z.record(z.string(), z.unknown()) at .params and per-model models[id].params)
• applyModelAliasDefaults (src/config/defaults.ts:255-281) spreads existing entries — does not appear to drop params
• materializeRuntimeConfig (src/config/materialize.ts:53) is in-memory only

So the offender is somewhere in the [reload]-driven persist path that re-emits agents.defaults without the user's params keys.

Workarounds tried

• Setting at agents.defaults.params (global) — stripped
• Setting at agents.defaults.models["openai/gpt-5.4"].params — stripped
• Searched process.env.OPENCLAW_* for transport / warmup overrides — none exist in the src/agents/ tree

Impact

Documented override path in docs/concepts/model-providers.md is non-functional in v2026.4.26. Operators on slow first-message latency (#73428) cannot apply the maintainer-suggested transport: "sse" / openaiWsWarmup: false workaround.

OpenClaw version

2026.4.26

Operating system

Ubuntu 24.04 (in container) on macOS Docker Desktop host. Reproduced from ghcr.io/openclaw/openclaw:2026.4.26.

Install method

docker (ghcr.io/openclaw/openclaw image)

Model

openai/gpt-5.4

Provider / routing chain

openclaw → openai (direct)

Additional notes

Likely a regression in the agent-list reconcile / config write-back path (writeConfigFile chain at src/config/io.ts:1029, 1969, 2413). Happy to bisect against an older release if it would help, or to attach a debug-logging diff that prints the in-memory agents.defaults keys before/after each persist hop.

Related: #73428 (latency report — uses this missing override path), #73477 (cold-load tool resolution bottleneck — separate symptom, same era).