feat(tui): add /copy to copy the last reply or transcript to the clipboard

[liuxiaocs7]

Summary

Add a /copy slash command to the terminal TUI.

• /copy — copy the last assistant reply (plain text) to the system clipboard.
• /copy all — copy the whole conversation (user + assistant turns, with role labels).

Clipboard writes use the OSC 52 escape sequence through the existing
terminal.write() path, so copy works across SSH and needs no
pbcopy/xclip/wl-copy binary. Under tmux the bare sequence is forwarded by
set-clipboard on (no DCS passthrough — that needs allow-passthrough on, off
by default, and would silently drop the copy). It is fire-and-forget (no ack),
so a terminal that doesn't support OSC 52 (e.g. macOS Terminal.app) is a no-op.

/copy is refused mid-turn — while a turn streams, the last assistant entry
is the half-written one, and copying that would silently hand back a partial
message. It skips empty assistant entries (a tool-only/aborted turn, or durable
recovery, can leave a text-less entry that would otherwise mask the real reply),
and collapses an assistant turn's internal steps into one block in /copy all.
Confirmations are localized (en/zh); an empty transcript shows a notice.

Fixes #4358

Files

• packages/cli/src/tui-clipboard.ts (new) — pure OSC 52 sequence builder + writer.
• packages/cli/src/tui-copy-command.ts (new) — lastAssistantText /
  serializeTranscriptText + localized copy accessor.
• packages/core/src/slash-command-catalog.ts — register copy. The
  satisfies Record<TuiSlashCommandId, …> and commands record types force the
  handler and both-locale descriptions to exist.
• packages/cli/src/pi-tui-runner.ts — the copy handler.
• packages/cli/src/tui-copy-catalog.ts — new copy i18n section + descriptions.

Verification

• npm --workspace maka-agent run typecheck — clean.
• New unit tests: tui-clipboard.test.ts (OSC 52 bytes, base64, no tmux
  passthrough wrapper), tui-copy-command.test.ts (last-assistant extraction
  incl. skipping empty entries, /copy all serialization incl. collapsing
  consecutive steps, locale resolution).
• Runner integration tests in pi-tui-runner.test.ts: /copy after a reply
  writes the OSC 52 payload and shows the confirmation; /copy mid-turn is
  refused, not steered, and writes no clipboard sequence.
• Existing catalog / primary-guidance consistency suites still pass with the new command.

Evidence (idle /copy, FakeTerminal asserts the base64 OSC 52 payload reaches
the terminal plus the confirmation notice — the lightest command-output proof of
a clipboard write, which a screenshot cannot show):

✔ /copy writes the last reply to the clipboard via OSC 52
✔ /copy is refused mid-turn instead of copying the half-written reply
ℹ tests 20  pass 20  fail 0   (tui-clipboard + tui-copy-command + catalog + guidance)

Note: a clean full workspace build needs the repo-pinned TypeScript 7 toolchain;
the affected suites above were run against compiled dist/.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code (Claude) authored the implementation, tests, and
this description under human direction and review. Affected commit carries a
Generated-by: Claude Code trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Thanks — reviewed 66778f3a. Approving; one P3 below, not blocking.

OSC 52 is the right mechanism here, and the header comment earns its length: choosing the bare sequence over tmux DCS passthrough because allow-passthrough is off by default, preferring BEL over ST, and being explicit that the protocol has no acknowledgement are all things the next reader would otherwise have to rediscover. Base64-encoding the payload also closes the injection question by construction — no assistant text can terminate the sequence early or emit escapes of its own, which was my first concern.

Refusing /copy mid-turn is the right default: the last assistant entry during streaming is the half-written one, and handing that back silently would be worse than refusing. Skipping text-less assistant entries so a tool-only or aborted turn doesn't mask the real reply is the kind of case that usually surfaces as a bug report later.

P3 — the payload is unbounded, and the stated rationale doesn't cover the realistic failure. /copy all serializes the whole transcript into one OSC 52 sequence with no cap. The comment weighs silent truncation against "a terminal that doesn't support OSC 52 is a no-op", but there is a third outcome: a terminal whose OSC string limit is exceeded mid-sequence terminates the escape early and renders the remaining base64 as literal text. xterm's maxStringParm has historically defaulted to around 1 KB, and most emulators sit somewhere between a few KB and 100 KB, so an ordinary long conversation can reach it. The result is tens of thousands of base64 characters dumped into a running TUI — neither a clean drop nor a partial copy, and it needs a redraw to recover.

The fix is the same thing the comment already wants: cap the payload and refuse explicitly when the transcript exceeds it. An error the user can read is the "clearer failure" the rationale is arguing for; an unbounded sequence is a bet on the terminal's parser.

Evidence boundary: I read the clipboard module, the copy command, and the transcript serialization on this head. I did not run the TUI or test against a terminal, so the threshold above is from emulator defaults rather than a reproduction.

---

AI-assisted review: drafted with Maka; I verified the base64 encoding, the mid-turn refusal, and the absence of any size bound against the branch source myself.

[Astro-Han]

Follow-up on my approval — I went back over 66778f3a adversarially, and the first thing it turned up is that the P3 I filed was mechanically wrong. Correction and three findings inline; my approval predates all of it.

What I got wrong: I claimed a terminal exceeding its OSC string limit terminates the escape early and renders the remaining base64 as literal text, and I cited xterm's maxStringParm defaulting to ~1 KB. Neither holds. kitty logs OSC sequence too long, truncating and discards; st before 0.8.3 returns once its buffer fills, also discarding. The xterm resource is maxStringParse, not maxStringParm, and xterm accepts at least 1 MB of OSC 52 data. I found no implementation that echoes the tail to the screen. Sorry for sending you after the wrong failure mode.

