feat(gemini): support --resume flag and fix stuck session on abort

[junmo-kim]

Summary

• Add --resume <geminiSessionId> support for resuming previous Gemini sessions in remote mode
• Replay historical messages from local transcript on resume
• Prevent duplicate history replay when switching local→remote mode
• Fall back to new session when loadSession fails on resume
• Fix stuck session bug: cancelPrompt() now properly unblocks backend.prompt() via AbortSignal

Bug Fix: Stuck Session on Abort

Previously, cancelPrompt() only sent a session/cancel notification to the Gemini CLI ACP backend. If the backend did not respond to the cancel, backend.prompt() would hang indefinitely (timeoutMs: Infinity), blocking the main message loop from processing any further user input — leaving the HAPI session permanently unresponsive.

Root cause: AcpStdioTransport.sendRequest() had no cancellation mechanism.

Fix: Added AbortSignal support through the ACP stack:

• AcpStdioTransport.sendRequest() accepts an optional AbortSignal
• AcpSdkBackend.prompt() accepts and forwards the signal
• geminiRemoteLauncher passes the session abort controller signal to prompt()

Test plan

• Start a Gemini session via HAPI and send a message
• While Gemini is processing, click abort — session should recover and accept new messages
• Resume a previous Gemini session: historical messages appear in UI
• Switch local→remote: history not replayed twice
• loadSession failure: session starts fresh without error
• Unit tests: bun vitest run src/agent/backends/acp/

🤖 Generated with Claude Code

[github-actions]

Findings

• None.

Summary

• Review mode: initial
• No issues found in the diff. Residual risks: resume behavior still depends on Gemini CLI semantics and session-id discovery paths outside the covered unit test.

Testing

• Not run (automation)

[github-actions]

Findings

• [Major] Remote resume no fallback. loadSession error now aborts remote launch; expected behavior is new session on invalid/expired session id. Evidence cli/src/gemini/geminiRemoteLauncher.ts:71-74
  Suggested fix:

  let acpSessionId: string;
  if (session.sessionId) {
      try {
          acpSessionId = await backend.loadSession({ ...sessionConfig, sessionId: session.sessionId });
      } catch (error) {
          logger.warn('[gemini-remote] resume failed, starting new session', error);
          session.sendSessionEvent({ type: 'message', message: 'Gemini resume failed; starting a new session.' });
          acpSessionId = await backend.newSession(sessionConfig);
      }
  } else {
      acpSessionId = await backend.newSession(sessionConfig);
  }

Summary
Review mode: initial. 1 major issue.

Testing
Not run (automation)

[github-actions]

[MAJOR] Remote resume has no fallback. If session.sessionId is invalid/expired, loadSession throws and the remote loop aborts. Expected behavior: start a new session (similar to opencodeRemoteLauncher). Evidence cli/src/gemini/geminiRemoteLauncher.ts:71-74.

Suggested fix:

let acpSessionId: string;
if (session.sessionId) {
    try {
        acpSessionId = await backend.loadSession({ ...sessionConfig, sessionId: session.sessionId });
    } catch (error) {
        logger.warn('[gemini-remote] resume failed, starting new session', error);
        session.sendSessionEvent({ type: 'message', message: 'Gemini resume failed; starting a new session.' });
        acpSessionId = await backend.newSession(sessionConfig);
    }
} else {
    acpSessionId = await backend.newSession(sessionConfig);
}

[junmo-kim]

Fixed: loadSession is wrapped in try/catch that falls back to newSession. See lines 79-89.

[github-actions]

Findings

• None.

Summary

• Review mode: initial. No issues found in modified lines. Residual risk: tests not run here.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

Findings

• None.

Summary

• Review mode: follow-up after new commits. No issues found in modified lines. Residual risk: tests not run here.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

Findings

• [Major] Transcript replay re-emits history to hub, duplicating messages on resume; hub already persisted history. Evidence cli/src/gemini/geminiRemoteLauncher.ts:214.
  Suggested fix:

  if (text) {
      this.messageBuffer.addMessage(text, 'user');
  }
  // ...
  if (message.type === 'gemini' && typeof message.content === 'string' && message.content) {
      this.messageBuffer.addMessage(message.content, 'assistant');
  }

Summary
Review mode: follow-up after new commits. 1 major issue: resume replay duplicates messages in hub/UI.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

[MAJOR] History replay re-emits transcript messages to the hub, which will duplicate existing history on resume. Evidence cli/src/gemini/geminiRemoteLauncher.ts:214.
Suggested fix:

if (text) {
    this.messageBuffer.addMessage(text, 'user');
}
// ...
if (message.type === 'gemini' && typeof message.content === 'string' && message.content) {
    this.messageBuffer.addMessage(message.content, 'assistant');
}

[junmo-kim]

