Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature] Clear session model override on /new and /reset [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#64475•Fetched 2026-04-11 06:14:45
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
zhuyankarlzhuyankarl
Participants
ClawKingAIClawKingAIzhuyankarlzhuyankarl
Timeline (top)
referenced ×2commented ×1cross-referenced ×1

Root Cause

  • Users change agents.defaults.model.primary in config and expect it to take effect
  • After /new, users expect a truly fresh session, not one with hidden stale state
  • The current behavior silently undermines config changes, causing confusion and debugging time

Fix Action

Fix / Workaround

Current Workaround

PR fix notes

PR #64518: fix: clear model/provider override on /new and /reset

Description (problem / solution / changelog)

Summary

  • Clears modelOverride and providerOverride when /new or /reset is triggered
  • Ensures reset sessions start fresh with the configured default model
  • Preserves other per-session settings (thinking, verbose, reasoning, ttsAuto) as intended

Problem

After /new or /reset, the session incorrectly inherited the previous modelOverride/providerOverride via the spread operator, causing the new session to remain pinned to the old model instead of falling back to agents.defaults.model.primary.

Test plan

  • Existing session tests pass (pnpm test src/auto-reply/reply/session.test.ts)
  • Manual testing: set /model gpt, run /new, verify session uses default model

Fixes #64475

🤖 Generated with Claude Code

Changed files

  • src/auto-reply/reply/session.test.ts (modified, +39/-0)
  • src/auto-reply/reply/session.ts (modified, +18/-4)

PR #64904: fix(sessions): clear model override on /new and /reset

Description (problem / solution / changelog)

Summary

  • Problem: When /new or /reset is triggered without specifying a model, the previous session's model override was incorrectly retained
  • What changed: When resetTriggered=true and no body is provided, clear modelOverride and providerOverride by treating it as a reset to defaults
  • What did NOT change: Other behavior of /new and /reset remains unchanged

Changes

src/auto-reply/reply/session-reset-model.ts

When /new or /reset is called without a model argument, the function now clears any existing model override by applying isDefault: true instead of silently returning without action.

src/auto-reply/reply/session-reset-model.test.ts (added)

Added test case: "clears model override when resetTriggered is true but body is empty"

Testing

TestStatus
session-reset-model.test.ts (4 tests)✓ Passed

Linked Issue

Closes #64475

With AI assist: MiniMax-M2.7

Changed files

  • extensions/browser/src/browser/chrome-wsl-display.test.ts (added, +47/-0)
  • extensions/browser/src/browser/chrome.ts (modified, +3/-0)
  • src/auto-reply/reply/session-reset-model.test.ts (modified, +24/-0)
  • src/auto-reply/reply/session-reset-model.ts (modified, +10/-0)
  • ui/src/ui/views/config-form.node.ts (modified, +3/-3)

Code Example

// Current (buggy):
if (resetTriggered && entry) {
  persistedModelOverride = entry.modelOverride;        // ← bug
  persistedProviderOverride = entry.providerOverride;  // ← bug
}

// Proposed fix:
if (resetTriggered && entry) {
  // Do NOT persist model/provider override on reset
  // This ensures the new session starts with the configured default
}

---

{
  "session": {
    "clearModelOverrideOnReset": true
  }
}
RAW_BUFFERClick to expand / collapse

Problem

When a user sets a per-session model override (via /model or session_status(model=...)), the override persists in the session store across:

  • /new and /reset commands
  • Gateway restarts

This causes the new session to start with the stale override instead of the configured agents.defaults.model.primary or agent-level model.primary.

Related Issues

  • #55063 — /new and /reset preserve session model override
  • #51251 — Session modelOverride persists across gateway restarts
  • #27058 — /new does not clear session-level model override
  • #22443 — Session-level model overrides should be visible and clearable

Current Workaround

Users must manually call session_status(model="default") after each /new or gateway restart to clear the stale override. This is not intuitive and most users dont know about it.

Proposed Solution

Option A: Auto-clear on /new (Recommended)

In the session reset path, do NOT persist modelOverride and providerOverride when resetTriggered is true:

// Current (buggy):
if (resetTriggered && entry) {
  persistedModelOverride = entry.modelOverride;        // ← bug
  persistedProviderOverride = entry.providerOverride;  // ← bug
}

// Proposed fix:
if (resetTriggered && entry) {
  // Do NOT persist model/provider override on reset
  // This ensures the new session starts with the configured default
}

Option B: Config-level option

Add a config option to control this behavior:

{
  "session": {
    "clearModelOverrideOnReset": true
  }
}

Option C: Distinguish intentional vs stale overrides

Track whether the override was set intentionally (via /model) vs inherited from a previous session. Only clear inherited ones on /new.

Why This Matters

  • Users change agents.defaults.model.primary in config and expect it to take effect
  • After /new, users expect a truly fresh session, not one with hidden stale state
  • The current behavior silently undermines config changes, causing confusion and debugging time

Suggested Behavior

After /new or /reset:

  1. Session starts with NO model override
  2. Model resolves to the agent's configured model.primary
  3. If no agent-level primary, falls back to agents.defaults.model.primary
  4. The reset banner shows the correct resolved model

This would make /new a true "fresh start" as users expect.

extent analysis

TL;DR

To fix the issue, update the session reset path to not persist modelOverride and providerOverride when resetTriggered is true, ensuring new sessions start with the configured default model.

Guidance

  • Review the proposed solution in Option A and consider implementing the change to prevent persisting modelOverride and providerOverride on reset.
  • Evaluate the feasibility of adding a config option as described in Option B to control the behavior of clearing model overrides on reset.
  • Consider tracking whether the override was set intentionally or inherited from a previous session, as suggested in Option C, to only clear inherited ones on /new.
  • Verify the fix by testing the behavior after /new or /reset commands and checking that the session starts with the expected model override.

Example

// Proposed fix:
if (resetTriggered && entry) {
  // Do NOT persist model/provider override on reset
  persistedModelOverride = null;
  persistedProviderOverride = null;
}

Notes

The best approach may depend on the specific requirements and constraints of the system, so it's essential to evaluate each option carefully.

Recommendation

Apply the workaround by implementing the proposed fix in Option A, as it directly addresses the issue and ensures new sessions start with the configured default model. This approach is straightforward and effective in resolving the problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#orchestration issue#cache issue#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING