Summary

openclaw models set <alias> does not resolve the alias to its underlying model id. Instead, it registers a new literal model entry using <inferred-provider>/<alias> as the id and writes that bogus id as the primary model.

This can leave the gateway in an unbootable state when the bogus id is not a real model in any provider catalog.

Reproduction

Given a config with an alias already defined:

"agents": {
  "defaults": {
    "models": {
      "anthropic/claude-sonnet-4-6": { "alias": "sonnet" }
    }
  }
}

Run:

openclaw models set sonnet

Expected

The alias sonnet resolves to anthropic/claude-sonnet-4-6, and agents.defaults.model.primary is set to that id.

Actual

• A new entry openai/sonnet is added to agents.defaults.models.
• agents.defaults.model.primary is set to openai/sonnet.
• On next gateway start: Unknown model: openai/sonnet → agent fails before reply with Logs: openclaw logs --follow.
• Confirmed on openclaw@2026.4.15 (041266a).

Impact

• High. Gateway becomes unusable until config is manually edited.
• Silent: no warning that the alias was not recognized.

Suggested fix

Before treating the argument as a raw model id, look it up in the current alias table (agents.defaults.models.*.alias). If a match is found, resolve to the fully qualified id and write that to agents.defaults.model.primary without adding a new entry.

If the argument does not match any alias and is not already in agents.defaults.models, at minimum error out (or require --force) instead of silently creating a new model entry.

Environment

• OpenClaw: 2026.4.15 (041266a)
• OS: Ubuntu on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2 x64)
• Node: v22.22.2