Stale verboseLimit on session switch

When a user switches to a session that has no saved verboseLimit, record.verboseLimit is undefined. The ?? state.sessionInfo.verboseLimit fallback then preserves the previous session's limit, so chatLog.setVerboseLimit is called with a stale value. Every exec tool card shown in the new session will use the wrong truncation length.

The same session-switch fallback pattern is used for verboseLevel / thinkingLevel / etc. on the lines above and is a pre-existing quirk, but those fields don't feed chatLog state; verboseLimit does, making this observable.

Because loadHistory is the "cold" session-load path (full reload, chatLog.clearAll() follows immediately), the right behaviour here is to take whatever the server returned — undefined meaning "use the default":

This is a comment left during a code review.
Path: src/tui/tui-session-actions.ts
Line: 310-311

Comment:
**Stale `verboseLimit` on session switch**

When a user switches to a session that has no saved `verboseLimit`, `record.verboseLimit` is `undefined`. The `?? state.sessionInfo.verboseLimit` fallback then preserves the *previous* session's limit, so `chatLog.setVerboseLimit` is called with a stale value. Every exec tool card shown in the new session will use the wrong truncation length.

The same session-switch fallback pattern is used for `verboseLevel` / `thinkingLevel` / etc. on the lines above and is a pre-existing quirk, but those fields don't feed `chatLog` state; `verboseLimit` does, making this observable.

Because `loadHistory` is the "cold" session-load path (full reload, `chatLog.clearAll()` follows immediately), the right behaviour here is to take whatever the server returned — `undefined` meaning "use the default":

```suggestion
      state.sessionInfo.verboseLimit = record.verboseLimit;
      chatLog.setVerboseLimit(state.sessionInfo.verboseLimit);
```

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

chatLog limit not reset when entry clears verboseLimit

applySessionInfo is also called by the live-session-update path (e.g. after a session reload or when the gateway pushes a new entry). If the incoming entry doesn't carry verboseLimit (e.g. because it was null-patched to remove the limit), the if guard means chatLog.setVerboseLimit is never called with undefined, so the chatLog silently retains the previously-applied limit for all future tool cards.

The same concern applies if the user ever sets verboseLimit: null via sessions.patch — applySessionInfo would receive an entry with verboseLimit === undefined and leave chatLog unchanged.

Consider calling setVerboseLimit unconditionally so the chatLog always reflects the resolved session state:

This is a comment left during a code review.
Path: src/tui/tui-session-actions.ts
Line: 180-183

Comment:
**`chatLog` limit not reset when entry clears `verboseLimit`**

`applySessionInfo` is also called by the live-session-update path (e.g. after a session reload or when the gateway pushes a new entry). If the incoming `entry` doesn't carry `verboseLimit` (e.g. because it was null-patched to remove the limit), the `if` guard means `chatLog.setVerboseLimit` is never called with `undefined`, so the chatLog silently retains the previously-applied limit for all future tool cards.

The same concern applies if the user ever sets `verboseLimit: null` via `sessions.patch` — `applySessionInfo` would receive an entry with `verboseLimit === undefined` and leave chatLog unchanged.

Consider calling `setVerboseLimit` unconditionally so the chatLog always reflects the resolved session state:

```suggestion
    next.verboseLimit = entry?.verboseLimit;
    chatLog.setVerboseLimit(next.verboseLimit);
```

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

Redundant default in compactRawCommand call

compactRawCommand already declares maxLength = DEFAULT_VERBOSE_LIMIT as a default parameter, so passing maxLength ?? DEFAULT_VERBOSE_LIMIT is redundant — when maxLength is undefined both expressions produce the same result. Simplifying removes the need to keep two places in sync if the default ever changes:

This is a comment left during a code review.
Path: src/agents/tool-display-exec.ts
Line: 418

Comment:
**Redundant default in `compactRawCommand` call**

`compactRawCommand` already declares `maxLength = DEFAULT_VERBOSE_LIMIT` as a default parameter, so passing `maxLength ?? DEFAULT_VERBOSE_LIMIT` is redundant — when `maxLength` is `undefined` both expressions produce the same result. Simplifying removes the need to keep two places in sync if the default ever changes:

```suggestion
  const compact = compactRawCommand(unwrapped, maxLength);
```

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

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Trigger refresh after applying /verbose limit

executeVerbose patches verboseLimit but returns only content, while dispatchSlashCommand only reloads sessions/history when result.action === "refresh" (ui/src/ui/app-chat.ts). As a result, the active session snapshot keeps the old verboseLimit, so tool cards continue truncating exec commands at the previous length until a manual refresh or navigation occurs.

Useful? React with 👍 / 👎.

Clear stale verboseLimit when history omits it

When loading a different session, this assignment keeps the prior session’s verboseLimit whenever the new session has no override (undefined). That leaks truncation settings across sessions (e.g., session A set to 500, session B unset still renders at 500), which breaks per-session behavior and makes TUI tool display inconsistent with stored session state.

Useful? React with 👍 / 👎.

Reset verboseLimit when session entry omits override

This update only applies verboseLimit when the field is present, so a previously set limit is never cleared on refresh paths that return verboseLimit as undefined (for example after sessions.patch clears it with null, or when a session has no override). In that case state.sessionInfo.verboseLimit and tool rendering keep using the stale old value, so truncation no longer matches persisted session state.

Useful? React with 👍 / 👎.