Not a real duplication: when HAPI creates a new resume session, the hub DB for that session is empty. The web client calls getMessages() on connect and gets nothing. sendUserMessage/sendCodexMessage fill it for the first time — no duplicates.

[github-actions]

Findings

• [Major] Resume history replay re-emits transcript messages to the hub, which will duplicate already persisted history on resume — evidence cli/src/gemini/geminiRemoteLauncher.ts:215.
  Suggested fix:

  if (text) {
      this.messageBuffer.addMessage(text, 'user');
  }
  // ...
  } else if (message.type === 'gemini' && typeof message.content === 'string' && message.content) {
      this.messageBuffer.addMessage(message.content, 'assistant');
  }

Summary
Review mode: follow-up after new commits. 1 major issue: resume history replay duplicates persisted messages in hub/UI.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

Findings

• None.

Summary
Review mode: follow-up after new commits. No issues found in modified lines. Testing gap: not run (automation).

Testing

• Not run (automation)

HAPI Bot

[github-actions]

Findings

• [Major] Resume history only written to local message buffer; remote/web clients (headless runner) see no replay, so --resume history feature missing in primary UI. Evidence cli/src/gemini/geminiRemoteLauncher.ts:201
  Suggested fix:

  import { randomUUID } from 'node:crypto';
  
  if (message.type === 'user') {
      const text = extractMessageText(message.content);
      if (text) {
          this.session.sendUserMessage(text);
          this.messageBuffer.addMessage(text, 'user');
      }
  } else if (message.type === 'gemini' && typeof message.content === 'string' && message.content) {
      this.session.sendCodexMessage({ type: 'message', message: message.content, id: randomUUID() });
      this.messageBuffer.addMessage(message.content, 'assistant');
  }

Summary
Review mode: follow-up after new commits. 1 major issue. Testing gap: not run (automation).

Testing
Not run (automation)

HAPI Bot

[github-actions]

[MAJOR] Resume history replay only updates local messageBuffer; remote/web clients (no TTY) see no history, so resume UX missing. Evidence cli/src/gemini/geminiRemoteLauncher.ts:201.

Suggested fix:

import { randomUUID } from 'node:crypto';

if (message.type === 'user') {
    const text = extractMessageText(message.content);
    if (text) {
        this.session.sendUserMessage(text);
        this.messageBuffer.addMessage(text, 'user');
    }
} else if (message.type === 'gemini' && typeof message.content === 'string' && message.content) {
    this.session.sendCodexMessage({ type: 'message', message: message.content, id: randomUUID() });
    this.messageBuffer.addMessage(message.content, 'assistant');
}

[junmo-kim]

Fixed in the current code — both sendUserMessage() and sendCodexMessage() are called during replay. Web clients receive history via hub.

[github-actions]

Review mode: follow-up after new commits. 1 major issue. Testing gap: not run (automation).

[github-actions]

[MAJOR] User abort now throws AbortError from backend.prompt() and is treated as a hard failure, so every abort shows "Gemini prompt failed" plus an extra status line. This is new with the abort signal wiring and makes normal aborts look like errors. Evidence cli/src/gemini/geminiRemoteLauncher.ts:138.

Suggested fix:

            } catch (error) {
                const isAbort = error instanceof DOMException && error.name === 'AbortError';
                if (!isAbort) {
                    logger.warn('[gemini-remote] prompt failed', error);
                    session.sendSessionEvent({
                        type: 'message',
                        message: 'Gemini prompt failed. Check logs for details.'
                    });
                    messageBuffer.addMessage('Gemini prompt failed', 'status');
                }
            } finally {

[junmo-kim]

Fixed in commit 6ee6eee — catch block now checks isAbortError() and silently ignores expected aborts without showing the error message.

[github-actions]

Review mode: follow-up after new commits
Major: Resume fallback replays history after starting a new ACP session; UI can imply model context that isn't loaded (see inline).
Minor: signal.aborted check happens after timer setup, leaving an unnecessary timer running when already aborted (see inline).
Testing: Not run (automation)

[github-actions]

[MAJOR] Resume fallback replays history against a fresh ACP session

When session/load fails you create a new session but still set resumedFromSessionId, so replayHistoricalMessages runs even though ACP is now on a fresh context. That can make the UI show prior context the model does not have.

Suggested fix:

} catch (error) {
    logger.warn('[gemini-remote] resume failed, starting new session', error);
    session.sendSessionEvent({ type: 'message', message: 'Gemini resume failed; starting a new session.' });
    acpSessionId = await backend.newSession(sessionConfig);
    resumedFromSessionId = null;
}

[junmo-kim]

Valid point — fixed in commit f3264ad. On loadSession failure, resumedFromSessionId stays null so history replay is skipped. The previous comment in the code was incorrect.

[github-actions]

[MINOR] signal.aborted check after timer setup leaves a pending timer

