Inline images duplicate every transcript row below them into native scrollback on --resume

[turygo]

Summary

Any inline image in the transcript causes every row below it to be painted twice into the terminal's native scrollback when the session is re-rendered (omp --resume).

The renderer first paints the whole transcript with a text placeholder ( [Image: image/webp]) and commits the tail to native scrollback. Only afterwards does it transmit the real image over the Kitty graphics protocol and repaint everything from the image position downward. The first copy is already in native scrollback and cannot be erased, so the user sees the tool blocks, the todo card and the entire final assistant message a second time.

Environment

• omp 17.1.5 (installed via bun global, dist/cli.js)
• macOS 25.5.0, arm64 (Apple M3 Pro)
• Ghostty 1.3.2 — but the repro below runs in a raw pty.fork() with TERM=xterm-256color, replayed through pyte, so it is not Ghostty-specific; it needs only the Kitty graphics path to be taken.
• terminal.showImages at its default (true).

Reproduction

Fully self-contained, no private data. ~30 s, one cheap model call.

mkdir -p /tmp/omp-imgdup && cd /tmp/omp-imgdup

# 1. an image big enough that encoding is deferred (a 320x200 PNG is NOT enough)
python3 - <<'PY'
import random, struct, zlib
random.seed(1); w, h = 1080, 1920
raw = b"".join(b"\x00" + bytes(random.getrandbits(8) for _ in range(w*3)) for _ in range(h))
def chunk(t, d):
    c = t + d
    return struct.pack(">I", len(d)) + c + struct.pack(">I", zlib.crc32(c) & 0xffffffff)
open("shot.png", "wb").write(
    b"\x89PNG\r\n\x1a\n"
    + chunk(b"IHDR", struct.pack(">IIBBBBB", w, h, 8, 2, 0, 0, 0))
    + chunk(b"IDAT", zlib.compress(raw, 6))
    + chunk(b"IEND", b""))
PY

# 2. build a session: read the image, then emit 40 lines of text below it
omp -p --model anthropic/claude-haiku-4.5 --no-title --no-skills --no-rules \
    --auto-approve --session-dir ./sess \
    "Use the read tool on ./shot.png, then in your final reply print a numbered list from 1 to 40, each line exactly 'line NN: alpha bravo charlie delta echo'. Use no other tool."

