This is a comment left during a code review.
Path: src/auto-reply/status.ts
Line: 383-385

Comment:
**`resolveReasoningDefault` called without catalog**

`buildStatusMessage` calls `resolveReasoningDefault` without the `catalog` parameter. The function first checks the catalog for a matching entry with `reasoning === true`, then falls back to the user-config path (`cfg.models.providers.[p].models.[m].reasoning`). Since no catalog is passed here, the catalog-based detection is silently skipped.

This means: for any reasoning-capable model whose capability is declared only in the bundled model catalog (but not explicitly set in the operator's config), `buildStatusMessage` will display `Reasoning: off` even when the model is actually a reasoning model. The `/status` command path (`buildStatusReply` → `resolveDefaultReasoningLevel`) correctly loads the catalog and avoids this problem; this synchronous path does not.

The new test in `status.test.ts` only covers the case where `reasoning: true` is set in the user config, so it doesn't catch this gap.

A straightforward fix is to add an optional `catalog?: ModelCatalogEntry[]` field to `StatusArgs` and thread it through:

```typescript
// StatusArgs
catalog?: ModelCatalogEntry[];

// buildStatusMessage
const reasoningLevel =
  args.resolvedReasoning ??
  (args.config
    ? resolveReasoningDefault({ cfg: args.config, provider, model, catalog: args.catalog })
    : "off");
```

Callers that already have a catalog available (e.g. the `session_status` tool) can then pass it in, and the synchronous path will behave consistently with the async command path.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/agents/model-selection.ts
Line: 428-438

Comment:
**Catalog takes priority over operator config — user `reasoning: false` silently ignored**

`resolveReasoningDefault` checks the bundled catalog **first**. If the catalog has an entry with `reasoning: true`, the function returns `"on"` immediately and never consults the operator's per-model `reasoning` flag. This means an operator who explicitly sets `reasoning: false` in `models.providers.[provider].models` to opt a specific model out of the reasoning default will have that setting silently ignored whenever the model also appears in the catalog with `reasoning: true`.

This is the **opposite priority** of `resolveThinkingDefault`, which checks `cfg.agents.defaults.thinkingDefault` (i.e., operator config) first and only falls through to the catalog as a secondary signal.

For consistent and predictable behaviour, operator-declared per-model config should win over catalog defaults:

```
export function resolveReasoningDefault(params: {
  cfg?: OpenClawConfig;
  provider: string;
  model: string;
  catalog?: ModelCatalogEntry[];
}): "on" | "off" {
  // User config takes priority over catalog defaults
  const configuredEntry =
    params.cfg?.models?.providers?.[params.provider]?.models?.find(
      (entry) => entry.id === params.model,
    );
  if (configuredEntry !== undefined && "reasoning" in configuredEntry) {
    return configuredEntry.reasoning ? "on" : "off";
  }
  const candidate = params.catalog?.find(
    (entry) => entry.provider === params.provider && entry.id === params.model,
  );
  if (candidate?.reasoning === true) {
    return "on";
  }
  return "off";
}
```

The existing test in `status.test.ts` ("shows reasoning as on for reasoning-capable models when not explicitly overridden") only covers the case where the catalog entry is absent and user config has `reasoning: true`, so the conflict scenario is not currently caught by the test suite.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/auto-reply/reply/get-reply-directives-apply.ts
Line: 163-164

Comment:
**`resolveDefaultReasoningLevel` fallback is unreachable dead code**

`resolveCurrentDirectiveLevels` (in `directive-handling.levels.ts`) returns `currentReasoningLevel` typed as `ReasoningLevel` — never `undefined`. When the session has no explicit `reasoningLevel`, it fills in `"off"` as the hardcoded default (line 34–35 of `directive-handling.levels.ts`):

```ts
// directive-handling.levels.ts – BEFORE this PR
const currentReasoningLevel =
  (params.sessionEntry?.reasoningLevel as ReasoningLevel | undefined) ?? "off";
```

Because the return type is `ReasoningLevel` (a union of non-empty strings, all truthy), the `??` guard on the consuming side:

```ts
const currentReasoningLevel =
  resolvedCurrentReasoningLevel ?? (await modelState.resolveDefaultReasoningLevel());
```

…can **never** evaluate the right-hand branch — `"off"` is a truthy string, not `null`/`undefined`. `resolveDefaultReasoningLevel()` is dead code here.

For the directive-only path (an inline `+status` directive embedded in a regular message), sessions without an explicit `reasoningLevel` will therefore always display `Reasoning: off`, even when the model catalog marks the model as `reasoning: true`. This is exactly the bug the PR intends to fix, but the fix doesn't reach this code path.

The root fix needs to land in `resolveCurrentDirectiveLevels` — change its return type to `currentReasoningLevel: ReasoningLevel | undefined` and remove the `?? "off"` default there, then let the caller apply the catalog fallback:

```ts
// directive-handling.levels.ts
const currentReasoningLevel =
  params.sessionEntry?.reasoningLevel as ReasoningLevel | undefined;
// return it as ReasoningLevel | undefined — callers apply the catalog default
```

With that change the `??` guard in `get-reply-directives-apply.ts` would fire correctly when the session has no persisted value, and `resolveDefaultReasoningLevel()` would supply the catalog-backed default.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/agents/model-selection.test.ts
Line: 852

Comment:
**`resolveReasoningDefault` tests nested inside wrong describe block**

The new `describe("resolveReasoningDefault", ...)` block is placed as a nested child of `describe("normalizeModelSelection", ...)`. These are unrelated utilities, so test output (and IDE tree views) will show the new tests under the `normalizeModelSelection` suite, making failures harder to locate.

Consider promoting it to a top-level describe, or nesting it under an existing block that is specifically about model-selection helpers (there are several at the top of the file):

```suggestion
});

describe("resolveReasoningDefault", () => {
  it("uses explicit config reasoning false before catalog reasoning true", () => {
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/auto-reply/reply/model-selection.ts
Line: 406-408

Comment:
**Caching guard won't short-circuit for `"off"` — but only on first call**

`if (defaultReasoningLevel)` is truthy for both `"on"` and `"off"` (non-empty strings), so the cache works correctly once a value has been stored. However, because the result of `resolveReasoningDefault` is synchronous, two concurrent `await resolveDefaultReasoningLevel()` calls that both see `defaultReasoningLevel === undefined` will both fall through and call `loadModelCatalog` a second time before the first write lands. This is an inherent race in the memoization pattern (also present in `resolveDefaultThinkingLevel`), but it's worth keeping in mind if `loadModelCatalog` ever becomes expensive or stateful.

No change is required for correctness; the worst case is a redundant catalog load that produces the same value.

How can I resolve this? If you propose a fix, please make it concise.