If the signal is already aborted, the timeout timer is still scheduled and left to fire later. Move the aborted check before creating the timer, or clear the timer before returning.

Suggested fix:

if (signal?.aborted) {
    reject(new DOMException('ACP request aborted', 'AbortError'));
    return;
}

if (Number.isFinite(timeoutMs)) {
    // existing timer setup
}

[junmo-kim]

Fixed in commit f3264ad — cleanup() is now called before rejecting on a pre-aborted signal, which clears the pending timer.

[github-actions]

Findings

• [Major] Local resume sets without backfilling, so switching local→remote after skips history replay. Evidence .
  Suggested fix:

Summary
Review mode: follow-up after new commits. 1 major issue. Testing not run (automation).

Testing
Not run (automation)

HAPI Bot

[github-actions]

[MAJOR] in local mode prevents resume history from reaching the hub when you later switch to remote (local scanner only streams new transcript entries). Evidence .

Suggested fix:

[junmo-kim]

Duplicate of the comment below — same root cause. Fixed in commit e02a7da.

[github-actions]

Review mode: follow-up after new commits. 2 issues.

Testing: Not run (automation).

HAPI Bot

[github-actions]

[MAJOR] content now allows array form, but local transcript handler only forwards user messages when content is a string. When transcripts use the array format, user messages never reach the hub (remote UI misses user history). Evidence cli/src/gemini/geminiRemoteLauncher.ts:274.

Suggested fix:

const text = extractMessageText(message.content);
if (message.type === 'user' && text) {
    session.sendUserMessage(text);
    return;
}

[junmo-kim]

Valid point. Fixed in commit e02a7da: extracted extractMessageText to sessionScanner.ts (shared between both launchers) and updated handleTranscriptMessage in geminiLocalLauncher.ts to use it, so array-form content is now handled correctly.

[github-actions]

[MAJOR] historyReplayed set here blocks remote history replay on local→remote switch, even when local started with --resume. The local scanner primes transcript and does not emit existing messages, so pre-existing history never reaches the hub. Evidence cli/src/gemini/utils/sessionScanner.ts:144 and cli/src/gemini/geminiRemoteLauncher.ts:94.

Suggested fix:

// after creating scanner
const transcript = await readGeminiTranscript(transcriptPath);
session.historyReplayCutoff = transcript?.messages?.length ?? 0;
session.historyReplayed = session.historyReplayCutoff === 0;

// in replayHistoricalMessages
const cutoff = this.session.historyReplayCutoff ?? messages.length;
for (let i = 0; i < Math.min(messages.length, cutoff); i += 1) {
    const message = messages[i];
    // existing replay logic
}
this.session.historyReplayed = true;

[junmo-kim]

Valid point. Fixed in commit e02a7da: added historyReplayCutoff to GeminiSession. When the local scanner starts, it reads the existing transcript length and sets historyReplayCutoff = N (and keeps historyReplayed = false when N > 0). On local→remote switch, replayHistoricalMessages replays only messages[0..N] — exactly the ones the scanner primed/skipped — so the hub receives the full history without duplicating messages the scanner already forwarded.

[github-actions]

Findings

• [Minor] History replay cutoff set for every local launch, even when transcript already synced from remote mode; next remote switch can replay duplicates. Evidence cli/src/gemini/geminiLocalLauncher.ts:76
  Suggested fix:

  if (!session.historyReplayed) {
      if (session.startingMode === 'remote') {
          session.historyReplayCutoff = 0;
          session.historyReplayed = true;
      } else {
          session.historyReplayCutoff = existingCount;
          session.historyReplayed = existingCount == 0;
      }
  }

Summary
Review mode: follow-up after new commits. 1 issue. Duplicate history replay risk on remote→local→remote switches.

Testing

• Not run (automation)

[github-actions]

[MINOR] History replay cutoff always derived from existing transcript, even when those messages were already synced during remote mode. This can replay duplicates on the next remote switch.

Suggested fix:

if (!session.historyReplayed) {
    if (session.startingMode === 'remote') {
        session.historyReplayCutoff = 0;
        session.historyReplayed = true;
    } else {
        session.historyReplayCutoff = existingCount;
        session.historyReplayed = existingCount == 0;
    }
}

[junmo-kim]

Valid point. Fixed in commit 1061603: wrapped the cutoff assignment in \!session.historyReplayed guard. If startingMode === 'remote', we set historyReplayCutoff = 0 and historyReplayed = true so a subsequent remote switch skips replay entirely. If startingMode === 'local', the existing cutoff logic is unchanged.

[github-actions]

Findings

• None.

Summary

• Review mode: follow-up after new commits. No issues found in modified lines. Residual risks: resume/history behavior depends on transcript availability and manual end-to-end testing; abort/cancel coverage only unit tests.

Testing

• Not run (automation)

HAPI Bot