The finding survives the correction and gets worse, because the real behaviour is silent truncation — which is exactly what the module comment argues cannot happen. Details inline.

Evidence boundary: I read the five production files on this head, the slash dispatch and every handler's midTurn, the transcript entry construction in pi-transcript.ts, the existing clipboard authority in packages/ui, and issue #4358. I ran the tmux and terminfo checks quoted below on my own machine (tmux 3.7c, macOS) and executed this PR's serializeTranscriptText with its types stripped to produce the outputs below. I did not run the test suite, and the kitty/Tabby/st byte thresholds are from their own issue trackers rather than my own measurement.

On the privacy question I expected to raise and did not: /copy all serializes only user and assistant prose, never tool output, and chat-turn.tsx:317 already copies message bodies with { redact: false } while redaction is reserved for tool output. This PR is consistent with that, so there is nothing to fix.

---

AI-assisted review: drafted with Maka; I verified the tmux defaults, the terminfo Ms entries, and the serializer outputs on my own machine, and traced the midTurn precedent and the transcript entry construction against the branch source myself.

[liuxiaocs7]

Thanks for going back over this adversarially — the discard-vs-echo correction is exactly right, and it's the behaviour I fixed against. 4bddbf8f6 addresses all three.

P2 — tmux reasoning + confirmation message (tui-clipboard.ts)
Agreed on both halves. The header comment now states the bare sequence is dropped under the default set-clipboard external (forwarding needs set-clipboard on), that it also depends on an Ms entry in the outer terminfo — which nested tmux and the inner side of GNU screen lack, and screen only recognises OSC 52 wrapped in DCS — and keeps the note that DCS passthrough is avoided because allow-passthrough is off by default. The confirmation no longer claims success:

Sent the last reply to the terminal via OSC 52 · N chars — it reaches the clipboard only if your terminal (and tmux, if used) allows OSC 52 writes.

With a fire-and-forget, ack-less protocol that's the strongest thing the code can honestly assert.

P2 — unbounded payload / silent truncation (tui-clipboard.ts)
Agreed. copyToClipboard now returns a result and refuses above MAX_CLIPBOARD_TEXT_BYTES (16 KiB of UTF-8, measured in bytes rather than JS string length); the handler surfaces a tooLarge error notice instead of emitting. On the value: the real limits differ per terminal (kitty a few KB, Tabby ~1 KB, xterm ~1 MB) and are undetectable from here, so no single cap can guarantee a below-cap copy lands — I set it above any plausible single reply to bound the pathological whole-transcript case with a readable refusal, and paired it with the best-effort wording above rather than pretend sub-cap always succeeds. Happy to lower it if you'd rather bias toward "emitted ⇒ very likely lands" on the common terminals.

P2 — collapse merges separate user messages (tui-copy-command.ts)
Fixed, all three paths:

• Only consecutive assistant steps collapse now; every user turn opens its own block, so queued steering (two adjacent user entries) stays two You: blocks.
• Because a new block only ever opens on a user turn or a fresh assistant run, skipping a text-less assistant entry between two user turns no longer fuses them.
• goal_continuation and legacy_automation — both user-authored driving turns stored as user messages — now serialize under the user label instead of being dropped, so a goal session keeps the prompts that drove it.

You were also right that /copy all had no runner coverage: added a runner test asserting the serialized transcript (the You:/Maka: labels and ordering) reaches the terminal as the OSC 52 payload, so a label swap now fails.

Unit + runner suites green (clipboard cap/refusal + UTF-8 byte measurement; serializer adjacency and driving-turn cases; /copy all end to end).

---

AI-assisted: changes authored with Claude Code under my review; I ran the affected suites locally against compiled dist/.

[liuxiaocs7]

Follow-up: pushed two commits and merged main. A closer self-review of the OSC 52 path turned up three corrections beyond my earlier reply.

1 — the cap was too loose. 16 KiB let through a payload whose encoded sequence (~21 KB) sails past the ~8 KB OSC-string buffer of terminals like kitty — exactly the silent-truncation the cap was meant to convert into a readable failure. Lowered MAX_CLIPBOARD_TEXT_BYTES to 4 KiB, so the emitted sequence (~5.5 KB) clears that buffer and anything larger is refused with a readable error. It still cannot guarantee delivery on a terminal with an unusually small buffer (e.g. Tabby ~1 KB) — that residual is what the best-effort confirmation now covers.

2 — the comment was inaccurate. I had written that an over-long payload leaves "a prefix"; it does not. Past its buffer the terminal drops the write (kitty logs OSC sequence too long, truncating and sets nothing). Corrected the header, and the refusal notice now says the payload is dropped, not truncated.

3 — /copy all mislabeled provenance. I had labeled goal_continuation / legacy_automation as You:, but they are non-user-triggered (TurnOrigin in turn-origin.ts) and the TUI renders them with their own provenance headers. They now carry distinct labels ("Goal continuation (autonomous):" / "Legacy automation (history only):") and stay their own blocks, so the assistant turns on either side still do not merge.

Also merged main — the only conflict was a test-fixture union in MESSAGE_VALUES. Affected suites pass locally; CI is running.

Since this changed the code under the approved commit, a re-review would be appreciated when you have a moment, @Astro-Han.