@pellux/goodvibes-tui 1.20.0 → 1.20.1

package/CHANGELOG.md

@@ -4,6 +4,13 @@ All notable changes to GoodVibes TUI.
 
 ---
 
+## [1.20.1] - 2026-07-25
+
+### Changes
+
+- fd3b3037 fix: recovery offers and removals behave; active-model surfaces agree; failover is visible and temporary
+- 08237438 docs: replace README screenshots with true terminal captures
+
 ## [1.20.0] - 2026-07-24
 
 ### Changes

package/README.md

@@ -2,11 +2,11 @@
 
 [![CI](https://github.com/mgd34msu/goodvibes-tui/actions/workflows/ci.yml/badge.svg)](https://github.com/mgd34msu/goodvibes-tui/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
-[![Version](https://img.shields.io/badge/version-1.20.0-blue.svg)](https://github.com/mgd34msu/goodvibes-tui)
+[![Version](https://img.shields.io/badge/version-1.20.1-blue.svg)](https://github.com/mgd34msu/goodvibes-tui)
 
 GoodVibes is a terminal console for coding and operations work with an AI model. You run `goodvibes` in a project directory and get a full-screen terminal app where you talk to a model that can read and edit your files, run shell commands, search the web, and hand work off to background agents — asking your permission before anything that writes or executes. It talks to many model providers (OpenAI, Anthropic, Gemini, Bedrock, Copilot, OpenRouter and other OpenAI-compatible gateways, plus local servers like Ollama and LM Studio that it finds on startup), keeps its settings, sessions, and secrets on your own machine, and shows you the token count and running cost of every turn. Alongside the conversation, panels turn background work — running agents, git state, diffs, tokens, cost — into live control rooms.
 
-<img src="docs/assets/splash.png" alt="GoodVibes starting up in a terminal: a glitch-art GOODVIBES wordmark in cyan-to-magenta gradient, the version and tagline beneath it, the active model and tool count, the working directory, and a hint line reading Ctrl+P panels / ? help / F2 fleet. A status footer shows mode, token usage, context usage, and the daemon and web listener addresses." width="900">
+<img src="docs/assets/splash.png" alt="GoodVibes starting up in a terminal: a glitch-art GOODVIBES wordmark in cyan-to-magenta gradient, the version and tagline beneath it, the active model and tool count, the working directory, a line offering to resume the last session, and a hint line reading Ctrl+P panels / ? help / F2 fleet. A status footer shows mode, token usage, context usage, and the daemon and web listener addresses." width="900">
 
 ---
 
@@ -45,7 +45,7 @@ Deeper install notes — the installer's environment variables, uninstall, daemo
 
 ### The conversation loop
 
-<img src="docs/assets/conversation.png" alt="A conversation turn in the terminal. The user asks the model to read two source files and explain the project. Below it, an assistant block lists two read tool calls with green checkmarks, followed by a collapsed group labelled tool results, 2 tools, 2 lines. A second assistant block makes one more read call. The final answer is plain prose with an identifier syntax-highlighted in yellow. The footer reads Token Usage: Input 41.3k, Output 337, Cache Read 0, Cache Write 0, Total 41.6k, approximately 0.129 dollars, above a green context usage bar at 5 percent." width="900">
+<img src="docs/assets/conversation.png" alt="Two conversation turns in the terminal. The tail of an earlier answer describes the project as a minimal ISS pass tracker whose calculation is still a stub. Below it the user asks the model to grep for nextPass and list every file that references it; an assistant block shows one find tool call with a green checkmark, and its result is expanded as syntax-highlighted JSON with line numbers listing the two matching file paths and a count of 2. The final answer names src/passes.ts and src/index.ts as a bulleted list. The footer reads Token Usage: Input em dash, Output 264, Cache Read 0, Cache Write 0, Total 264, approximately 0.0040 dollars, above a green context usage bar at 4 percent." width="900">
 
 Tool calls stream inline as the model makes them, then their results fold into a collapsible group so a long working session stays readable — expand any group to see what actually came back. Assistant messages render markdown, syntax-highlighted code, and inline diffs, and any block can be collapsed, bookmarked, copied, or saved to a file.
 
@@ -57,13 +57,13 @@ The footer keeps an honest running total: fresh input tokens separated from cach
 
 The first time you open a directory, GoodVibes asks how much it is allowed to do there. Restricted is read-only: the model can look around, but writes and commands are refused until you trust the workspace.
 
-<img src="docs/assets/permission-prompt.png" alt="An execution approval prompt. A header reads EXECUTE, Shell Execution Approval. Fields list the requesting session, the tool exec, the full command, the working directory, a Risk line reading HIGH write in red, the surface and radius, a summary, the effects: process execution, filesystem mutation, possible network access, and a reviewer checklist. Below, four numbered remember options scope an approval to this exact command, to every mkdir command, to every exec call in this project, or to the rest of the session in memory only. The action line reads: Y Allow once, 1-4 Allow and remember, N Deny, or type a reason to deny." width="900">
+<img src="docs/assets/permission-prompt.png" alt="An execution approval prompt. A header reads EXECUTE, Shell Execution Approval, one more waiting. Fields list the requesting session, the tool exec, the full command mkdir -p build, the working directory, a Risk line reading HIGH write in red, the surface and radius, a summary, the decision class, the effects: process execution, filesystem mutation, possible network access, a reviewer checklist, and the raw tool arguments. Below, four numbered remember options scope an approval to this exact command, to every mkdir command, to every exec call in this project, or to the rest of the session in memory only. The action line reads: Y Allow once, 1-4 Allow and remember, N Deny, or type a reason to deny." width="900">
 
 After that, the default permission mode is `prompt`: writes, edits, shell commands, network fetches, agent spawns, and MCP calls each stop and ask. The prompt shows what will run, in which directory, its assessed risk, and what it can affect. You can allow it once, deny it (optionally typing a reason the model sees), or remember the decision at whichever scope fits — this exact command, this command shape, this tool for the whole project, or just for the rest of the session. Four other modes are available when prompting is not what you want: `accept-edits` auto-approves file writes and edits while exec and the other risky classes still ask, `plan` allows read-only tools and refuses every mutating or exec call, `allow-all` approves everything, and `custom` takes per-tool `allow` / `prompt` / `deny` overrides. `Shift+Tab` cycles the four session postures — normal, accept-edits, plan, auto — and `/plan` toggles plan mode directly.
 
 ### Models and providers
 
-<img src="docs/assets/model-picker.png" alt="A fullscreen model workspace. A left column lists routing targets: Main Chat set, Helper Model off, Tool LLM off, TTS LLM inherit, and Embeddings set. The right pane shows the selected target with its current model and a filter row for search, price, capability, grouping, and availability. Below, a table of models lists model key, display name, provider, context window, tier, and capability flags across 2017 catalogued entries, with a footer of list shortcuts." width="900">
+<img src="docs/assets/model-picker.png" alt="A fullscreen model workspace. A left column lists routing targets: Main Chat set, Helper Model off, Tool LLM off, TTS LLM inherit, and Embeddings set. The right pane shows the selected target with its current model and a filter row for search, price, capability, grouping, and availability. Below, a table of models lists model key, display name, provider, context window, tier, and capability flags across 2030 catalogued entries, with a footer of list shortcuts." width="900">
 
 Models come from a live catalog, so the picker lists far more than a hardcoded set, filterable by search, price, capability, and availability. Separate roles route independently: your main chat model, a cheaper helper model for grunt work, a tool model, a TTS model, and an embeddings model can each point somewhere different.
 
@@ -71,13 +71,13 @@ The `synthetic` provider groups the same model across every backend that serves
 
 ### The Fleet control room
 
-<img src="docs/assets/fleet-panel.png" alt="The Fleet panel open beside the conversation. It lists background work as rows with a kind, a name, elapsed time, token count, and cost — a CI watch poller and a runtime health watcher at 59 seconds each, and a code indexer. The detail region below shows the selected watcher's id, state idle, elapsed time, model, tokens, cost, a headline reading CI watch poller, healthy, an activity phase, and an approvals line. The action hints read j/k navigate, Enter attach, K kill, A archive finish." width="900">
+<img src="docs/assets/fleet-panel.png" alt="The Fleet panel open beside the conversation. It lists background work as rows with a kind, a name, elapsed time, token count, and cost — a CI watch poller and a runtime heartbeat watcher at 4 minutes 23 seconds each, and an idle code indexer. The detail region below shows the selected watcher's id, state idle, elapsed time, model, tokens, cost, a headline reading CI watch poller, healthy, an activity phase, and an approvals line. The action hints read j/k navigate, Enter attach, K kill, A archive finished, v archived, n host agent." width="900">
 
 Work that is not conversation goes into panels instead of scrolling past in the transcript. Fleet — reached with `F2` — is the live control room for agents, workstreams, watchers, and scheduled jobs: what is running, for how long, at what token cost, and what it is waiting on. You can attach to a running agent to watch or steer it, detach again without killing it, pause and resume, and archive finished work. Git, diff, cost, token, and local-auth panels sit alongside it; heavier operator surfaces open as review modals.
 
 ### Everything else is a command
 
-<img src="docs/assets/help-overlay.png" alt="A searchable help overlay titled Help, Commands, with a search field and results grouped by category. Under Provider Accounts is the /accounts command with review, panel, show, routes, and repair subcommands and a one-line description. Under Fleet is /agents, described as hosting third-party coding agents as fleet rows over ACP. A line reads 146 below, and the hints read Up/Down Navigate, Enter Run, / Search, Esc Close." width="820">
+<img src="docs/assets/help-overlay.png" alt="A searchable help overlay titled Help, Commands, with a search field and results grouped by category. Under Provider Accounts is the /accounts command with review, panel, show, routes, and repair subcommands and a one-line description. Under Fleet is /agents, described as hosting third-party coding agents as fleet rows over ACP. Under Experience is /approval, for reviewing action-specific approval classes. A line reads 147 below, and the hints read Up/Down Navigate, Enter Run, / Search, Esc Close." width="820">
 
 Press `?` for a searchable, categorized list of every slash command with its arguments and description. The same list is generated into [docs/commands-reference.md](docs/commands-reference.md).
 

package/docs/foundation-artifacts/operator-contract.json

@@ -3,7 +3,7 @@
   "product": {
     "id": "goodvibes",
     "surface": "operator",
-    "version": "1.12.0"
+    "version": "1.12.1"
   },
   "auth": {
     "modes": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pellux/goodvibes-tui",
-  "version": "1.20.0",
+  "version": "1.20.1",
   "description": "Terminal-native GoodVibes product for coding, operations, automation, knowledge, channels, and daemon-backed control-plane workflows.",
   "type": "module",
   "main": "src/main.ts",
@@ -104,8 +104,8 @@
     "@anthropic-ai/vertex-sdk": "^0.16.0",
     "@ast-grep/napi": "^0.42.0",
     "@aws/bedrock-token-generator": "^1.1.0",
-    "@pellux/goodvibes-sdk": "1.12.0",
-    "@pellux/goodvibes-terminal-shell": "1.12.0",
+    "@pellux/goodvibes-sdk": "1.12.1",
+    "@pellux/goodvibes-terminal-shell": "1.12.1",
     "bash-language-server": "^5.6.0",
     "fuse.js": "^7.1.0",
     "graphql": "^16.13.2",
@@ -131,10 +131,10 @@
     "typescript": "^5.9.3"
   },
   "optionalDependencies": {
-    "@pellux/goodvibes-tui-linux-x64": "1.20.0",
-    "@pellux/goodvibes-tui-linux-arm64": "1.20.0",
-    "@pellux/goodvibes-tui-darwin-x64": "1.20.0",
-    "@pellux/goodvibes-tui-darwin-arm64": "1.20.0"
+    "@pellux/goodvibes-tui-linux-x64": "1.20.1",
+    "@pellux/goodvibes-tui-linux-arm64": "1.20.1",
+    "@pellux/goodvibes-tui-darwin-x64": "1.20.1",
+    "@pellux/goodvibes-tui-darwin-arm64": "1.20.1"
   },
   "trustedDependencies": [],
   "overrides": {

package/src/cli/bundle-command.ts

@@ -12,7 +12,7 @@ import type { ConfigKey } from '../config/index.ts';
 import type { CliCommandRuntime } from './types.ts';
 import type { CliCommandOutput } from './types.ts';
 import { getPackageVersion } from './help.ts';
-import { classifyProviderSetup } from './provider-classification.ts';
+import { classifyProviderSetup } from '../providers/provider-classification.ts';
 import { buildCliServicePosture } from './service-posture.ts';
 import { REDACTED_VALUE, collectSensitiveConfigValues, isRedactedValue, redactConfig, redactSerializedSecrets } from './redaction.ts';
 import { summarizeError } from '@pellux/goodvibes-sdk/platform/utils';

package/src/cli/management.ts

@@ -13,7 +13,7 @@ import { beginOpenAICodexLogin, exchangeOpenAICodexCode } from '@pellux/goodvibe
 import { inspectProviderAuth } from '@/runtime/index.ts';
 import type { CliCommandRuntime, GoodVibesCliParseResult } from './types.ts';
 import { formatProviderAuthRoute, summarizeProviderAuthRoutes } from './provider-auth-routes.ts';
-import { classifyProviderSetup } from './provider-classification.ts';
+import { classifyProviderSetup } from '../providers/provider-classification.ts';
 import { resolveRuntimeEndpointBinding } from './endpoints.ts';
 import { applyRuntimeEndpointFlagOverrides } from './config-overrides.ts';
 import type { RuntimeEndpointId } from './endpoints.ts';

package/src/core/active-model-identity.ts

@@ -0,0 +1,153 @@
+/**
+ * active-model-identity.ts — the single answer to "which backend is serving
+ * this session right now, and is that what the user chose?"
+ *
+ * Two shell surfaces used to answer that question independently and could
+ * therefore contradict each other:
+ *   - the top-right header read `providerRegistry.getCurrentModel()` live
+ *     every frame, so it followed an automatic failover switch immediately;
+ *   - the footer read `runtime.model` / `runtime.provider`, which only
+ *     bootstrap and explicit user model switches ever wrote, so it kept
+ *     naming the configured backend after failover had moved serving (and
+ *     billing) somewhere else.
+ *
+ * Both surfaces now resolve through resolveActiveModelDisplay() so they are
+ * computed from one comparison of serving-vs-configured. Divergence is
+ * detected structurally — by comparing the live registry key against the
+ * configured selection — not by trusting a flag, so ANY path that moves the
+ * registry off the user's choice is surfaced, not just the failover path that
+ * sets the record below.
+ *
+ * The failover record adds the REASON for a divergence ("failover from …");
+ * it never decides whether one exists.
+ */
+
+/**
+ * The live per-turn record of an automatic provider failover.
+ *
+ * `configuredRegistryKey` is sticky across repeated failovers within one turn
+ * (a second hop still reports divergence from what the USER chose, not from
+ * the first fallback). `servingRegistryKey` tracks the most recent switch.
+ */
+export interface FailoverTurnRecord {
+  /** The user's configured selection (`provider.model`) when failover began. */
+  readonly configuredRegistryKey: string;
+  /** The registry key failover switched serving to. */
+  readonly servingRegistryKey: string;
+}
+
+/**
+ * Mutable holder for the failover record, owned by the shell composition root
+ * (main.ts) and shared between the stream-event wiring that sets it and the
+ * render frame that reads it.
+ */
+export interface FailoverTurnState {
+  /** The active record, or null when no failover is in effect. */
+  current(): FailoverTurnRecord | null;
+  /**
+   * Record a failover switch. On a second switch within the same turn the
+   * originally-configured key is preserved — divergence is always reported
+   * against the user's own selection.
+   */
+  begin(record: FailoverTurnRecord): void;
+  /** Drop the record — called only after serving is actually back on the configured selection. */
+  clear(): void;
+}
+
+/** Create an empty FailoverTurnState. */
+export function createFailoverTurnState(): FailoverTurnState {
+  let active: FailoverTurnRecord | null = null;
+  return {
+    current: () => active,
+    begin(record: FailoverTurnRecord): void {
+      active = active === null
+        ? record
+        : { configuredRegistryKey: active.configuredRegistryKey, servingRegistryKey: record.servingRegistryKey };
+    },
+    clear(): void { active = null; },
+  };
+}
+
+/** What the live provider registry reports as serving this frame. */
+export interface ServingModelIdentity {
+  readonly id: string;
+  readonly provider: string;
+  readonly registryKey?: string | undefined;
+}
+
+export interface ActiveModelInputs {
+  /** Live registry answer — who is actually serving right now. */
+  readonly serving: ServingModelIdentity;
+  /** The user's configured selection as a registry key (config `provider.model`). */
+  readonly configuredRegistryKey: string | undefined;
+  /** The configured selection's footer label (session `runtime.model`). */
+  readonly configuredLabel: string | undefined;
+  /** The configured selection's provider id (session `runtime.provider`). */
+  readonly configuredProvider: string | undefined;
+  /** The live failover record, when one is in effect. */
+  readonly failover: FailoverTurnRecord | null;
+}
+
+export interface ActiveModelDisplay {
+  /** Model text for the header's right-hand segment. */
+  readonly headerModel: string;
+  /** Provider text for the header's right-hand segment. */
+  readonly headerProvider: string;
+  /** Model text for the footer's context-info segment. */
+  readonly footerModel: string;
+  /** Provider text for the footer's context-info segment. */
+  readonly footerProvider: string;
+  /**
+   * Divergence marker naming the configured selection, e.g.
+   * `failover from abacusai:route-llm`. Empty string when serving is the
+   * configured selection — in that case both surfaces render exactly as they
+   * did before this resolver existed.
+   */
+  readonly divergenceNote: string;
+  /** True when the serving backend is not the user's configured selection. */
+  readonly diverged: boolean;
+}
+
+/**
+ * Decide what the header and footer say about the active model this frame.
+ *
+ * Divergence requires BOTH a known live registry key and a known configured
+ * selection; if either is missing the resolver reports no divergence rather
+ * than guessing, because a false "failover" marker would be its own lie. The
+ * configured selection is matched against the serving registry key AND the
+ * bare serving model id, so a config value stored as a bare model id (rather
+ * than the `provider:model` registry key) does not read as permanent divergence.
+ */
+export function resolveActiveModelDisplay(input: ActiveModelInputs): ActiveModelDisplay {
+  const servingKey = input.serving.registryKey;
+  const configuredKey = input.configuredRegistryKey;
+  const diverged = Boolean(
+    servingKey && configuredKey && configuredKey !== servingKey && configuredKey !== input.serving.id,
+  );
+  if (!diverged) {
+    return {
+      headerModel: input.serving.id,
+      headerProvider: input.serving.provider,
+      // Footer keeps its own established label form (runtime.model) when there
+      // is nothing to correct, so the unchanged case renders byte-identically.
+      footerModel: input.configuredLabel ?? input.serving.id,
+      footerProvider: input.configuredProvider ?? input.serving.provider,
+      divergenceNote: '',
+      diverged: false,
+    };
+  }
+  // Serving != configured. Both surfaces now name the SERVING backend, plus a
+  // marker naming the configured selection it departed from. The failover
+  // record supplies the reason only when it matches the backend actually
+  // serving; any other divergence is described without claiming a cause.
+  const causedByFailover = input.failover !== null && input.failover.servingRegistryKey === servingKey;
+  const reason = causedByFailover ? 'failover from' : 'not the configured';
+  return {
+    headerModel: input.serving.id,
+    headerProvider: input.serving.provider,
+    footerModel: input.serving.id,
+    footerProvider: input.serving.provider,
+    divergenceNote: `${reason} ${configuredKey}`,
+    diverged: true,
+  };
+}

package/src/core/conversation-user-receipts.ts

@@ -0,0 +1,42 @@
+/**
+ * conversation-user-receipts.ts — tracks which system-role message indices
+ * are a direct receipt for an explicit user action (e.g. answering the
+ * startup recovery modal's Resume/Keep/Remove choice), as opposed to ambient
+ * boot chatter (provider registration, the resume notice, etc.). Kept in its
+ * own file so ConversationManager (core/conversation.ts) — already near its
+ * line-count gate — doesn't have to carry the bookkeeping inline.
+ *
+ * ConversationManager.rebuildHistory()'s splash-vs-transcript check consults
+ * this via ConversationManager.addUserActionReceipt(): a receipt the user is
+ * actively waiting on must displace the splash the way a user message does,
+ * while quiet startup plumbing keeps rendering underneath it. Indices mirror
+ * messageKindRegistry's own lifecycle — cleared on resetAll(), purged for
+ * indices an undo() frees for reuse, deleted when a later add overwrites the
+ * same recycled index with a non-receipt message.
+ */
+export class UserReceiptIndices {
+  private readonly indices = new Set<number>();
+
+  add(index: number): void {
+    this.indices.add(index);
+  }
+
+  delete(index: number): void {
+    this.indices.delete(index);
+  }
+
+  has(index: number): boolean {
+    return this.indices.has(index);
+  }
+
+  clear(): void {
+    this.indices.clear();
+  }
+
+  /** Drop every tracked index >= minIndex — mirrors undo()'s tail-splice. */
+  purgeFrom(minIndex: number): void {
+    for (const key of this.indices) {
+      if (key >= minIndex) this.indices.delete(key);
+    }
+  }
+}

package/src/core/conversation.ts

@@ -14,6 +14,7 @@ import {
 } from '@pellux/goodvibes-sdk/platform/core';
 import type { BlockMeta } from './conversation-types.ts';
 import { MessageLineCache } from './conversation-line-cache.ts';
+import { UserReceiptIndices } from './conversation-user-receipts.ts';
 import {
   addConversationSplashScreen,
   conversationTextToLines,
@@ -139,6 +140,8 @@ export class ConversationManager extends SdkConversationManager {
   private errorLineRegistry: number[] = [];
   /** Maps message index → SystemMessageKind for system-role messages. */
   private messageKindRegistry: Map<number, SystemMessageKind> = new Map();
+  /** See conversation-user-receipts.ts. */
+  private userReceiptIndices = new UserReceiptIndices();
   /** Streaming block start line in history buffer (for incremental streaming update). */
   private streamingStartLine = -1;
   /**
@@ -221,25 +224,21 @@ export class ConversationManager extends SdkConversationManager {
     // stale kind (e.g. 'operational') and silently mis-classify the new message.
     const nextIndex = this.getMessageSnapshot().length;
     this.messageKindRegistry.delete(nextIndex);
+    this.userReceiptIndices.delete(nextIndex);
     super.addSystemMessage(content);
     this.markDirty();
   }
 
   /**
-   * addTypedSystemMessage - Add a system message with an explicit kind tag.
-   * The kind is stored in messageKindRegistry (keyed by the message index that
-   * will be assigned after the push) so that renderConversationSystemMessage
-   * can use it instead of text-based pattern matching.
-   *
-   * Called by SystemMessageRouter.routeTypedSystemMessage when routing to the
-   * conversation surface. Falls back to addSystemMessage for callers that do
-   * not have kind information.
+   * addTypedSystemMessage - System message with an explicit kind tag, stored
+   * in messageKindRegistry. `isUserReceipt` (conversation-user-receipts.ts)
+   * additionally marks it for rebuildHistory()'s splash check — only for a
+   * direct receipt to an explicit user action, never ambient boot chatter.
    */
-  public addTypedSystemMessage(content: string, kind: SystemMessageKind): void {
-    // getMessageSnapshot().length is the index this message will receive after
-    // addSystemMessage appends it to the messages array.
+  public addTypedSystemMessage(content: string, kind: SystemMessageKind, opts?: { isUserReceipt?: boolean }): void {
     const nextIndex = this.getMessageSnapshot().length;
     this.messageKindRegistry.set(nextIndex, kind);
+    if (opts?.isUserReceipt) this.userReceiptIndices.add(nextIndex); else this.userReceiptIndices.delete(nextIndex);
     super.addSystemMessage(content);
     this.markDirty();
   }
@@ -256,6 +255,7 @@ export class ConversationManager extends SdkConversationManager {
       for (const key of this.messageKindRegistry.keys()) {
         if (key >= postUndoCount) this.messageKindRegistry.delete(key);
       }
+      this.userReceiptIndices.purgeFrom(postUndoCount);
       this.markDirty();
     }
     return result;
@@ -357,6 +357,7 @@ export class ConversationManager extends SdkConversationManager {
     this.messageLineRegistry = [];
     this.errorLineRegistry = [];
     this.messageKindRegistry = new Map();
+    this.userReceiptIndices.clear();
     this.streamingStartLine = -1;
     this._displayFromMessageIndex = 0; // full reset — show everything on next render
   }
@@ -478,12 +479,14 @@ export class ConversationManager extends SdkConversationManager {
     const displayStart = this._displayFromMessageIndex;
     const visibleSnapshot = displayStart > 0 ? renderSnapshot.slice(displayStart) : renderSnapshot;
 
-    // Tool messages ARE rendered (as collapsed blocks); this filter is only
-    // for determining whether to show the splash screen (tool-only messages
-    // don't count as visible conversation content for splash purposes).
-    const displayMessages = visibleSnapshot.filter(
-      (m) => m.role !== 'tool' && m.role !== 'system',
-    );
+    // Tool/system messages aren't visible splash-purposes content, except a
+    // system message in userReceiptIndices. visibleSnapshot mirrors the
+    // snapshot 1:1 (only front-sliced), so index i is absolute displayStart+i.
+    const displayMessages = visibleSnapshot.filter((m, i) => {
+      if (m.role === 'tool') return false;
+      if (m.role === 'system') return this.userReceiptIndices.has(displayStart + i);
+      return true;
+    });
 
     if (displayMessages.length === 0 && displayStart === 0 && !this.suppressSplash) {
       this.addSplashScreen(width);