fix(cli): wait for the startup chat before an OpenTUI turn sends (#11042) (#11046)

* fix(cli): wait for the startup chat before an OpenTUI turn sends (#11042)

The `E2E Interactive - OpenTUI renderer (bun)` leg goes red on main with no
commit to blame. It failed at 0dd5bf2 and at 39a84c9 — the rewind
classifier refactor this issue names — and passed at 74fe3a6, which carries
that same refactor; 56f75ad failed run 33834473606 and passed run
33836390526 on an identical SHA. The job uploads no artifact and its log is
auth-gated, so the failing test is not readable from the run.

Reproduced locally instead, under CI's own bun pin and its exact command: four
interactive specs fail all three vitest attempts (exit 1, 460s) while the same
four pass under ink on the same machine in 34.8s. The rendered screen names the
cause — `Chat not initialized` sitting where the first prompt should have
opened a turn — and the scripted model server records zero requests, so the
prompt never became a turn at all.

OpenTUI mounts its composer and, from that mount effect, loads the command
registry, which calls `config.initialize()`. `Config.initialize()` sets its own
`initialized` guard before the work runs and reaches
`llmClient.initialize()` -> `startChat()` only near the end, so a prompt
submitted inside that window makes the turn's own `initialize()` throw
"already initialized" — which the turn's catch reads as "already done" and
proceeds. The client has no chat yet, the send dies in `getChat()`, and the
prompt is dropped. ink cannot reach this state: #11000 gates `isInputActive` on
`isConfigInitialized`, so its composer accepts nothing until initialization
completes, and OpenTUI has no equivalent gate.

`OpenTuiSlashDispatcher.ensureCommandsLoaded` already self-heals the same
window for the registry with a bounded poll; the turn path never got one. Wait
for the chat the in-flight initialization creates, on the same budget, so a
config that never finishes still reports its own error instead of hanging the
prompt. Starting the chat directly is not the fix: `LlmClient.initialize()`
guards only on an already-built chat, so a second caller inside the window
would build a second one.

Witness: a turn whose `initialize()` throws "already initialized" against a
client that reports no chat and throws from the send until one appears. With
the wait removed the case fails `Error: Chat not initialized`; restored, the
send runs once and the file's 45 cases pass.

Measured: the leg now exits 0 with 10 files passed and 1 skipped (19 tests),
against 4 failed files before.

* fix(cli): hold the OpenTUI turn until the startup chat has tools (#11042)

Chat existence is not readiness: startChat() assigns the chat and only
then awaits the SessionStart hook, its context and setTools(), so a wait
polling isInitialized() released the session's first prompt before the
tool declarations existed and the turn reached the model with no tools.
Release on the generation config's tools instead — setTools() is the
flight's last stage and always writes them — and give the wait's
deadline branch its own fake-timer witness.

* fix(cli): settle the startup-chat wait on abort and on expiry (#11042)

The wait this branch added is the first multi-second window between an
OpenTUI submit and its send, and it consulted neither the turn's abort
signal nor what its own expiry means.

An Esc pressed inside it was ignored for the whole budget, and nothing
between the loop and sendMessageStream re-checks the signal for text-only
input — applyPromptVisionBridge returns on !hasImageParts before its
abort check, and @-expansion is skipped for non-@ text — so a prompt the
user had already cancelled still fired its UserPromptSubmit hooks and
pushed a history entry. Poll the signal in the loop condition and throw
once it aborts: the throw is what routes the turn through runTurn's
catch, which settles on abort.signal.aborted, where a clean generator
return would have fired onComplete instead.

Expiry also fell through to a send whenever the flight had assigned the
chat but not reached setTools(), so a SessionStart hook slower than the
budget produced a turn answered with zero tool declarations and nothing
on screen to say so. Fail that case with a named error, gated on
isInitialized() so a config that never created a chat still surfaces the
client's own "Chat not initialized".

One existing test changed shape, not assertion: "skips steering when the
turn is aborted" pre-aborted its controller before calling the generator,
a state the production caller cannot reach and which now settles before
the send. It aborts inside the fake stream instead, where a real Esc
arrives. Measured on the pre-round source, neither version witnesses the
tool-response boundary guard — both pass with `|| abort.aborted` deleted
— so no coverage moved.

---------

Co-authored-by: Shaojin Wen <shaojin.wensj@alibaba-inc.com>

Author: qwen-code-dev-bot

packages/cli/src/ui/opentui/live-session.test.ts

@@ -29,6 +29,7 @@ import {
   nextApprovalMode,
   resetPromptCountForTesting,
   selectAutoApprovals,
+  STARTUP_CHAT_WAIT_MS,
   type WaitingCallInfo,
 } from './live-session.js';
 import type { OpenTuiStreamEvent } from './event-adapter.js';
@@ -188,10 +189,19 @@ vi.mock('../hooks/atCommandProcessor.js', () => ({
 function createFakeConfig(
   sendMessageStream: (...args: unknown[]) => unknown,
   bridgeModel?: VisionBridgeModelSelection,
+  isInitialized: () => boolean = () => true,
 ) {
   return {
     initialize: vi.fn(async () => {}),
-    getGeminiClient: () => ({ sendMessageStream }),
+    getGeminiClient: () => ({
+      sendMessageStream,
+      isInitialized,
+      // A chat the startup flight has already completed: `setTools()` ran, so
+      // its declarations are in the generation config the send reads.
+      getChat: () => ({
+        getGenerationConfig: () => ({ tools: [{ functionDeclarations: [] }] }),
+      }),
+    }),
     getSessionId: () => 'session-1',
     getModel: () => 'test-model',
     getMaxSessionTurns: () => 10,
@@ -276,6 +286,185 @@ describe('livePromptEvents', () => {
     expect(options).toEqual({ type: SendMessageType.UserQuery });
   });
 
+  it('waits for the chat an in-flight startup initialization creates', async () => {
+    // The boot-time command-registry load owns the initialize() flight, so the
+    // turn's own call throws "already initialized" and its catch proceeds
+    // while startChat() has not run yet. The real client then throws from
+    // getChat(); the stand-in throws the same way, so the wait is what keeps
+    // the turn alive.
+    let chatReady = false;
+    const sendMessageStream = vi.fn(function* () {
+      if (!chatReady) throw new Error('Chat not initialized');
+      yield { type: 'finished', value: {} };
+    });
+    const config = {
+      ...createFakeConfig(sendMessageStream, undefined, () => chatReady),
+      initialize: vi.fn(async () => {
+        throw new Error('Config was already initialized');
+      }),
+    } as unknown as Config;
+    setTimeout(() => {
+      chatReady = true;
+    }, 250);
+
+    await drain(livePromptEvents(config, 'hello'));
+
+    expect(sendMessageStream).toHaveBeenCalledTimes(1);
+  });
+
+  it('holds the first send until the startup chat has tool declarations', async () => {
+    // `startChat()` assigns the chat (client.ts:2261) and only then awaits the
+    // SessionStart hook, the session-start context and `setTools()`. A wait
+    // that releases on chat existence alone sends the first prompt of the
+    // session with no tool declarations at all.
+    let chatExists = false;
+    let tools: unknown[] | undefined;
+    let toolsAtSend: unknown[] | undefined;
+    const sendMessageStream = vi.fn(function* () {
+      toolsAtSend = tools;
+      yield { type: 'finished', value: {} };
+    });
+    const config = {
+      ...createFakeConfig(sendMessageStream),
+      initialize: vi.fn(async () => {
+        throw new Error('Config was already initialized');
+      }),
+      getGeminiClient: () => ({
+        sendMessageStream,
+        isInitialized: () => chatExists,
+        getChat: () => ({ getGenerationConfig: () => ({ tools }) }),
+      }),
+    } as unknown as Config;
+
+    vi.useFakeTimers();
+    try {
+      chatExists = true;
+      const pending = drain(livePromptEvents(config, 'hello'));
+      // The chat exists while the startup flight is still inside setTools().
+      await vi.advanceTimersByTimeAsync(1_000);
+      expect(sendMessageStream).not.toHaveBeenCalled();
+      tools = [{ functionDeclarations: [] }];
+      await vi.advanceTimersByTimeAsync(1_000);
+      await pending;
+    } finally {
+      vi.useRealTimers();
+    }
+
+    expect(sendMessageStream).toHaveBeenCalledTimes(1);
+    // A literal, not the mutable `tools`, so a send that observed no tools
+    // cannot pass by comparing two undefined values.
+    expect(toolsAtSend).toEqual([{ functionDeclarations: [] }]);
+  });
+
+  it('reports the client error once the startup chat wait is spent', async () => {
+    // The bound is what keeps a config that never finishes initializing from
+    // polling forever: the turn falls through to the send and surfaces the
+    // client's own error instead of hanging the prompt.
+    const sendMessageStream = vi.fn(function* () {
+      throw new Error('Chat not initialized');
+      yield { type: 'finished', value: {} };
+    });
+    const config = {
+      ...createFakeConfig(sendMessageStream),
+      initialize: vi.fn(async () => {
+        throw new Error('Config was already initialized');
+      }),
+      getGeminiClient: () => ({
+        sendMessageStream,
+        isInitialized: () => false,
+        getChat: () => {
+          throw new Error('Chat not initialized');
+        },
+      }),
+    } as unknown as Config;
+
+    vi.useFakeTimers();
+    try {
+      const pending = drain(livePromptEvents(config, 'hello'));
+      // The wait expires deep inside the virtual-time run, so keep the
+      // rejection handled until the assertion below can claim it.
+      void pending.catch(() => {});
+      await vi.advanceTimersByTimeAsync(STARTUP_CHAT_WAIT_MS + 1_000);
+      await expect(pending).rejects.toThrow('Chat not initialized');
+    } finally {
+      vi.useRealTimers();
+    }
+
+    expect(sendMessageStream).toHaveBeenCalledTimes(1);
+  });
+
+  it('settles an Esc pressed during the startup wait without sending', async () => {
+    // Releasing the wait is not enough: a text-only prompt has no abort gate
+    // between the loop and `sendMessageStream`, so falling through would fire
+    // the UserPromptSubmit hooks and push history for a cancelled prompt.
+    const controller = new AbortController();
+    const sendMessageStream = vi.fn(function* () {
+      yield { type: 'finished', value: {} };
+    });
+    // A startup flight that never creates the chat, so the wait is still
+    // running when the abort lands.
+    const config = createFakeConfig(sendMessageStream, undefined, () => false);
+
+    vi.useFakeTimers();
+    try {
+      const pending = drain(
+        livePromptEvents(config, 'hello', controller.signal),
+      );
+      let settled = false;
+      const markSettled = () => {
+        settled = true;
+      };
+      void pending.then(markSettled, markSettled);
+      await vi.advanceTimersByTimeAsync(500);
+      controller.abort();
+      // Poll ticks, not the budget: the abort must release the wait at once.
+      await vi.advanceTimersByTimeAsync(500);
+      expect(settled).toBe(true);
+      await expect(pending).rejects.toThrow();
+    } finally {
+      vi.useRealTimers();
+    }
+
+    expect(sendMessageStream).not.toHaveBeenCalled();
+  });
+
+  it('fails the turn when the startup wait expires on a chat with no tools', async () => {
+    // `startChat()` assigns the chat before the SessionStart hook and
+    // `setTools()`, so a flight still inside that gap — or one that died in
+    // it — leaves a chat that is not ready: a send against it declares zero
+    // tools, silently.
+    const sendMessageStream = vi.fn(function* () {
+      yield { type: 'finished', value: {} };
+    });
+    const config = {
+      ...createFakeConfig(sendMessageStream),
+      initialize: vi.fn(async () => {
+        throw new Error('Config was already initialized');
+      }),
+      getGeminiClient: () => ({
+        sendMessageStream,
+        isInitialized: () => true,
+        getChat: () => ({ getGenerationConfig: () => ({ tools: undefined }) }),
+      }),
+    } as unknown as Config;
+
+    vi.useFakeTimers();
+    try {
+      const pending = drain(livePromptEvents(config, 'hello'));
+      // The wait expires deep inside the virtual-time run, so keep the
+      // rejection handled until the assertion below can claim it.
+      void pending.catch(() => {});
+      await vi.advanceTimersByTimeAsync(STARTUP_CHAT_WAIT_MS + 1_000);
+      await expect(pending).rejects.toThrow(
+        `Timed out after ${STARTUP_CHAT_WAIT_MS}ms`,
+      );
+    } finally {
+      vi.useRealTimers();
+    }
+
+    expect(sendMessageStream).not.toHaveBeenCalled();
+  });
+
   it('uses the ink promptId format and increments promptCount per turn', async () => {
     const sendMessageStream = vi.fn(function* () {});
     const config = createFakeConfig(sendMessageStream);
@@ -516,14 +705,19 @@ describe('livePromptEvents', () => {
 
   it('skips steering when the turn is aborted', async () => {
     const drainSteering = vi.fn(() => ['never']);
-    const sendMessageStream = oneToolBatchStream({
+    const controller = new AbortController();
+    const batch = oneToolBatchStream({
       callId: 't1',
       name: 'test_tool',
       args: {},
     });
+    // Esc reaches the generator mid-turn, not before it: the abort lands on
+    // the tool-response boundary, which is where a real cancel arrives.
+    const sendMessageStream = vi.fn(() => {
+      controller.abort();
+      return batch();
+    });
     const config = createFakeConfig(sendMessageStream);
-    const controller = new AbortController();
-    controller.abort();
 
     await drain(
       livePromptEvents(config, 'start', controller.signal, { drainSteering }),

packages/cli/src/ui/opentui/live-session.ts

@@ -544,6 +544,12 @@ async function resolveSteeredPromptParts(
   return { parts, events, restore: [] };
 }
 
+// How long a turn waits for a startup initialization that is already in
+// flight to create the chat. Bounded so a config that never finishes
+// initializing still reports its own error instead of hanging the prompt.
+export const STARTUP_CHAT_WAIT_MS = 15_000;
+const STARTUP_CHAT_POLL_MS = 100;
+
 /**
  * Sends one user prompt through the real client and yields neutral events.
  * The caller (backend) drains this into the streaming model.
@@ -565,6 +571,39 @@ export async function* livePromptEvents(
     /* already initialized by command loading / startup */
   }
   const client = config.getGeminiClient();
+  // `Config.initialize()` flips its own guard before the work runs, so the
+  // boot-time command-registry load owning that flight makes the call above
+  // throw while `startChat()` has not run yet. Sending then dies in
+  // `getChat()` and the prompt is dropped as "Chat not initialized". The
+  // registry self-heal in commands-dispatch bounds the same window; this
+  // waits it out so the turn starts against a real chat.
+  //
+  // Chat existence alone is not readiness: `startChat()` assigns the chat and
+  // only then awaits the SessionStart hook, its context and `setTools()`, so
+  // releasing on existence sends the session's first prompt with no tool
+  // declarations. `setTools()` is the flight's last stage and always writes
+  // `tools`, which makes its presence the marker that the chat is complete.
+  const chatDeadline = Date.now() + STARTUP_CHAT_WAIT_MS;
+  const chatReady = () =>
+    client.isInitialized() &&
+    client.getChat().getGenerationConfig().tools !== undefined;
+  while (!chatReady() && Date.now() < chatDeadline && !signal?.aborted) {
+    await new Promise((resolve) => setTimeout(resolve, STARTUP_CHAT_POLL_MS));
+  }
+  // An abort before the send must reach runTurn's catch, not the send path:
+  // nothing between here and `sendMessageStream` re-checks the signal for
+  // text-only input, so a cancelled prompt would still fire its
+  // UserPromptSubmit hooks and leave an entry in the session history.
+  signal?.throwIfAborted();
+  // Expiry with a chat assigned but not ready — the flight is still inside,
+  // or died inside, the hook or `setTools()` stage — must not fall through:
+  // the send would answer the whole turn with zero tool declarations and no
+  // error. Gated so the no-chat branch still surfaces the client's own error.
+  if (client.isInitialized() && !chatReady()) {
+    throw new Error(
+      `Timed out after ${STARTUP_CHAT_WAIT_MS}ms waiting for the startup chat to become ready`,
+    );
+  }
   const promptId = options?.promptId ?? nextLivePromptId(config);
   const abort = signal ?? new AbortController().signal;
   // Read per boundary rather than once: the vision bridge can pick a full-turn