openclaw - 💡(How to fix) Fix agents.list[].thinkingDefault not reflected in Control UI session thinking selector [1 comments, 2 participants]

Bug Description

Setting thinkingDefault: "high" in agents.list[] per-agent config does not change the Control UI session thinking selector — it still shows Default (off) for DeepSeek V4 Flash sessions, even after gateway restart and new session creation.

Environment

• OpenClaw 2026.4.25 (aa36ee6)
• Model: deepseek/deepseek-v4-flash (via api.deepseek.com)

Steps to Reproduce

1. Set thinkingDefault: "high" in openclaw.json for an agent:

{
  agents: {
    list: [
      {
        id: "investment-master",
        model: { primary: "deepseek/deepseek-v4-flash" },
        thinkingDefault: "high"
      }
    ]
  }
}

1. Restart gateway (openclaw gateway restart)
2. Create a new session
3. Check Control UI → session → thinking selector shows Default (off) instead of Default (high)

Expected Behavior

When agents.list[].thinkingDefault is set to "high", the Control UI session thinking selector should show Default (high) and new sessions should inherit that level.

Actual Behavior

• Control UI always shows Default (off) regardless of thinkingDefault value
• Sessions do not appear to inherit the configured thinkingDefault from agent config

Root Cause Investigation

Trajectory files in session data confirm that thinkingDefault: "high" IS being applied at runtime — the trajectory files show "thinkLevel":"high" when a conversation runs. However, the Control UI thinking selector always shows Default (off).

It appears that session-utils / getSessionDefaults() resolves the thinking default from the global default model rather than the per-agent model, so agent-level thinkingDefault never reaches the UI display layer.

Additional Context

• This was tested on both webchat (main) sessions and Feishu sessions
• DeepSeek V4 Flash API defaults to thinking enabled even without explicit parameters, so the actual behavior is correct — but the UI is misleading
• The thinkingDefault value is correctly displayed in trajectory logs but not surfaced in the Control UI