Summary

In get-reply (compiled file dist/get-reply-*.js, around line 576), the session-entry construction uses trivial ternaries of the form resetTriggered ? X : X for six fields. Both branches are identical, so the conditional is effectively a no-op — the previous session's settings (thinkingLevel, verboseLevel, reasoningLevel, ttsAuto, modelOverride, providerOverride, authProfileOverride*) are always preserved on /reset.

This means /reset does not restore agent defaults like agents.list[].thinkingDefault or agents.defaults.thinkingDefault — those defaults are only consulted when no value was ever set, but the trivial ternary keeps any previously-set value alive across every reset.

Reproduction

1. In any session, set /thinking off
2. Run /reset
3. Send a message
4. Observe: the session is still at thinkingLevel: off, even with agents.defaults.thinkingDefault: "high" configured at the global level

Result: the only way to escape off is an explicit /thinking <level> command. Setting thinkingDefault in config has no effect for any session that has ever had an explicit thinking level set.

Affected version

[email protected] (npm latest)

Code (compiled dist/get-reply-*.js)

const sessionEntry = {
  ...!resetTriggered ? existingEntry : void 0,
  sessionId,
  sessionFile,
  updatedAt: now,
  thinkingLevel:                resetTriggered ? existingEntry?.thinkingLevel       : existingEntry?.thinkingLevel,
  verboseLevel:                 resetTriggered ? existingEntry?.verboseLevel        : existingEntry?.verboseLevel,
  reasoningLevel:               resetTriggered ? existingEntry?.reasoningLevel      : existingEntry?.reasoningLevel,
  ttsAuto:                      resetTriggered ? existingEntry?.ttsAuto             : existingEntry?.ttsAuto,
  responseUsage: !resetTriggered ? existingEntry?.responseUsage : void 0,
  modelOverride:                resetTriggered ? existingEntry?.modelOverride       : existingEntry?.modelOverride,
  providerOverride:             resetTriggered ? existingEntry?.providerOverride    : existingEntry?.providerOverride,
  authProfileOverride:          resetTriggered ? existingEntry?.authProfileOverride : existingEntry?.authProfileOverride,
  // ...
};

The pattern next to it (responseUsage) shows the intended shape — it discriminates between reset/non-reset (!resetTriggered ? existingEntry?.responseUsage : void 0). The six ternaries above appear to be a copy-paste that lost the distinguishing logic.

Expected behaviour

On /reset, the session-level overrides should fall back to agent-level / global defaults:

thinkingLevel:   resetTriggered ? void 0 : existingEntry?.thinkingLevel,
verboseLevel:    resetTriggered ? void 0 : existingEntry?.verboseLevel,
reasoningLevel:  resetTriggered ? void 0 : existingEntry?.reasoningLevel,
ttsAuto:         resetTriggered ? void 0 : existingEntry?.ttsAuto,
modelOverride:   resetTriggered ? void 0 : existingEntry?.modelOverride,
providerOverride:resetTriggered ? void 0 : existingEntry?.providerOverride,
authProfileOverride: resetTriggered ? void 0 : existingEntry?.authProfileOverride,

This way agentCfg?.thinkingDefault (and equivalents) actually take effect after reset, which matches the documented purpose of agents.defaults.thinkingDefault / agents.list[].thinkingDefault.

(If the design intent is in fact to preserve these across /reset, then the entire ternary should be replaced with the simple expression existingEntry?.thinkingLevel and the dead resetTriggered branch removed — the current form misleads anyone reading the code.)

Workaround

Manually patch sessions.json to set the desired thinkingLevel, then restart the gateway. From that point on, future resets will preserve the desired value (since the bug preserves whatever's there).

Impact

Low severity but high friction:

• thinkingDefault config setting is silently ineffective for any returning user
• Same applies to verboseLevel, reasoningLevel, model overrides, etc.
• Users assume /reset returns to a clean state — it doesn't for these fields