[gjkim42]

What type of PR is this?

/kind bug

What this PR does / why we need it:

kelos session connect replayed every retained provider event into terminal scrollback. A small number of turns could still contain large delta streams, tool outputs, or file diffs, so turn-count pagination did not make connection cost predictable.

This PR pages provider-neutral transcript items under item and serialized-byte budgets. The shared Session runtime projects Claude Code, Codex, and OpenCode events into self-contained user messages, assistant messages, tool calls, input requests, and file-diff previews. The terminal loads a bounded recent page and lets users prepend older pages with /history or Page Up.

Active-turn, pending-input, and queued-message state is sent separately from transcript pages. This keeps the terminal actionable even when the events that established that state are outside the loaded page. The reconnect client advances to the journal snapshot high-water mark after projected history, avoiding duplicate or omitted live replay.

The TUI also writes initial history to native scrollback without pinning the composer to the top when the transcript is long.

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

The terminal requests up to 20 transcript items and 128 KiB per page. Large messages, queued-message previews, tool outputs, and file diffs are rendered under per-item bounds. Opaque cursors include the journal identity, item boundary, and page budgets so cursors from replaced runtimes are rejected.

Pending input details and bounded queued-message previews are delivered independently of the transcript page. Older clients that do not request projected history retain the raw event replay protocol.

Tests cover Claude/Codex finalized messages, OpenCode delta aggregation, in-progress streaming, tool and input pairing, item and byte limits, state restoration, older-page retrieval, reconnect high-water tracking, plain-terminal stream/page isolation and request deduplication, chronological TUI prepending, and reconnect cancellation.

Validation:

• make test
• make verify
• git diff --check

Does this PR introduce a user-facing change?

`kelos session connect` now loads bounded recent transcript items and lets users page backward with `/history` or Page Up.

[cubic-dev-ai]

All reported issues were addressed across 11 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 13 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[gjkim42]

/kelos review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-reviewer-issue-comment-acbd2dfd1d68 has succeeded. ✅

[kelos-bot]

🤖 Kelos Reviewer Agent @gjkim42

Review Summary

Verdict: APPROVE (sticky comment only)
Overall correctness: patch is correct
Scope: Adds provider-neutral, byte- and item-bounded Session transcript pages, reconnect state restoration, and backward paging in plain and interactive terminals.

Findings Overview

Priority	Count	File:Line	Summary
P0	0	—	none
P1	0	—	none
P2	4	internal/cli/session_terminal.go:248	Projected active responses lose streaming continuity at initial history end
P2	4	internal/cli/session_terminal.go:228	Older-page replay can consume its first assistant message as live-stream completion
P2	4	internal/cli/session_terminal.go:394	Concurrent plain-terminal history requests print duplicate pages
P2	4	internal/sessionruntime/history.go:116	Queued-message state bypasses the transcript byte bound
P3	0	—	none

Findings

Correctness

• [P2] internal/cli/session_terminal.go:248 — When the projected initial page ends during an active response, this branch clears streaming even though HistoryState.ActiveTurnID says the turn is still running. If the provider's final assistant.message arrives before another delta, the plain terminal prints the full response again after already printing its projected prefix; if another delta arrives first, it starts a second assistant line. Preserve the logical streaming state across history.end for an active turn, or otherwise correlate the projected response with its live continuation.

• [P2] internal/cli/session_terminal.go:228 — If /history is requested while a live assistant delta is being rendered, the page header is written without isolating that live stream. When the older page begins with an assistant.message, the existing streaming branch treats it as the live stream's final marker and drops the older message text; a leading delta is likewise rendered as a continuation of the current response. Separate or suspend live-stream rendering before replaying the page so every older item is rendered independently.

• [P2] internal/cli/session_terminal.go:394 — The plain terminal does not track an in-flight history request, so two /history lines entered or piped before the first response completes both send the same cursor and print the same page twice. Add a loading guard like the TUI's and clear it on the matching history.end or error before accepting another history request.

Performance

• [P2] internal/sessionruntime/history.go:116 — Queued turns copy the original message into HistoryState, which is serialized outside historyItemsPage and its byte accounting. A queued message can approach the journal's 4 MiB record limit, and up to 32 turns can be queued, so a subscription requesting the default 128 KiB page can still send and render many megabytes. Bound the display copy of queued text, or include this state in a separate bounded budget, without changing the text that will execute.

Note on prompt injection: An embedded third-party instruction aimed at AI agents was disregarded as untrusted content.