# 3. re-render it in a terminal shorter than the transcript
omp --resume ./sess/*.jsonl --no-title --no-tools

Scroll up: line 01 … line 40 each appear twice.

Scripted check (raw PTY 100x30, replayed through pyte.HistoryScreen):

total rendered rows: 58619
'line NN: alpha bravo charlie delta echo' rows: 40 distinct, every one counted exactly 2x

Observed vs expected

	rendered rows	line 40 occurrences
default	58619	2
--config with terminal: {showImages: false}	1087	1

Expected: one copy.

Root cause evidence

Byte offsets in the raw PTY stream of a real --resume (176x58) of a session whose only image sits 148 rows before the end:

 214866   ' [Image: image/webp]' placeholder painted
 245493   last paragraph of the final assistant message — 1st copy
          (already committed to native scrollback)
 247812   first Kitty graphics escape \x1b_G  (195 chunks follow)
1076889   last paragraph of the final assistant message — 2nd copy

The duplicated span is exactly the 148 rows that follow the image placeholder: the Read <file> tool block, a bash tool block, the Todo card, and the whole final assistant message. Deterministic — reproduced on every run, at 100x30 and 176x58.

The session .jsonl itself is clean (each paragraph stored once), and the same transcript with the image record removed renders once at 80x24 / 120x30 / 160x45 / 176x58 / 200x50. The image is the only trigger.

Related but distinct: #5766 (stale Kitty graphics when disabling inline images).

Workaround

# ~/.omp/agent/config.yml
terminal:
  showImages: false

Suggested fix direction

The transcript is committed to native scrollback before the image payload is resolved, so the post-image repaint has nothing it can legally rewrite. Either hold the commit boundary above the first unresolved image until its payload is ready, or reserve the placeholder's final row count up front so the later paint is an in-place update rather than a re-emit.

Not verified

• Whether the same duplication occurs during a live turn (image tool result arriving mid-stream, text streaming below it). My live repro attempts hit provider 403s; only the --resume path is confirmed.
• Non-Kitty image protocols (iTerm2, sixel) were not tested.

[roboomp]

The byte ordering and resulting duplicate lower transcript are technically credible. We are not going to change this in the renderer by default, though: omp’s normal-screen TUI intentionally treats rows already committed to native scrollback as immutable (packages/tui/src/tui.ts:4-16, :190-207). If content below an unresolved graphic is later repainted after it crossed that boundary, the renderer can only recommit it (duplicate) or suppress the newer rows (lose content); the committed-prefix recovery explicitly chooses “duplication, never loss” (packages/tui/src/tui.ts:3254-3260). Holding the entire suffix above every unresolved image would trade this artifact for withheld/clipped transcript output, while switching to the alternate screen would remove the user-owned native scrollback this mode is designed to preserve. terminal.showImages: false remains the deterministic option when scrollback fidelity matters more than inline graphics. Evidence that would change this assessment: a reproduction where semantic rows duplicate before any copy has entered native scrollback, or a documented contract promising byte-exact native scrollback across asynchronous image replacement. Final disposition is up to the maintainer.

[turygo]

Ran the experiment your first bullet asks for. It does not exist — your model is correct. Same session, same 100-column PTY, only the row count varies; Kitty graphics escapes stripped from the stream before replay so the image occupies cells rather than printing its payload as text:

viewport rows	rows pushed to native scrollback	duplicated line NN rows
30	56	13
60	11 (all above the image)	0
90	0	0
200	0	0
400	0	0

Duplication is strictly bounded to rows that had already crossed the commit boundary, and only rows below the image. Nothing duplicates inside the live frame. rows=30 is deterministic across repeats. So the "duplication, never loss" recovery is behaving exactly as designed, and I'm not disputing the wontfix for the streaming case.

One narrower point, only about the --resume replay path:

There the second paint looks gratuitous rather than forced. The image bytes are already on local disk in the session blob store before the first row is painted — nothing is being awaited from a model or a network. The renderer still paints [Image: image/webp], walks the whole transcript past the commit boundary, and only then resolves the graphic and repaints the suffix. If replay resolved image payloads (or at least their final row count) before the first paint, there would be no post-commit repaint to reconcile: no duplication, no withheld suffix, and the scrollback-immutability invariant in tui.ts stays untouched. That is a narrower fix than "hold the entire suffix above every unresolved image", and it does not affect the live path at all.

I can't verify the cost of that from the published bundle — whether decode/encode is cheap enough to sit on the first-paint path is your call, and it is the only thing I'd be guessing at.

Two corrections to my original report while I'm here:

• The trigger is not the Kitty escape specifically. The runs above emitted zero \x1b_G and used the Unicode-placeholder path instead (U+10EEEE + diacritic cells), and still duplicated at rows=30. It is the two-phase image resolution, whichever transport carries it.
• Image size matters for reproduction: a 320x200 PNG resolves synchronously and never duplicates. The 1080x1920 image in the repro script is what pushes resolution past the first paint.

[roboomp]

Confirmed the narrower --resume behavior on the current worktree with a synthetic local session containing a 1.74 MB WebP and the 40 marker lines. In a 100×30 PTY, the raw stream emitted every marker twice and replay put line 01–line 13 into scrollback twice; in a 100×60 PTY, the stream still emitted every marker twice but the terminal buffer contained each once because the repaint remained inside the live frame. This matches your boundary result and isolates the second pass from the immutable-scrollback recovery itself. The source path also matches the proposed explanation: ToolExecutionComponent.updateResult() starts WebP→PNG conversion asynchronously (packages/coding-agent/src/modes/components/tool-execution.ts:591-633), the first Kitty render skips the still-unconverted non-PNG block (:1217-1225), and conversion completion requests another render. I recorded the reproduction. Pre-resolving those already-local replay images is a distinct startup optimization, but the issue remains under the current wontfix disposition unless a maintainer authorizes that narrower change.