Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

In the OpenClaw Control UI WebChat, the thinking-level dropdown can show Default (low) even though the actual configured default and effective runtime thinking level are adaptive.

This appears to be a frontend display bug, not a backend/session-default bug.

Steps to reproduce

Configure:

{
  "agents": {
    "defaults": {
      "thinkingDefault": "adaptive"
    }
  }
}

Use a reasoning-capable model, for example: "openai-codex/gpt-5.4"

Open Control UI WebChat Leave the session without an explicit thinking override Check the thinking dropdown

Expected behavior

It should show the actual effective/configured default, e.g.: "Default (adaptive)"

Actual behavior

The dropdown shows: "Default (low)"

OpenClaw version

2026.4.10 (and later)

Operating system

Linux

Install method

No response

Model

openai-codex/gpt-5.4

Provider / routing chain

openai / oauth

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Confirmed backend/runtime state

Verified separately via runtime/config inspection:

    configured default: agents.defaults.thinkingDefault = adaptive
    current session runtime: Think: adaptive
    UI still showed: Default (low)

So the backend/session state is correct, but the Control UI label is misleading.

Impact and severity

This does not appear to affect actual backend behavior. It appears to be a Control UI labeling bug only.

Additional information

Root cause

The issue appears to be in the Control UI frontend logic for the thinking dropdown.

The thinking dropdown label in ET(e) was built from: ia({ provider, model, catalog })

In the built frontend bundle, the dropdown label is computed in ET(e) using model-based fallback logic: defaultLabel: Default (${r && i ? ia({ provider: r, model: i, catalog: e.chatModelCatalog ?? [] }) : 'off'})

That means the UI derives the label from the model/provider heuristic via ia(...), which can return low for reasoning-capable models, instead of using the actual configured/effective default thinking level.

So the dropdown is effectively showing: model-derived fallback, instead of actual configured/effective default

Local proof / workaround

A local UI-only patch fixed the display by making the dropdown prefer the effective/current thinking state instead of the model heuristic.

function ET(e) {
  let t = e.sessionsResult?.sessions?.find(t => t.key === e.sessionKey)?.thinkingLevel,
      n = typeof t === 'string' && t.trim() ? ta(t) ?? t.trim() : '',
      { provider: r, model: i } = wT(e),
      a =
        typeof e.chatThinkingLevel === 'string' && e.chatThinkingLevel.trim()
          ? ta(e.chatThinkingLevel) ?? e.chatThinkingLevel.trim()
          : r && i
            ? ia({ provider: r, model: i, catalog: e.chatModelCatalog ?? [] })
            : 'off';

  return {
    currentOverride: n,
    defaultLabel: `Default (${a})`,
    options: TT(r, i, n),
  };
}

After this local patch, the dropdown correctly displayed: "Default (adaptive)"

Suggested fix

The dropdown should use a resolved/default thinking value coming from actual session/config state, not infer the label from model capability heuristics.

Best source would be one of:

• resolved default thinking from server/session state
• explicit surfaced thinkingDefault
• effective current thinking default already known by the chat/session state

Notes

• UI-only fix
• no backend behavior change
• no sessions.patch behavior change