openclaw - 💡(How to fix) Fix Claude CLI-backed sessions show mixed modelProvider metadata; sessions.patch model:null succeeds but does not normalize stale runtime fields [1 participants]

Bug type

Behavior bug / session metadata inconsistency

Summary

After configuring agents to use the Claude CLI runtime with a canonical Anthropic model ref, active sessions can report mixed modelProvider values for the same effective setup.

Config uses the documented split:

• model: anthropic/claude-opus-4-7
• runtime: claude-cli
• fallback: none

Some active sessions report:

{
  "modelProvider": "claude-cli",
  "model": "claude-opus-4-7"
}

Other active sessions for Claude CLI-backed agents still report:

{
  "modelProvider": "anthropic",
  "model": "claude-opus-4-7"
}

Calling sessions.patch with model: null returns ok: true, but the stale rows remain or are immediately re-resolved back to modelProvider: "anthropic".

This makes it difficult to verify whether a session is actually using the configured CLI runtime or whether the session metadata is stale/misleading.

Environment

• OpenClaw: 2026.4.25 (aa36ee6)
• Install method: npm global
• OS: macOS 26.4.1
• Gateway service: local gateway

Sanitized config shape

{
  "agents": {
    "defaults": {
      "agentRuntime": {
        "id": "claude-cli",
        "fallback": "none"
      },
      "model": {
        "primary": "anthropic/claude-opus-4-7",
        "fallbacks": []
      },
      "thinkingDefault": "high"
    },
    "list": [
      {
        "id": "<claude-cli-agent-1>",
        "agentRuntime": {
          "id": "claude-cli",
          "fallback": "none"
        },
        "model": "anthropic/claude-opus-4-7",
        "thinkingDefault": "high"
      },
      {
        "id": "<claude-cli-agent-2>",
        "agentRuntime": {
          "id": "claude-cli",
          "fallback": "none"
        },
        "model": "anthropic/claude-opus-4-7",
        "thinkingDefault": "high"
      }
    ]
  }
}

Steps to reproduce

1. Configure one or more agents to use:
   • agentRuntime.id: "claude-cli"
   • agentRuntime.fallback: "none"
   • model: "anthropic/claude-opus-4-7"
2. Have existing active sessions from before or during the runtime/config migration.
3. Run:

openclaw sessions --all-agents --active 360 --json

1. Observe mixed runtime metadata across active sessions:
   • some rows show modelProvider: "claude-cli"
   • other rows show modelProvider: "anthropic"
2. Try clearing the session model override through the gateway:

openclaw gateway call sessions.patch \
  --params '{"key":"<session-key>","model":null}' \
  --json

1. The call returns ok: true, but the affected session entry still reports:

{
  "modelProvider": "anthropic",
  "model": "claude-opus-4-7"
}

Expected behavior

For sessions whose effective agent runtime is claude-cli, session metadata should either:

• consistently show modelProvider: "claude-cli" for the runtime provider, or
• clearly separate canonical model provider (anthropic) from runtime backend (claude-cli), so status/session checks are not ambiguous.

If sessions.patch with model: null is the intended way to clear stale per-session model state, it should either normalize/clear stale runtime fields or return a response indicating no runtime metadata was changed.

Actual behavior

sessions.patch returns success, but stale-looking session rows continue to report modelProvider: "anthropic" even though the agent config uses claude-cli runtime with fallback disabled.

Impact

This creates ambiguous verification for Claude CLI-backed deployments. Health checks and config validation can pass, while active session metadata still suggests some sessions are using the canonical Anthropic provider rather than the configured Claude CLI runtime.

Workaround

Start a fresh session or delete/reset affected session state, accepting loss of short-term session context. I did not force-delete session entries because the gateway method returned success but did not normalize the metadata.

Notes

This may be related to session runtime fields being persisted separately from model override fields, or to canonical model provider resolution overwriting/obscuring the runtime backend.