[OrcaWin]

	Files	Added	Deleted	Net
Test	17	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​2235	$\color{#cf222e}{\Huge{\mathbf{−}}}$​31	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​2204
Prod	36	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​927	$\color{#cf222e}{\Huge{\mathbf{−}}}$​125	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​802

	Files	Added	Deleted	Net
Test	16	$

ELI5

When the network to a remote machine dies silently, Orca takes about 20 seconds to notice. Keys typed in that window went into a dead connection and were lost. Keys still waiting to be sent when Orca noticed were thrown away, so half a command reached the shell and got glued onto the next one. And keys held during "Reconnecting…" were deleted after about 3 minutes, even though the terminal later came back.

Now every key typed into a remote terminal is numbered. The remote host writes the numbers strictly in order and says which number it has reached. Orca keeps everything the host has not confirmed and sends it again from that point whenever the host asks, the connection is replaced, or confirmations stop arriving. The host skips anything it already wrote. Keys arrive once, in order, whole.

What Changed

Before (real SSH host, 65 s network black hole, one token every 0.5 s): 42 of 200 typed lines lost. 200 s black hole, one token every 2 s: 103 of 120 lost.

After (same runs on this head): 200/200 and 120/120, with no duplicates, no reordering and no split lines.

Mechanism: standard go-back-N

The pane and host negotiate an inputAck capability. A host that does not offer it gets today's unsequenced input, and the pane never resends to it.

Host (per PTY + pane input session; the ledger belongs to one host runtime):

• It keeps one number, appliedSeq: the highest sequence whose write was confirmed. Sequenced input uses the provider's settled write, so for an SSH-backed PTY "confirmed" means the provider took the bytes, not merely queued them.
• Frames are handled one at a time, in arrival order, from any connection:
  • seq ≤ appliedSeq: a duplicate. It is re-acked and not written.
  • seq = appliedSeq + 1: it is written. If the write is confirmed, appliedSeq advances and the host acks it.
  • Write refused, or seq beyond the next number (a gap): nothing is written, appliedSeq stays put, and the host sends a resend request carrying appliedSeq on that stream.
• No state blocks later input. Every stream of a session is treated the same.
• A settlement that proves no byte left the host counts as a refusal and is resent. A write that may have reached the terminal (the handoff was lost or the provider threw) is never resent, because a resent command could run twice. The host advances past it and acks it as "delivery unknown", and the pane reports that write as failed.
• The ledger has an id. A runtime restart gets a new ledger and a new id, so the pane never replays into a ledger that has no record of what it applied.

Pane (remote-runtime-input-journal.ts, which replaces the old journal and the resend scheduler):

• It keeps every unacked input in order, and every host ack is cumulative.
• It resends everything after appliedSeq, in order, in three cases: a resend request (backoff from 100 ms up to 8 s), a new stream, or no ack progress for 5 s.
• A refusal never remounts the pane. Remounts happen only when the endpoint is really lost.
• Input that must not run is resent as an empty slot, so the host can move past it. That covers a withdrawn paste or drop, a stale query reply, and bytes past the 1 MiB retention budget (after a budget gap nothing later is replayed).
• Cancelling a paste or drop withdraws only that operation's own sequences. Typing still in the 8 ms debounce goes out first as its own sequences, so it cannot be cancelled with the paste.
• Accepted writes (Ctrl+C, Escape, pastes) resolve from the host ack.
• Recovery hold: a release cut short by another outage now pauses and keeps the rest for the next release. Before, it dropped the rest. After an accepted write that a sequenced stream withdrew or could not confirm, the hold keeps delivering the typing queued behind it.

Kept from earlier rounds: capability negotiation, the ledger id, holding input under "disconnected" past the auto-recovery window, merging held keystrokes, and withdrawing a held or journaled paste when its caller's timeout (120 s per chunk) or a file drop's (30 s) fires.

The invariant, and how it is proven

The PTY receives exactly the input the pane did not withdraw, each byte once and in order. A withdrawn paste contributes nothing unless its bytes had already reached the host, and nothing typed before it is lost. Once the link is healthy everything settles, and no resends continue.

tests/e2e/remote-terminal-input-delivery-model.unit.test.ts is a seeded, deterministic, model-based test. It drives the real pane transport, multiplexer and journal against the real host RPC dispatcher and ledger, over an in-process link that injects faults. It runs 2,000 random schedules of 60 steps in about 12 s. The schedules mix the following:

• typing, Ctrl+C, small and chunked (16–40 KiB) pastes, and withdrawn pastes
• lost or buffered frames in either direction, and lost acks on a healthy connection
• dead connections whose buffered input reaches the host late
• connection replacement, an unreachable host, and host runtime restarts with the PTY surviving
• refused writes, settlements that prove no byte left, and lost settlements whose bytes either landed or did not; thrown writes

One run covered 66,809 inputs, 1,745 withdrawals (1,348 of them before any byte reached the host), 1,589 runtime restarts, 10,318 disconnects, 2,117 late deliveries from dead connections, and 6,477 refused plus 3,353 unhanded writes. The test was also run against 20,000 schedules (1.2 M steps) during development.

A rerun with each fix reverted fails, for these fixes:

• typing batched into the paste's sequence
• the host advancing past a refusal
• no stall resend
• the hold dropping input after a cut-short release

Wire compatibility (docs: remote wire compatibility)

• inputAck and inputSessionId are optional subscribe fields. The sequence number travels in the existing frame header.
• InputAck (opcode 18) is sent only to clients that negotiated it. Its seq is the host's cumulative appliedSeq. An optional flag byte means "delivery unknown" (1) or "resend everything after seq" (2).
• The opcode and the flag are new in this PR, so no released client or host uses a different meaning.
• Old host with a new pane: unsequenced input, and no resend. New host with an old pane: no change.

Why

• Holding keys only after detection cannot cover the roughly 20 s before it. Those bytes sit in the dead socket and the SSH buffers, and only the host knows whether they arrived. A cumulative ack plus host-side dedup is the only way to resend them without running a command twice.
• Why go-back-N. Three review rounds kept finding new P1s in a hand-built "block after a refusal" design. Each fix added carrier, epoch and blocked-state bookkeeping, and each addition created a new way to strand input. Two examples: a replacement stream stayed blocked behind an old stream's refusal, and one transient refusal silently dropped everything typed after it. Go-back-N is the textbook reliable-delivery protocol. The receiver keeps one number and the sender keeps one ordered buffer, and there is nothing to unblock: any lost frame, lost ack, refusal or stream swap ends in "resend from N". That is why it can be proven by exhaustive random testing. It also deletes code: this round removes 122 net production lines.
• Alternatives considered:
  • Selective repeat: more state for no benefit, since terminal input is small and ordered.
  • Shorter detection: it only narrows the window.
  • Replay without dedup: it types commands twice when the old SSH channel survives.
  • Resending writes whose delivery is unknown: it runs commands twice.

Linked Issue

Phase 3.7 network findings P1-1, P1-2 and P1-3 (adversarial real-host test), plus review-round findings 1–3. There is no separate GitHub issue.

Visual Proof

N/A. This is a behavior fix with no visual change except the banner text. The real-host evidence is below.

Testing

• I manually tested these changes locally
• Automated tests added/updated, or explained why not below

Real host on this head's production code. Setup:

• Docker SSH fixture with iptables, a managed orcad host, and a packaged arm64 build.
• An isolated HOME and profile, ORCA_BACKGROUND_LAUNCH=1, with tokens unset.
• Typing through CDP into a remote pane running a timestamped read loop.

Run	Base	This PR
65 s black hole, 200 tokens every 0.5 s (the SSH connection was replaced)	lost 42	200/200: 0 lost, 0 dup, 0 reordered, 0 mangled
200 s black hole, past the 181 s window ("Remote runtime disconnected" shown), 120 tokens every 2 s	lost 103	120/120: 0 lost, 0 dup, 0 reordered, 0 mangled
Forced orcad update applied 1 s before a 40 s drop, 300 tokens every 0.5 s	UD: lost 50, 1 mangled line	300/300: 0 lost, 0 dup, 0 reordered, 0 mangled
Forced orcad update started 1 s into a 40 s drop; the update applied during the outage, 300 tokens every 0.5 s	—	263/300: lost 37 (#33–69, typed into the dead socket before detection), 0 dup, 0 reordered, 0 mangled

The last row is the documented limit. The runtime restarted while those 37 keys were unconfirmed, so the pane cannot tell whether the old runtime wrote them, and it drops them rather than risk running them twice. Keys typed after detection were held and all arrived.

Unit and integration tests. Each one ports a finding from rounds 1–3 or covers the new design:

• terminal-input-sequence-ledger.test.ts:
  • in-order serial writes, with duplicates settled after the original
  • a refusal resent on the same stream while later typing keeps flowing
  • a replacement stream whose replay raced a refusal is written, not stranded
  • a late dead-connection frame after a gap is never written early
  • delivery-unknown advances and is never retried
  • sessions scoped per PTY, LRU eviction, and a distinct ledger id per runtime
• terminal-multiplex-input-sequence-replay.test.ts:
  • exactly-once across a dead connection and its replacement
  • a refusal sends a resend request, not WriteUnavailable
  • writes are settled, and an unverifiable handoff is acked as delivery-unknown
  • an unhanded settlement is resent
  • legacy clients stay unsequenced
• remote-runtime-input-journal.test.ts:
  • resend fills withdrawn slots and query-reply slots
  • backoff, the stall resend, and delivery-unknown handling
  • no replay across a ledger or endpoint change, or past a budget gap
  • a failed send is resent on the next stream
• remote-runtime-pty-transport-input-replay.test.ts:
  • P1-1, P1-2, P1-3, Ctrl+C order, and the validating paste
  • no replay into a restarted runtime
  • a held or journaled paste is withdrawn on timeout
  • typing before a timed-out paste is kept
  • a refusal is resent without a remount, even after many refusals
  • chunk 1 and chunk 2 send failures keep earlier typing
• remote-runtime-recovery-input-hold.test.ts: a release cut short by an outage resumes, and typing continues after a withdrawn or unconfirmed accepted write.
• paired-runtime-rejected-input-remount.unit.test.ts: the end-to-end remount on a refusal now runs on a stream that did not negotiate inputAck, which is the only kind that still remounts.

Checks:

• pnpm tc, oxlint, pnpm run check:code-quality:changed and pnpm run audit:anti-slop are clean.
• These pass: src/renderer/src/components/terminal-pane, src/renderer/src/runtime, src/main/runtime/rpc, the tests/e2e unit tests, and the cross-version terminal wire suite.

Platforms: macOS desktop against a Linux SSH host. No platform-specific code.

Review

Agent skill upstream boundary

• Not applicable, or this change copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

• SSH: this is the SSH and remote path. The execution boundary is unchanged, and no live/unverifiable/exited verdict changes. A settlement that may have written is treated as unverifiable, never as a refusal.
• Mobile: mobile clients never advertise inputAck.
• Folder workspaces: not affected.
• Known limits:
  • A host runtime restart during an outage drops unconfirmed input instead of replaying it (see the last real-host row).
  • More than 1 MiB of unconfirmed input in one outage replays nothing past the gap.
  • A write whose delivery is unknown is reported as failed and never resent.
  • A pane remounted mid-outage starts a new input session.
• Only the retryingBody text changed in the copy (French fixed too).

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)