ide forward: integrated terminal ~12 s through the relay while explorer is 7 s and localhost < 1 s — attribute the terminal channel's latency, fix the codev-side share

[amrmelsayed]

Problem

With the #1677 H2 flow-control fix live on both halves (tower 3.3.4 + relay), the browser IDE served through the /ide/ forward (#1668/PR #1683) shows a split personality in the 2026-09-19 field re-test (WSL tower, Windows browser, real repository):

	before	after	localhost reference
Explorer populates	45–52 s	7 s	< 1 s
Integrated terminal usable	~15 s	12 s	< 1 s

The explorer's 7x improvement proves the head-of-line starvation is fixed. The terminal barely moved (15 s → 12 s), so its latency is dominated by something the window fix does not touch. 12 s vs a sub-second localhost reference is a 12x gap on a path we forward.

Field numbers and environment: see the 2026-09-19 closure comment on #1677.

Scope: attribute first, then fix what is ours

Phase 1 is measurement — identify which leg eats the 12 s before changing anything:

• The terminal channel's WebSocket upgrade through the forward (ide-forward.ts) and the relay: handshake steps that are round-trip-bound multiply by the ~150 ms relay RTT; count the round trips.
• PTY spawn on the server side once the channel is up (is the spawn itself slow under WSL, independent of the forward? The localhost reference suggests not, but confirm on the same box).
• Remote extension-host / terminal-contribution startup inside the VS Code server (potentially not ours to fix; if attribution lands here, document and close).
• Frame-size profile of the terminal channel vs the management socket: many tiny frames behave differently from the big transfers tower tunnel: small RPCs starve behind large transfers on the shared H2 session (default 64 KB windows) — 39 s explorer stall through the relay #1677 optimized; check whether per-message overhead (e.g. write coalescing, Nagle-like batching absent) dominates.

Phase 2: fix whatever of that is in the forward or tunnel client; anything attributed to the upstream IDE server or the relay gets documented on this issue and handed to the owning side.

Acceptance

Either the integrated terminal becomes usable in low single-digit seconds through the forward, or the 12 s is attributed leg-by-leg with evidence and the codev-side share is fixed, with the remainder explicitly assigned elsewhere.

[amrmelsayed]

Pointers from the fork-side measurements, for a running start:

• Server side, per-RPC timing: run the IDE server with --log trace (via the record Tower spawns from — or a standalone codev-ide-server --log trace --server-data-dir <tmp>); <data>/logs/<ts>/remoteagent.log then timestamps every management/ext-host RPC, and <ts>/ptyhost.log + exthost*/remoteexthost.log cover PTY spawn and remote extension-host startup respectively. Diffing the same session's remoteagent.log timestamps direct-on-localhost vs through the forward isolates the forward's share.
• Browser side, coarse phases: performance.getEntriesByType('mark').filter(m => m.name.startsWith('code/')) in the workbench console — code/willLoadExtensions → code/didLoadExtensions brackets remote scan + ext-host spawn; the Developer: Startup Performance command renders the same as a table. The terminal's own creation is not a mark; time it from the New Terminal action to the first PTY data frame in remoteagent.log.
• Reference points from 2026-09-19: direct localhost, same artifact, same repo — explorer < 1 s; through the forward on a LAN-local Tower (macOS) — full boot ~5 s wall, ext-host row ~0.2–0.4 s; through the relay from a WSL tower — explorer 7 s, terminal 12 s. So roughly: forward alone costs little; the relay round-trips and the on-box ext-host spawn are the two candidates for the 12 s, and a --log trace diff should split them.
• Not much else survived as tooling: the field captures (HAR + Chrome perf trace from 2026-09-12) were one-off files, and the headless-Chromium probes were ad-hoc scripts; happy to hand a copy of the probe over if useful.