Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: /new and /reset preserve session model override; reset banner default can differ from agents.defaults.model.primary [2 pull requests, 1 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#55063•Fetched 2026-04-08 01:33:00
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
gshlomigshlomi
Participants
gshlomigshlomi
Timeline (top)
cross-referenced ×3

PR fix notes

PR #1: fix(auth): stop new sessions inheriting auto-selected auth profile overrides

Description (problem / solution / changelog)

Summary

  • Problem: New sessions inherit authProfileOverride from rate-limited or cooldown backup profiles instead of using the default/best available profile. The auto-failover override persists across gateway restarts, /new, /reset, and manual session clearing.
  • Why it matters: Users get stuck on a degraded auth profile with no way to recover short of deleting session state, and the lastGood/cooldownUntil fields are effectively ignored.
  • What changed: Auto-selected (source === "auto") auth profile overrides are now discarded at session boundaries (gateway reset, /new, /reset). Only user-explicitly-set overrides (source === "user") carry over. Defense-in-depth in resolveSessionAuthProfileOverride ensures new sessions always call pickFirstAvailable() for auto overrides.
  • What did NOT change (scope boundary): User-set auth profile overrides (/auth command) still carry over across session resets as before. The round-robin and cooldown logic is unchanged for continuing (non-new) sessions.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #62412
  • Related #51251, #55063, #57760, #56393
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: Three code paths unconditionally carry over authProfileOverride from old to new sessions regardless of whether the override was auto-selected (failover) or user-set. The authProfileOverrideSource discriminator existed in the data model but was not consulted at session boundaries.
  • Missing detection / guardrail: No distinction between "auto" and "user" source when propagating auth profile overrides across session resets.
  • Contributing context (if known): The auto-failover system correctly sets authProfileOverrideSource: "auto" but the session reset and init paths treated all overrides identically.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/agents/auth-profiles/session-override.test.ts
  • Scenario the test should lock in: New session with authProfileOverrideSource: "auto" picks first available profile (not round-robin from stale position); new session with authProfileOverrideSource: "user" round-robins as before; cooldown profiles are skipped.
  • Why this is the smallest reliable guardrail: The resolver function is the last line of defense — testing it covers the defense-in-depth layer regardless of upstream session propagation behavior.
  • Existing test that already covers this (if any): None — only provider-alias and early-return tests existed.
  • If no new test is added, why not: 5 new tests added.

User-visible / Behavior Changes

  • New sessions (via /new, /reset, gateway restart, or session expiry) now start with the best available auth profile instead of inheriting a stale auto-failover profile that may be in cooldown or rate-limited.
  • User-explicitly-set auth profile overrides (via /auth or similar) still persist across session resets.

Diagram (if applicable)

Before:
[rate limit] -> [auto-failover to backup1] -> [/new] -> [backup1 still active, even if in cooldown]

After:
[rate limit] -> [auto-failover to backup1] -> [/new] -> [pickFirstAvailable() -> default profile]

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Environment

  • OS: Linux 6.17.0-1010-azure (x64) per issue report
  • Runtime/container: Node v22.22.1
  • Model/provider: anthropic/claude-opus-4-6
  • Integration/channel (if any): Telegram DM
  • Relevant config (redacted): 3 Anthropic auth profiles (default + 2 backups)

Steps

  1. Configure multiple auth profiles for the same provider
  2. Use system until one profile hits a transient rate limit, triggering auto-failover
  3. Start a new session (/new, /reset, or new message after expiry)

Expected

  • New session uses the best available non-cooldown profile (typically the default)

Actual

  • New session inherits the rate-limited backup profile from the previous session

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

5 new unit tests in src/agents/auth-profiles/session-override.test.ts all pass, covering auto vs user override propagation, cooldown skipping, legacy inference, and all-cooldown fallback.

Human Verification (required)

  • Verified scenarios: All 5 new tests pass; all 7 tests in session-override.test.ts pass; full auth-profiles test suite (109/110 pass, 1 pre-existing unrelated failure in state-observation.test.ts)
  • Edge cases checked: Legacy session entries without authProfileOverrideSource, all-profiles-in-cooldown fallback, provider alias normalization
  • What you did not verify: End-to-end gateway restart with real multi-profile setup; the gateway session-reset-service path is tested indirectly via the defense-in-depth layer

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Risks and Mitigations

  • Risk: Existing sessions with authProfileOverrideSource: "auto" will lose their override on the next session reset, changing profile selection behavior.
    • Mitigation: This is the intended fix. Auto overrides were never meant to be permanent; they should be re-evaluated per session.

🤖 Generated with Claude Code

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/auth-profiles/session-override.test.ts (modified, +205/-1)
  • src/agents/auth-profiles/session-override.ts (modified, +4/-1)
  • src/auto-reply/reply/session.ts (modified, +5/-3)
  • src/gateway/session-reset-service.ts (modified, +12/-3)

PR #62710: fix(auth): stop new sessions inheriting auto-selected auth profile overrides

Description (problem / solution / changelog)

Summary

  • Problem: New sessions inherit authProfileOverride from rate-limited or cooldown backup profiles instead of using the default/best available profile. The auto-failover override persists across gateway restarts, /new, /reset, and manual session clearing.
  • Why it matters: Users get stuck on a degraded auth profile with no way to recover short of deleting session state, and the lastGood/cooldownUntil fields are effectively ignored.
  • What changed: Auto-selected (source === "auto") auth profile overrides are now discarded at session boundaries (gateway reset, /new, /reset). Only user-explicitly-set overrides (source === "user") carry over. Defense-in-depth in resolveSessionAuthProfileOverride ensures new sessions always call pickFirstAvailable() for auto overrides.
  • What did NOT change (scope boundary): User-set auth profile overrides (/auth command) still carry over across session resets as before. The round-robin and cooldown logic is unchanged for continuing (non-new) sessions.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #62412
  • Related #51251, #55063, #57760, #56393
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: Three code paths unconditionally carry over authProfileOverride from old to new sessions regardless of whether the override was auto-selected (failover) or user-set. The authProfileOverrideSource discriminator existed in the data model but was not consulted at session boundaries.
  • Missing detection / guardrail: No distinction between "auto" and "user" source when propagating auth profile overrides across session resets.
  • Contributing context (if known): The auto-failover system correctly sets authProfileOverrideSource: "auto" but the session reset and init paths treated all overrides identically.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/agents/auth-profiles/session-override.test.ts
  • Scenario the test should lock in: New session with authProfileOverrideSource: "auto" picks first available profile (not round-robin from stale position); new session with authProfileOverrideSource: "user" round-robins as before; cooldown profiles are skipped.
  • Why this is the smallest reliable guardrail: The resolver function is the last line of defense — testing it covers the defense-in-depth layer regardless of upstream session propagation behavior.
  • Existing test that already covers this (if any): None — only provider-alias and early-return tests existed.
  • If no new test is added, why not: 5 new tests added.

User-visible / Behavior Changes

  • New sessions (via /new, /reset, gateway restart, or session expiry) now start with the best available auth profile instead of inheriting a stale auto-failover profile that may be in cooldown or rate-limited.
  • User-explicitly-set auth profile overrides (via /auth or similar) still persist across session resets.

Diagram (if applicable)

Before:
[rate limit] -> [auto-failover to backup1] -> [/new] -> [backup1 still active, even if in cooldown]

After:
[rate limit] -> [auto-failover to backup1] -> [/new] -> [pickFirstAvailable() -> default profile]

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Environment

  • OS: Linux 6.17.0-1010-azure (x64) per issue report
  • Runtime/container: Node v22.22.1
  • Model/provider: anthropic/claude-opus-4-6
  • Integration/channel (if any): Telegram DM
  • Relevant config (redacted): 3 Anthropic auth profiles (default + 2 backups)

Steps

  1. Configure multiple auth profiles for the same provider
  2. Use system until one profile hits a transient rate limit, triggering auto-failover
  3. Start a new session (/new, /reset, or new message after expiry)

Expected

  • New session uses the best available non-cooldown profile (typically the default)

Actual

  • New session inherits the rate-limited backup profile from the previous session

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

5 new unit tests in src/agents/auth-profiles/session-override.test.ts all pass, covering auto vs user override propagation, cooldown skipping, legacy inference, and all-cooldown fallback.

Human Verification (required)

  • Verified scenarios: All 5 new tests pass; all 7 tests in session-override.test.ts pass; full auth-profiles test suite (109/110 pass, 1 pre-existing unrelated failure in state-observation.test.ts)
  • Edge cases checked: Legacy session entries without authProfileOverrideSource, all-profiles-in-cooldown fallback, provider alias normalization
  • What you did not verify: End-to-end gateway restart with real multi-profile setup; the gateway session-reset-service path is tested indirectly via the defense-in-depth layer

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Risks and Mitigations

  • Risk: Existing sessions with authProfileOverrideSource: "auto" will lose their override on the next session reset, changing profile selection behavior.
    • Mitigation: This is the intended fix. Auto overrides were never meant to be permanent; they should be re-evaluated per session.

🤖 Generated with Claude Code

AI Disclosure

  • This PR was AI-assisted (built with Claude Code / Claude Opus 4.6)
  • Fully tested: 5 new unit tests added, all 7 tests in session-override.test.ts pass, full auth-profiles/ suite passes (109/110, 1 pre-existing unrelated failure)
  • I understand what the code does
  • Bot review conversations will be resolved as addressed

CI Note

The check and check-additional CI failures are pre-existing on main — type errors in extensions/slack/src/approval-handler.runtime.test.ts and extensions/telegram/src/approval-handler.runtime.test.ts (TS18046: 'payload' is of type 'unknown'). These are unrelated to this PR's changes.

Changed files

  • CHANGELOG.md (modified, +3/-0)
  • src/agents/auth-profiles/session-override.test.ts (modified, +295/-1)
  • src/agents/auth-profiles/session-override.ts (modified, +7/-1)
  • src/auto-reply/reply/session.ts (modified, +11/-3)
  • src/gateway/session-reset-service.ts (modified, +9/-2)

Code Example

if (resetTriggered && entry) {
  persistedThinking = entry.thinkingLevel;
  persistedVerbose = entry.verboseLevel;
  persistedReasoning = entry.reasoningLevel;
  persistedTtsAuto = entry.ttsAuto;
  persistedModelOverride = entry.modelOverride;
  persistedProviderOverride = entry.providerOverride;
  ...
}
RAW_BUFFERClick to expand / collapse

What happened?

In a WhatsApp direct session, /new does not clear the session-level model override.

It starts a fresh session ID, but the new session still inherits the old providerOverride / modelOverride, so the chat remains pinned to the previous model instead of falling back to the configured default.

Additionally, the reset notice can show a default: model that does not match the current configured agents.defaults.model.primary.

Repro

Environment:

  • OpenClaw 2026.3.24
  • channel: WhatsApp direct chat
  • configured default model:
    • agents.defaults.model.primary = ollama/minimax-m2.7:cloud

Steps:

  1. In WhatsApp direct chat, set a session override:
    • /model gpt
    • or any non-default model such as openai-codex/gpt-5.4
  2. Confirm with /status
  3. Send /new
  4. Send /status again

Expected

After /new (or /reset):

  • a fresh session should not keep the previous modelOverride/providerOverride
  • the session should resolve to the configured default model from:
    • agents.defaults.model.primary
  • the reset banner should show the actual configured default model

Actual

After /new:

  • the session still uses the previous override model
  • the WhatsApp session key remains the same logical route and the new session entry inherits the previous override
  • the reset banner can show a default: model that does not match the current config

Example observed behavior:

  • configured default: ollama/minimax-m2.7:cloud
  • active override before reset: openai-codex/gpt-5.4
  • after /new: still openai-codex/gpt-5.4
  • reset notice showed:
    • ✅ New session started · model: openai-codex/gpt-5.4 (default: litellm/gpt-5.3-chat)

Docs expectation

The docs imply reset should start fresh:

  • docs/concepts/session.md says /new / /reset start a fresh session ID
  • docs/concepts/model-failover.md says session pinning is reused until the session is reset

Code evidence

Installed bundle still preserves the model override on reset:

dist/pi-embedded-BaSvmUpW.js

if (resetTriggered && entry) {
  persistedThinking = entry.thinkingLevel;
  persistedVerbose = entry.verboseLevel;
  persistedReasoning = entry.reasoningLevel;
  persistedTtsAuto = entry.ttsAuto;
  persistedModelOverride = entry.modelOverride;
  persistedProviderOverride = entry.providerOverride;
  ...
}

and later writes it back into the session entry.

So /new is effectively “history fresh” but not “model fresh”.

Related issues

This looks related to prior reports in the same area:

  • #27058 /new / /reset does not clear session-level model override
  • #13982 /model default resolves to 'anthropic/default' instead of resetting to configured default model
  • #51251 Session modelOverride persists across gateway restarts, silently overrides config default

This may be a regression or an incomplete fix in the current reset path.

Suggested fix

  • On /new and /reset, do not carry over:
    • modelOverride
    • providerOverride
  • Ensure the reset notice default model is resolved from the current live config via the same path used for normal default model resolution (agents.defaults.model.primary)

extent analysis

Fix Plan

To resolve the issue, we need to modify the code to not carry over modelOverride and providerOverride when /new or /reset is triggered. We also need to ensure the reset notice default model is resolved from the current live config.

Step-by-Step Solution

  • Modify the dist/pi-embedded-BaSvmUpW.js file to remove the lines that preserve modelOverride and providerOverride on reset:
if (resetTriggered && entry) {
  persistedThinking = entry.thinkingLevel;
  persistedVerbose = entry.verboseLevel;
  persistedReasoning = entry.reasoningLevel;
  persistedTtsAuto = entry.ttsAuto;
  // Remove the following lines
  // persistedModelOverride = entry.modelOverride;
  // persistedProviderOverride = entry.providerOverride;
  ...
}
  • Update the reset notice to resolve the default model from the current live config:
const defaultModel = agents.defaults.model.primary;
// Use the defaultModel variable to display the correct default model in the reset notice
  • Ensure that the agents.defaults.model.primary is correctly configured and updated in the live config.

Verification

To verify the fix, follow the repro steps and check that:

  • After /new or /reset, the session does not inherit the previous modelOverride and providerOverride.
  • The reset notice shows the correct default model resolved from the current live config.
  • The session resolves to the configured default model from agents.defaults.model.primary.

Extra Tips

  • Make sure to test the fix in different environments and scenarios to ensure it works as expected.
  • Consider adding automated tests to prevent similar regressions in the future.
  • Review related issues (#27058, #13982, #51251) to ensure that the fix addresses all related problems.

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…
#model compatibility#GPU setup#container setup#orchestration issue#cache issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: /new and /reset preserve session model override; reset banner default can differ from agents.defaults.model.primary [2 pull requests, 1 participants]