sessions CLI shows stale model vs session_status

[rotund flint]

sessions CLI shows a stale model name for the main agent, which doesn't match the live model reported by the gateway.

Environment

OpenClaw: 2026.2.3-1
OS: macOS
Agent: main (session key agent:main:main)
Current behavior

agents.defaults.model.primary is set to openai/gpt-5.2-codex in ~/.openclaw/openclaw.json.
/status (or session_status for agent:main:main) reports:
Model: openai/gpt-5.2-codex
openclaw sessions prints a Sessions table where the same session appears as:
Model gpt-5.1
The backing session store at ~/.openclaw/agents/main/sessions/sessions.json has:
"agent:main:main" : { ..., "model": "gpt-5.1", ... }
So the CLI's Sessions view appears to be reading a cached model field from the session store that is no longer in sync with the actual model the gateway is using.

Expected behavior

When the default model for an agent is changed (e.g. via openclaw configure --section model or config patch), either:

The session store is updated to reflect the new effective model, or
The openclaw sessions CLI derives the model column from the live gateway state instead of from a stale cached snapshot.
In either case, for an active session like agent:main:main, the model shown in the Sessions table should match the model reported by /status / session_status.

[grand blaze]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[crisp mason]

Yep — this is a real mismatch, and it comes from a legacy field in sessions.json.

What’s happening

• The gateway (/status, session_status) uses modelOverride (and/or config defaults) to decide the effective model.
• Your sessions.json still contains an old persisted model field (e.g. "model": "gpt-5.1") from an earlier version.
• openclaw sessions currently prints entry.model from the store if it exists, so it shows the stale gpt-5.1 even though the gateway is actually running openai/gpt-5.2-codex.

So the CLI is effectively displaying a stale, unused field.

Workaround (safe + quick)

Remove the legacy model field from the session store entry (or from all entries). It won’t come back because current gateway code doesn’t write model anymore.

1. Stop the gateway (so it won’t rewrite the store while you edit):

openclaw gateway stop

2. Backup + strip the legacy field:

cd ~/.openclaw/agents/main/sessions
cp sessions.json sessions.json.bak

jq 'with_entries(.value |= del(.model))' sessions.json > sessions.json.new && mv sessions.json.new sessions.json

3. Restart:

openclaw gateway start
openclaw sessions

After that, openclaw sessions should fall back to the configured default model (since row.model is gone/null).

“Real” fix (upstream)

This looks like a CLI bug/regression: openclaw sessions should prefer modelOverride (or derive the effective model) and ignore the legacy model field.

If you file a GitHub issue, include exactly what you wrote + this key detail:

• session store uses modelOverride, but openclaw sessions displays entry.model (legacy)

Issues: https://github.com/openclaw/openclaw/issues

[rotund flint]

I have filed an issue already https://github.com/openclaw/openclaw/issues/10715

[crisp mason]

Nice — that issue is exactly the right report.

Extra detail that might help the fix/triage: openclaw sessions is currently a pure file reader of ~/.openclaw/agents/<agentId>/sessions/sessions.json, and it prints the legacy entry.model field if present (falling back to config only when it’s missing). The gateway/session runtime has moved on to modelOverride (+ config defaults), and doesn’t keep entry.model in sync anymore — so old stores can “pin” a stale model in the CLI output forever.

Until it’s fixed upstream, the clean workaround is to remove that legacy field (or delete just that session entry), then restart the gateway:

openclaw gateway stop
cp ~/.openclaw/agents/main/sessions/sessions.json{,.bak}
jq 'with_entries(.value |= del(.model))' ~/.openclaw/agents/main/sessions/sessions.json > /tmp/sessions.json \
&& mv /tmp/sessions.json ~/.openclaw/agents/main/sessions/sessions.json
openclaw gateway start

(Deleting an entry is also safe — the gateway recreates it on demand.)

If you want a “live gateway view” in the meantime (instead of the local file view), openclaw gateway call sessions.list --params '{}' is the closer source of truth.

[rotund flint]

22:24:31 [gateway] agent model: openai/gpt-5.2
22:24:31 [gateway] listening on ws://127.0.0.1:18789 (PID 3065)
22:24:31 [gateway] listening on ws://[::1]:18789
22:24:31 [gateway] log file: /tmp/openclaw/openclaw-2026-02-07.log
22:24:31 [browser/service] Browser control service ready (profiles=2)
22:24:32 [telegram] [default] starting provider (@******)
22:24:32 [telegram] autoSelectFamily=false (default-node22)
22:24:33 [diagnostic] lane task error: lane=main durationMs=2 error="FailoverError: No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.2 (ChatGPT OAuth) or set OPENAI_API_KEY for openai/gpt-5.2."
22:24:33 [diagnostic] lane task error: lane=session:agent:main:main durationMs=24 error="FailoverError: No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.2 (ChatGPT OAuth) or set OPENAI_API_KEY for openai/gpt-5.2."
22:24:33 [diagnostic] lane task error: lane=main durationMs=229 error="FailoverError: No API key found for amazon-bedrock.

[crisp mason]

Those log lines are the gateway telling you: you’re configured to use the openai/… provider, but you only have openai-codex OAuth credentials.

So it starts up, resolves “agent model: openai/gpt-5.2”, then immediately fails with:

No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.2 … or set OPENAI_API_KEY …

Fix (pick one path)

A) Use your Codex OAuth (no API key):
Set your default model to the Codex provider:

agents: {
defaults: {
model: { primary: "openai-codex/gpt-5.2" } // or openai-codex/gpt-5.2-codex for coding
}
}

Docs: https://docs.openclaw.ai/providers/openai (see “Option B: OpenAI Code (Codex) subscription”)
FAQ also calls out the openai-codex/gpt-5.2 ↔ openai-codex/gpt-5.2-codex switch: https://docs.openclaw.ai/help/faq

B) Keep openai/gpt-5.2 (OpenAI Platform API):
You need an actual OPENAI_API_KEY available to the gateway process (wizard: openclaw onboard --auth-choice openai-api-key, or set env/config accordingly).

About the amazon-bedrock error

That usually means you have Bedrock in your configured failover list (agents.defaults.model.fallbacks), so after OpenAI fails auth, it tries Bedrock and then fails too. If you don’t use Bedrock, remove it from fallbacks (or configure Bedrock creds).

If you paste your agents.defaults.model block (redact keys), I can point to the exact line that’s causing the Bedrock failover.

[rotund flint]

the logs show all other model/providers failing, this is after removing the mode from the sessions.json as you said.

[crisp mason]

Yeah — that failure spam isn’t caused by editing sessions.json.

Removing the legacy model field from ~/.openclaw/agents/main/sessions/sessions.json only affects what openclaw sessions prints. It doesn’t control which provider/model the gateway uses, and it doesn’t affect auth resolution.

What changed is: you restarted the gateway, and now it’s trying to run with:

• Resolved agent model: openai/gpt-5.2 (per your log line)
• But your credentials are Codex OAuth, i.e. for openai-codex/..., not openai/...

So the gateway correctly errors:

No API key found for provider "openai" … Use openai-codex/gpt-5.2 … or set OPENAI_API_KEY

And the amazon-bedrock error is just your fallback list getting tried afterward.

What to do next

1. Run and paste the output of: