[OrcaWin]

	Files	Added	Deleted	Net
Test	3	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​338	0	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​338
Prod	6	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​94	$\color{#cf222e}{\Huge{\mathbf{−}}}$​11	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​83

ELI5

Opening a very big folder (about 80,000 files) on a remote host used to break the whole connection to that host, and the folder looked empty. Now that one request fails on its own, the folder shows why it could not be listed, and everything else keeps working.

What Changed

Before (finding HH-2, P1): on a managed SSH host, expanding a folder with 80,000 files showed no rows and no error, so it looked like the files were gone. Behind the scenes the host closed its whole control connection with 1013 Outbound reply buffer overflow. Every pending request and subscription on that connection was dropped. A direct files.readDir call returned remote_runtime_unavailable with unrelated Tailscale advice.

After: the folder row turns into an error row reading "This folder has 80,000 entries, too many to list over a remote connection." The connection stays up. The terminal, other file reads and subscriptions keep working.

Mechanism. One request's reply was bigger than the 4 MiB cap the encrypted channel allows for a single message. The channel handled that as a transport fault and closed the socket (closeForOutboundBudget('size')).

• Transport (root cause). The WebSocket RPC dispatch (runtime-rpc-websocket-dispatch.ts) now runs every reply through limitRuntimeRpcReplySize. If a reply is over the cap, it is replaced with a reply_too_large error for the same request id before it reaches the channel. This uses the same admission check the channel uses, so the channel's size close no longer fires for RPC replies. This covers every method, including the other oversized producer in the report (HH-5, agent session list).
• files.readDir. For remote callers only, the listing is checked against the request's existing content budget (remoteRpcResultExceedsContentBudget, the same helper that file preview and git diff use). An oversized listing fails with a message that gives the entry count. Local callers still get the full listing.
• Explorer. A subfolder's read error was already stored in dirCache, but only a root error was ever shown. The expanded folder row now shows that error inline, in place of the folder icon and after the name.

Why

• Why fix it at the transport: the defect is that one oversized reply is treated as a fault in the whole session. Capping a single producer would leave every other uncapped method able to drop the connection.
• Why also give readDir its own check: the generic message only gives a size in bytes. Someone expanding a folder needs to see that the folder is too big.
• Why not page readDir now: paging would change the shape of the reply. Old and new clients and hosts are mixed in the field, so that change needs capability negotiation and an owner decision about how the explorer pages its rows. This PR makes the failure safe and visible. Paging can be a follow-up.
• Wire compatibility: no new fields and no new opcodes. An old client talking to a new host gets an ordinary error response for that request id. A new client talking to an old host still sees the old disconnect, but the folder row now shows the error instead of an empty listing.

Linked Issue

Phase 3.7 finding HH-2 (hostile-host attack). No GitHub issue exists for it. The transport change also stops the connection drop described in HH-5.

Visual Proof

Docker SSH host (debian bookworm arm64, managed orcad), /root/repo/flat with 80,000 files, flat expanded in the explorer.

• Base: the folder expands to nothing. The log shows lastClose: { code: 1013, reason: 'Outbound reply buffer overflow' } with files.readDir pending.
• Fix: the row reads flat This folder has 80,000 entries, too many to list over a remote connection.. No 1013 appears in the log, and the terminal stays live (echo AFTER-FLAT-$((6*7)) printed AFTER-FLAT-42).

Screenshots are in the session evidence folder (~/orca-p37-w3706/evidence/base-04-flat-expanded.png, fix-05-flat-expanded.png, fix-06-terminal.png).

Testing

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

Real host (macOS arm64 app, Docker SSH host, managed server):

	Base (tester's phase35 build ef00191c7c; the changed files are byte-identical to this base)	Fix (this branch, packaged, orcad 0.1.0+204eb8fb4fab)
Expand flat in the UI	empty folder, no error	error row naming 80,000 entries
Control connection	closed with 1013	stays open, 0 closes
Direct files.readDir on flat	remote_runtime_unavailable plus Tailscale hint	runtime_error: This folder has 80,000 entries…
Next call on the same connection (files.readDir '')	—	OK (.git, flat, README.md)
Terminal input after expanding	—	delivered once

The apps ran with ORCA_BACKGROUND_LAUNCH=1, an isolated HOME and profile, their own CDP and inspect ports, and all token and API key variables unset. Windows were never shown or focused. I used one container and removed it afterwards.

Automated tests. Each of these fails without the fix:

• runtime-rpc-websocket-reply-size-limit.test.ts: real OrcaRuntimeRpcServer.handleWebSocketMessage replies go through a real, authenticated E2EEChannel. An 80k-entry files.readDir and a generic oversized reply each produce one decrypted per-request error, and onError (the 1013 close) is never called. Without the fix the channel closes and no reply arrives.
• files-read-dir-remote-budget.test.ts: remote callers get the entry-count error. Local callers still get all 80,000 entries.
• FileExplorerRow.load-error.test.tsx: an expanded folder row shows its read error. A collapsed or loading row does not. The virtual rows pass the cached error to the row.

Checks: pnpm tc, oxlint and pnpm run check:code-quality:changed pass. In the full src/main/runtime/rpc, src/main/runtime/runtime-rpc* and right-sidebar runs, 6019 tests passed. Two tests timed out under heavy machine load and both are unrelated to this change: linear-agent-project-access passes on its own, and runtime-rpc-long-poll-transport passes on its own.

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

• Security: the error reply carries only the reply size and the cap.
• SSH and remote: the size guard sits on the paired WebSocket transport, which is used for managed hosts, mobile and paired clients. The local unix-socket CLI path is unchanged and uncapped.
• Folder workspaces and cross-platform: the explorer change does not depend on the workspace kind or the OS.
• Performance: the guard reuses the channel's own byte-length check, one pass per reply.
• Not covered: the legacy SSH relay readDir path is not exercised here.

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)