1074 Commits

Include renames

Author	SHA1	Message	Date
Neil	e1599c94b8	perf(terminals): let idle panes share one process-table capture instead of forking their own (#18742) ... * perf(terminals): let idle panes share one process-table capture instead of forking their own Every visible local pane runs an agent-completion cadence that resolves through `getStrictProcessTableSnapshot`, and the inspection queue already collapses every shared-observation task enqueued in the same tick onto a single whole-host `ps`. Independent ±10% jitter per pane defeated that: the jitter was re-rolled on each reschedule, so panes drifted permanently apart, each landing in its own tick and each missing the snapshot's 500 ms TTL. Four idle panes cost four captures where one would have served all of them. Idle panes now aim at a deadline grid anchored at the epoch. The pull-forward is clamped to the snapshot TTL, so no interval is ever longer than its tier and none is more than 500 ms shorter: a pane off the grid walks onto it over at most `tier / TTL` steps, costs at most one extra inspection in total, and no inspection is ever delayed. Scoped deliberately. A pane with a foreground agent, or one still inside the 10 s post-activity hot window, keeps its exact interval and its own phase, so the bounded hot cadence is unchanged. The error-backoff path keeps its jitter, where spreading retries across panes is the point. Measured by `pnpm bench:agent-inspection-cadence` — whole-host `ps` captures over 60 s at the 2 s idle tier, median of 21 rounds: | visible panes | before | after | reduction | | --- | --- | --- | --- | | 1 | 29 | 29 | 0% | | 2 | 42 | 30 | 29% | | 4 | 62 | 31 | 50% | | 8 | 82 | 32 | 61% | `process-table-snapshot-reader.ts` measures the `command=` column at 1.15 s of work for 1,948 processes, so these are captures a quiet app was paying for continuously. All 4,202 existing terminal-pane tests pass unchanged, including the no-evidence cadence suite that pins the relaxed and hot intervals. * test(terminals): report n/a instead of dividing by a zero baseline in the cadence benchmark A window shorter than one cadence tier leaves the baseline capture count at zero, and the reduction line then divided by it and printed a meaningless percentage. Reported by CodeRabbit on #18742.	2026-09-05 00:05:29 -07:00
Neil	149732df6d	perf(persistence): stop the session write re-scanning and rebuilding unchanged state (#18739)	2026-09-04 23:39:02 -07:00
3 people	a65332a8bd	feat(claude): move structured native chat onto the Claude Agent SDK and enable it on macOS and Linux (#18560) ... * Join structured attach teardown through journal bind * fix: restore structured chat parity * feat: add Claude structured session adapter * fix: harden Claude structured adapter * fix: close Claude adapter edge cases * fix: start Claude init deadline after launch * feat: wire Claude structured sessions * fix: harden Claude structured runtime * fix: fence Claude structured compatibility * fix: preserve Claude free-text prompt answers * fix: decode addressed Claude prompt text * feat: enable Claude structured chat on mobile * fix(mobile): keep structured chat provider-aware * fix(mobile): negotiate Claude structured tabs * fix: keep scoped RPC tests native-free * fix: secure mobile structured image delivery * fix: close structured session data-loss gaps * fix: prove real Claude structured startup * fix: consume pre-spawn proof before retry * feat(native-chat): add desktop structured sessions * fix(native-chat): satisfy structured session cleanup gates * fix(native-chat): keep structured renders pure * fix(native-chat): open composer pickers upward * fix(native-chat): use existing view for structured sessions * fix: harden structured desktop status projection * fix: close structured desktop lifecycle gaps * fix: fence structured AI Vault resumes * fix: fence structured AI Vault resumes * fix: preserve structured tabs during activation * feat: toggle structured sessions between chat and TUI * fix: harden structured session handoffs * fix: bind structured TUI before rollout proof * fix: complete structured chat round trips * fix: align structured TUI return readiness * fix(native-chat): make reverse handoff transactional * Add Claude structured TUI handoff seams * fix(native-chat): clear sticky handoff recovery * fix(native-chat): complete mobile reverse after TUI exit * fix(native-chat): keep TUI transcripts readable * fix(native-chat): recover TUI transcript gaps * fix(native-chat): recover claimed TUI owners * fix(native-chat): retain cold TUI proof authority * fix(native-chat): preserve Claude handoff authority * fix(native-chat): recover TUI transcripts read-only * fix(native-chat): harden Claude handoff recovery * fix(native-chat): serialize structured handoff recovery * fix(native-chat): close handoff admission races * fix(native-chat): validate pinned launch environment * fix(native-chat): revalidate restored and retried owners * fix(native-chat): gate restart recovery publications * fix(i18n): catalog Claude session controls * fix(native-chat): wait for structured TUI process proof * fix(native-chat): queue stale idle TUI handoffs * fix(native-chat): route structured Codex options directly * fix(native-chat): persist structured session options * fix(native-chat): hydrate resumed structured options * fix(native-chat): preserve options across structured handoffs * fix(native-chat): replay pending option mutations * fix(native-chat): rotate settled handoff operations * fix(native-chat): rotate refused send operations * test(native-chat): derive refusal retry state from host * test(native-chat): give the host-oracle matrix test an explicit timeout * fix(native-chat): keep Claude option controls idle * fix mobile structured first-send hydration race * fix(native-chat): preserve handoff launch authority * fix(native-chat): harden shared handoff recovery * fix(native-chat): serialize structured handoff recovery * fix(native-chat): close handoff admission races * fix(native-chat): validate pinned launch environment * fix(native-chat): revalidate restored and retried owners * fix(native-chat): gate restart recovery publications * fix(i18n): catalog structured session recovery control * fix(native-chat): wait for structured TUI process proof * fix(native-chat): queue stale idle TUI handoffs * fix(native-chat): keep structured recovery provider-neutral * fix(native-chat): drop local terminal topology from structured sync * fix structured outbox and tab restore races * fix(native-chat): preserve Claude question groups * fix structured provider visibility and request handling * fix structured session TUI handoff recovery * fix reverse structured session handoff * fix(native-chat): recover Claude outbox and resume state * chore(mobile): preserve the working-tree lockfile state before the main merge Carries the pre-existing uncommitted mobile/pnpm-lock.yaml modification into history so the main merge cannot overwrite it. Verified benign pnpm drift (babel 7.29.7->7.29.8 transitives plus deprecation metadata); drops no patchedDependencies (the mobile lockfile declares none). * test(native-chat): drop orphaned Claude handoff-auth test left by the main merge 'pins Claude handoff auth through the terminal provider boundary' is absent from main and its production counterpart preserveClaudeAuthEnv no longer exists outside this test - orphaned residue of the terminal/native handoff work this PR excludes by scope. Removed rather than repaired: the failure was a renamed field (providerHome -> providerRoot), and renaming it would have carried out-of-scope handoff code into the merge. Body preserved as evidence and logged in CLAUDE-STRUCTURED-DISPOSITION-TABLE.md. * Fix mobile structured turn state * fix Claude structured session blockers * fix claude structured lane blockers * fix Claude acquisition exit proof * fix(claude): route stream-json launch through process wrapper * fix(claude): gate structured chat support * Fix Claude structured launch gating * fix(claude): split session acquisition and prune mobile scope * test(claude): align structured session fixtures * fix(agent-session): preserve handoff launch arguments * fix(claude): open journals through the factory after origin/main split The journal opener moved to journal-store-factory on main; retarget the Claude structured tests that still imported the old path. * fix(claude): resolve Claude structured launch args, auth, and win32 proof The origin/main merge re-expressed the lane's Claude wiring onto main's split orca-runtime facade and dropped three wires past green typecheck and lint. - resolveLaunchArgs discarded its provider parameter, so structured Claude sessions were launched with Codex app-server flags; Claude exits on --dangerously-bypass-approvals-and-sandbox, and a Codex arg-parse throw could block Claude session creation outright. - resolveClaudeLaunchEnv was no longer supplied, so the launch resolver fell back to the whole process env as configuredEnv and buildClaudeChildProcessEnv re-applied every auth var it had just stripped. The resolver now merges the Claude overlay onto a strip-applied copy of the inherited env, which also keeps PATH intact for withCliRuntimeOnPath. - The windowsProcessStartTimeAvailable producer was gone while the contract field and both consumers survived, so the renderer gate fail-closed and structured native chat was unreachable on every win32 host. Separately, structured Claude pinned CLAUDE_CONFIG_DIR unconditionally. An explicit pin makes the CLI abandon the macOS Keychain even when it names the CLI's own default, so a default claude.ai account could not authenticate where the legacy Claude terminal could. Pin only a home the CLI would not resolve on its own, matching ClaudeRuntimePathResolver, and compare against the env the child would otherwise inherit so a diverging overlay cannot outrank the record's account home. Also await the now-async revealNativeSession in its regression test, and set the native status before revealing so a rejecting reveal cannot leave a session released but never marked native. Claude-Session: https://claude.ai/code/session_013UqKCRB6k5e8UaYhXUHeWY * fix(claude): scrub case-insensitive Windows auth env * fix(native-chat): settle handoff outcome-write failures instead of leaking them A store write failure while recording a handoff outcome escaped the flow runner's catch handler, so the client never received the failure and the flow surfaced as an unhandled rejection (seen as an intermittent agent_session_store_corrupt error in the proven-dead-retry suite, whose teardown raced the flow's trailing outcome write). Record the failed outcome best-effort, and drain the coordinator before that test's teardown removes the store root. Claude-Session: https://claude.ai/code/session_011aXkcHyeiRJuezupQdjZaM * fix(native-chat): make the structured close-failure toast provider-neutral The structuredSessionCloseFailed toast fires for any structured session, but its copy said 'Codex chat', so a Claude structured session that fails to close showed the wrong provider name. The launch-failure toast is only reachable behind the agent === 'codex' gate, so its copy stays as is. Claude-Session: https://claude.ai/code/session_013ugSpCx4AWkySaJb69BQax * fix(native-chat): wire structured handoff proof recovery * fix(native-chat): wire structured handoff proof recovery * fix(native-chat): correct the structured chat opt-in copy The one `experimentalStructuredNativeChat` toggle gates both providers — `useStructuredAgentSessionCreate` runs `canUseStructuredNativeChat` for `'claude'` as well as `'codex'` — but its description named only Codex. Its scope line also said Windows keeps using terminal chat, while the gate refuses win32 only until the host proves it can read a process start time. `structured-native-chat-availability.test.ts` already pins that Windows is allowed once the proof is cached, so the two contradicted each other. Claude-Session: https://claude.ai/code/session_01RJFsidQWmKYFmeoUuVu4Tp * test(claude): pin @anthropic-ai/claude-agent-sdk 0.3.251 contracts against a scripted CLI PR 1 of the SDK migration: dependency + test-only harness, no product wiring. - Pin @anthropic-ai/claude-agent-sdk to exactly 0.3.251 — not the newest release — because 0.3.251 (published 2026-08-28) clears the repo's 3-day minimumReleaseAge supply-chain gate with no exclusion, while the newest release was minutes old and would have required excluding a brand-new publish from the exact control built to catch brand-new malicious publishes. Every contract this design depends on was verified identical on 0.3.251: the full option surface, no pid on SpawnedProcess (custom spawner stays mandatory), env defaulting to process.env when omitted, and --replay-user-messages appearing only via extraArgs. - Exclude all eight bundled CLI platform binaries via ignoredOptionalDependencies. The setting lives in pnpm-workspace.yaml because pnpm 12 no longer reads the package.json "pnpm" field (it warns and ignores it; verified by install ablation). Excluding the binaries is what makes Orca's pathToClaudeCodeExecutable override mandatory rather than merely preferred. Note: pnpm 12.0.0 honors the ignore list when reconciling an existing lockfile but not on fresh resolution of a new dependency, so the lockfile's SDK entry was pinned surgically; both 'pnpm install' and 'pnpm install --frozen-lockfile' verify clean and stable against the committed lockfile. - Contract-pin suite drives the real SDK against a scripted fake CLI and pins: unknown type/field/content-block pass-through (and keep_alive interception), spawner env fidelity plus the omitted-env process.env inheritance sharp edge, extraArgs producing --replay-user-messages, argument parity for every CLAUDE_STRUCTURED_BASE_ARGS entry plus --session-id/--resume/ --resume-session-at, canUseTool wire request_id stability and abort on control_cancel_request, one spawn per query, pathToClaudeCodeExecutable honored by the default spawner, the exact SDK version, and the eight platform binaries staying uninstalled. Claude-Session: https://claude.ai/code/session_01FGCRfYUnb4hbvfTAHGtJKQ * feat(claude): drive the structured transport through the agent SDK Replaces the hand-rolled `claude -p --input-format stream-json` transport with @anthropic-ai/claude-agent-sdk 0.3.251, keeping the existing connection interface for this commit so the acquisition path changes minimally. The control-plane rewrite is a separate change. Orca still supplies the process. `spawnClaudeCodeProcess` routes through `spawnProcess`, retains the child and its pid — the triple the durable lease adjudicates on — drains stderr so exit errors keep their tail, and hands `.cmd` shims to Orca's Windows argument encoder rather than the SDK's plain spawn. `close()` keeps Orca's own bounded tree-kill and exit deadline, so it still resolves true only after an observed exit. Launch resolution emits an SDK options object instead of argv; durable `launchArgs` translate to a typed option where one exists and to `extraArgs` otherwise, refusing a token neither can carry rather than dropping it. The child env is always passed explicitly — omitting it would let the SDK inherit `process.env` and reintroduce the ambient `ANTHROPIC_*` leak. The stdout line parser is deleted; the SDK owns framing, and unknown frames still reach the translator verbatim. Claude-Session: https://claude.ai/code/session_01JMhFjh9HEnkcJ5YTfCdgD3 * fix(claude): settle the frame the SDK pulled but never wrote The SDK's input pump is `for await (frame of prompt) { await transport.write(frame) }`. When that write rejects — the child dies between Orca's liveness guard and the write — the for-await ends abruptly and calls the generator's `return()`, so the code after `yield` never runs. The frame was already shift()ed out of `queued`, so the later `fail()` from the exit path could not reach it and `send()` never settled: `dispatchClaudeTurn` awaits that send before it can return `unknown`, wedging the caller and the durable outbox. The pre-SDK transport rejected on the stdin write callback instead. Retain the in-flight entry and settle it from the generator's cleanup, and let fail() reach it too for the pump that never resumes at all. Claude-Session: https://claude.ai/code/session_01AobxxokqQ3qcxS7sy7ckum * fix(claude): keep the agent SDK behind the structured-Claude boundary The ordinary OrcaRuntimeService graph statically reaches the Claude adapter and so the transport module, whose first line imported @anthropic-ai/claude-agent-sdk. The SDK is evaluated whenever the regular runtime loads, before any structured Claude session is chosen: it sets process.env.NoDefaultCurrentDirectoryInExePath, changing Windows executable resolution for later subprocesses, and a missing or incompatible install would break normal runtime startup — for a user who never leaves the terminal/TUI path. Defer the SDK to the connection, memoized so it loads once per process, and add the import-graph ratchet: a walk from the Electron main entry that fails on any static import of the package, plus a clean-fork check that loading the runtime leaves the Windows search variable untouched and a child-process pin that the side effect is still real. Claude-Session: https://claude.ai/code/session_01AobxxokqQ3qcxS7sy7ckum * fix(claude): answer list_models so the picker stops serving the seed sendControlRequest had no list_models case, so every request hit the default reject; readClaudeStructuredSessionOptions swallows that with .catch(() => null) and falls back to the static catalog. Every structured session therefore served a hardcoded model list with no per-model effort levels, no resolvedModel and no default detection, and nothing surfaced the failure. The pre-SDK transport got the live catalog from the CLI. Route it through the SDK's supportedModels(), wrapped in the { models } envelope the existing parser reads. Claude-Session: https://claude.ai/code/session_01AobxxokqQ3qcxS7sy7ckum * fix(claude): reap the child's descendants before killing it The forced step of the exit ladder went through the Codex helper, which spawns `pkill -KILL -P <pid>` and SIGKILLs the parent in the same tick: the parent usually dies first, the descendants reparent to pid 1, and `-P` matches nothing. An MCP or launcher descendant of a stubborn Claude child was left running. The test named for that requirement declined to assert it and killed the survivor by hand instead, so it could not fail for the thing it was named after. Route the Claude reap through Orca's existing sweep, which snapshots descendants while their parent link still exists and signals them before the root goes, and on Windows uses the identity-gated `taskkill /T /F`. The test now asserts the descendant is dead; the manual kill stays only as a failure-safe. close() still returns true only on an observed exit. Claude-Session: https://claude.ai/code/session_01AobxxokqQ3qcxS7sy7ckum * fix(native-chat): merge the duplicated handoff type import CI's static-analysis lint (`oxlint --config config/oxlint-code-quality-native-plugins.json src config tests mobile --deny-warnings`) exits 1 on the two separate `import type` statements from the same module. Claude-Session: https://claude.ai/code/session_01AobxxokqQ3qcxS7sy7ckum * fix(claude): answer a permission callback whose signal already aborted settleFrom registered the abort listener and then delivered the request. A callback that arrives already aborted never fires that event, so the promise stayed pending behind a durable prompt with no cancel path. Check the signal first, emit the cancel, and resolve the SDK's null sentinel without registering. Claude-Session: https://claude.ai/code/session_01AobxxokqQ3qcxS7sy7ckum * test(claude): wait for the child to record the frame, not just for its report The scripted CLI writes its report at startup, so `until(readReport)` returned a report with no user messages whenever the child had not yet read the line. The assertion then failed under parallel load. Poll for the frame instead of for the file. Claude-Session: https://claude.ai/code/session_01AobxxokqQ3qcxS7sy7ckum * fix(claude): coalesce partial deltas onto one assistant item and stop painting result frames Under --include-partial-messages every stream_event frame carries its own uuid, and the final assistant frame for a block carries yet another; only message.id ties them. The translator keyed each delta by its frame uuid, so a reply painted as one bubble per delta chunk followed by a complete duplicate under the final frame's uuid. The block's first stream frame now mints the claude:(sessionId, uuid) identity, deltas coalesce onto it through the shared 60ms seam, and the final frame reconciles onto that same item. Known SDK bookkeeping no longer reaches the provider-fallback row: result subtypes are catalogued and settled by the turn lifecycle, an empty thinking block (redacted thinking) is a modeled kind, a string-content user replay is a text block, and an empty user frame paints nothing. An unmodeled result subtype or content kind still lands on the bounded fallback row. Claude-Session: https://claude.ai/code/session_01GaP5HpYQbvy2hYehVhwfEW * fix(claude): prove descendant exit at the close boundary instead of on an unref'd timer close() reported proven=true as soon as the direct child exited while the descendant sweep's SIGKILL sat on an unref'd 2 s timer, so a SIGTERM-resistant MCP server outlived the lease release. The reaper now composes the same shared primitives the Codex structured provider uses: snapshot, verified bounded descendant termination on POSIX, taskkill /T /F on Windows. The proof is false whenever descendants outlive the deadline, a retried close re-verifies the retained snapshot rather than trusting the dead root, and the raw pipe child no longer goes through the PTY job sweep it never owned a job for. Measured on macOS: a killed child of a SIGSTOPped parent stays a matching zombie row in ps, so the root is killed while verification runs rather than stopped first as the Codex non-group path does. Claude-Session: https://claude.ai/code/session_0161QFm3KVRNJKfdzWVGVNWk * feat(claude): replace the hand-rolled control plane with the SDK's native surface PR 3 of the Claude structured SDK migration removes the wire-frame scaffolding PR 2 kept, so Orca drives the SDK's typed control surface directly. Inbound permissions move from a rebuilt control_request dispatch to the SDK's canUseTool / onUserDialog callbacks. The prompt registry now carries the callback's own resolver: a decodable can_use_tool becomes a durable prompt whose answer settles the callback; a malformed one is denied without registering; the SDK's abort signal (fired on control_cancel_request, which the SDK matches and dedups itself) forgets the prompt and settles it null, and a late answer after abort finds no prompt and is refused. Closing settles every in-flight callback so no promise dangles. The claude-agent-sdk-control-bridge that rebuilt the wire frame is deleted. Outbound control maps to Query methods: interrupt() for cancel, setModel / setPermissionMode / applyFlagSettings for options, supportedModels for the model list, initializationResult() for init proof, each under Orca's own request deadline and error classification. Cancel is interrupt-receipt aware: a CLI advertising interrupt_cancel_queued_v1 gets cancel_queued in one round trip, otherwise the receipt's still_queued uuids are swept with cancel_async_message so a cancelled turn cannot spawn a later unexpected turn; older CLIs resolve no receipt. Init keeps the 10s deadline and the unauthenticated-startup guidance. Every behavior is failing-first and ablation-proven; the toggle-off import boundary and the accepted loss of unknown-control visibility rows are unchanged. Claude-Session: https://claude.ai/code/session_01Pqjduxt5G4rr9aYvtp7rNm * fix(claude): arm the descendant snapshot before stdin closes and make the tree verdict unproven by default A healthy Claude root leaves within the graceful window, and the close ladder only snapshotted descendants when the root was still alive after that window. So the common close never looked at the tree: `treeExited` stayed null, `!== false` passed it, and close() reported a proven exit with an MCP child still running. A root that died before the walk made the snapshot vacuous too. The proof is now unproven by default. The reaper holds one verdict in Orca's vocabulary (exited / live / unverifiable), assigned in exactly one place from the bounded verification, and close() returns true only on `exited`. The snapshot is armed before stdin closes, while the root can still be walked, and is verified after the root exits; a root that left before any snapshot could be armed stays unverifiable rather than vouching for descendants it never showed us. The shared verifier gains the three-way verdict behind its boolean face, and the connection reports the root and tree verdicts separately along with the child's exit status. One verification per close attempt: the retried close re-verifies, so the intra-attempt re-reap is gone from the teardown budget. Claude-Session: https://claude.ai/code/session_01BSmXgkWSsNHft8jFkdBFG9 * fix(claude): verify the Windows tree after taskkill instead of trusting that it ran `terminateWindowsProcessTree` resolves from taskkill's callback whatever the error says, so a timeout, an access denial, a recycled root and a surviving descendant all looked identical to the reaper — which then returned a proven exit unconditionally. close() reported true and the lease was released with an MCP descendant potentially still live. The Windows branch now snapshots the root's descendants while it is alive and, after taskkill, polls a fresh process table to a bounded deadline: a row still matching by pid AND creation time is `live`, an unreadable table is `unverifiable`, and only a table with no match is `exited`. Creation time is the PID-reuse guard the POSIX path gets from ps lstart, so a descendant that denied a creation-time query is omitted rather than signalled on a bare pid. A root already observed exited is never taskkilled: `/T /F` on a recycled pid would take an unrelated tree down with it. The captured tree is tagged by platform so neither verifier can be handed the other's rows. Claude-Session: https://claude.ai/code/session_01BSmXgkWSsNHft8jFkdBFG9 * fix(claude): release a reservation on a first-hand root exit instead of latching it into manual recovery Making close() strict about the descendant tree exposed a second defect at the same boundary. A create-time acquisition has no ownerProcess until publication, so an unproven cleanup mapped to handoffStage `manual-recovery`, and adjudication then refuses every later attach with agent_session_ownership_unknown. A user who was merely signed out, or whose --resume the CLI rejected, wedged the session id permanently. Each question now answers from its own evidence. close() is unchanged and stays strict about the tree. Separately, the lease is keyed on the root's pid and start time, so when Orca's own child handle observed that root exit and no descendant snapshot was ever admissible, the reservation is released and the CLI's exit code and stderr reach the user. A descendant observed still alive, or a root Orca never saw leave, stays unproven and keeps the reservation. The settlement records only what was observed: the released lease says the provider process exited and its descendants were not verifiable, rather than reusing the wording that claims cleanup proved no child remains. Claude-Session: https://claude.ai/code/session_01BSmXgkWSsNHft8jFkdBFG9 * fix(claude): surface an API error a result frame reports instead of settling the turn on it The SDK models an API failure as a SUCCESS-subtype result whose `result` string is the user-facing error text, with no assistant frame behind it. The translator suppressed every catalogued result subtype as turn bookkeeping, so that turn tombstoned its lifecycle and showed the user a completed, empty reply with no sign anything had failed. Suppression is now by meaning. A result reporting a failure routes to the bounded provider-error surface, leading with the provider's own sentence and keeping the raw frame behind the row's disclosure; ordinary successful results stay off the timeline as before. A turn the user aborted also stays suppressed: its interrupt frame already says so, and its execution diagnostic would only be noise on every stop. Claude-Session: https://claude.ai/code/session_01BSmXgkWSsNHft8jFkdBFG9 * fix(claude): drop the stream state of turns that never received their final frame Every streamed delta recorded its block's identity, latest text and checkpoint length. Only the final assistant frame removed them, so an interrupted turn left its whole accumulated reply reachable until the session was disposed, and a long session with repeated interruptions grew those maps without bound. The partial text was already journaled by the flush that precedes settlement, so the live copy was pure retention. That state now lives in its own module, named for what it does — grow a streamed block's journal row between its deltas and its final frame — and turn settlement drops every block still awaiting a final. The translator reports how many remain, which is the invariant: a settled turn leaves none. Also makes a timed-out process-table read retryable while the root is still alive. A loaded host can miss the table's one-second deadline, and latching that as "no descendants" both lost the descendant sweep and, on a busy machine, made the close ladder report unproven for a tree it never actually looked at. Only the root's death still makes a missing snapshot final. Claude-Session: https://claude.ai/code/session_01BSmXgkWSsNHft8jFkdBFG9 * perf(claude): capture the Windows descendant tree from one process-table read The capture walked the descendant tree and then read the table again for the creation times the walk's projection drops. Each read is bounded in seconds and both run inside the close ladder's budget, so the second one cost the worst-case teardown three seconds for data the first read already held. The walk is now exported from the module that owns it and runs over rows the caller has already read, which is also what lets the snapshot keep the PID-reuse guard the projection cannot carry. Claude-Session: https://claude.ai/code/session_01BSmXgkWSsNHft8jFkdBFG9 * fix(pty): spend the descendant verification window instead of surrendering on one slow table read The verification abandoned the whole check the first time a process-table read missed its own one-second deadline, with seconds of its window still unspent. On a loaded host that reported a tree unverifiable without ever having looked at it, which the Claude close ladder then turned into an unproven close and a retried teardown. It also made the descendant-exit tests flake under a parallel suite run, for the same reason and with the same honest-but-premature verdict. A read that missed its deadline is now simply not an answer: the loop waits and reads again until its own deadline, and only a window that ends without a readable table reports unverifiable. This can only turn a premature verdict into one backed by evidence; it never manufactures a proof. Claude-Session: https://claude.ai/code/session_01BSmXgkWSsNHft8jFkdBFG9 * fix(claude): never let a later failed look collapse an observed live descendant into unverifiable The reaper's single assignment site latched only 'exited', so a second reap whose table reads all missed their deadline overwrote an earlier completed verification's 'live' with 'unverifiable'. The acquisition release gate discriminates on exactly that pair, so a root exit after such a decay released the lease over a descendant that had been observed alive. The latch is now monotone in trust order: exited is final, and live is only ever raised to exited. Claude-Session: https://claude.ai/code/session_01HfdhsvSJucLw4cTZxzg2CP * fix(claude): never prove a Windows tree gone while a descendant denied identification The Windows snapshot dropped rows that denied the creation-time query, and an emptied snapshot was judged exited without any table read: a descendant Orca was refused information about was treated as one that had left. The snapshot now counts the unidentified rows it saw, and verification caps its verdict at unverifiable while any exist. Nothing is ever signalled on a bare pid, as before. Claude-Session: https://claude.ai/code/session_01HfdhsvSJucLw4cTZxzg2CP * fix(claude): classify cleanup after a first-hand exit as a root exit instead of a proven tree When the CLI died between a successful acquire and the host's commit or proof of the lease, handleExit had already removed the session, so releaseAcquisition found nothing and reported true. The attach flow then settled exit-proven with deathEvidence claiming cleanup proved no provider child remains, though the tree was never verified. The adapter now keeps the exit that removed a published session until the session is acquired again; acquisition cleanup runs that connection's close ladder and classifies its verdict exactly as a start-time failure would be, so the record reads root-exit-observed. The wire helper keeps that typed classification and its provider diagnostic instead of wrapping it as unproven, and the router gives up its owner even when the release throws. Claude-Session: https://claude.ai/code/session_01HfdhsvSJucLw4cTZxzg2CP * fix(claude): integrate SDK teardown and picker lifecycle fixes * fix(claude): preserve resume leaf and settle processless spawns * fix(claude): reacquire from persisted resume leaf * fix(native-chat): restore Claude grouped question handling * fix(claude): persist only resumable transcript leaves * fix(claude): recover structured session exits safely * fix(claude): close remaining structured session P1s * fix(claude): harden transcript branch proof * Remove superseded root fix reports * fix(windows): restore indexed descendant row walk * fix(router): forward force-close lifecycle * fix(claude): fence stale turn cancellations * fix(claude): fence cancellation after unknown dispatch * fix(claude): fence replay and option recovery races * fix(claude): block replay fallback after waiter eviction * fix(claude): fence evicted slash results * fix(claude): fence ambiguous results and restore options safely * fix(claude): scrub SDK child env and localize pending launch * fix(claude): pin transcript roots and exit recovery proofs * fix(claude): retain unproven SDK exits * fix(claude): settle retained exit before reacquire * fix(claude): resume from settled retained cursor * chore: remove tracked review artifact * fix: harden Claude SDK transport session cleanup * fix: close Claude sessions safely * fix(claude): close races with fresh child snapshots * fix(claude): fail closed on recycled child identities * fix(claude): gate root cleanup on process identity * fix(claude): fence same-second root identity reuse * fix(claude): restore the root SIGKILL fallback the identity gate took away The direct root kill goes through the handle Node owns, not through a pid: libuv drops that handle in the same turn it reaps, so the signal either reaches the process Orca spawned or reaches nothing at all. Gating it on a process-table probe therefore bought no safety and cost the tree its only fallback whenever the probe declined -- a first capture landing in the fork's own second, a recycled descendant pid voiding the snapshot, or a process table that could not be read on either platform. Identity verification stays where a bare pid is genuinely addressed: Windows `taskkill /T /F`, and the descendant sweep's own revalidation before it signals. Also stops a declined root probe from collapsing an observed `live` or `exited` descendant verdict into `unverifiable`, and stops a successful taskkill from reporting `unverifiable` because a later probe found the root correctly dead. * docs(claude): rewrap the root-kill ordering comment * Match the Claude structured launch to the terminal path's managed-account auth rules The SDK path stripped ambient Anthropic auth unconditionally, let an explicit agentDefaultEnv override beat a pinned managed account, and had no account-switch guard. Reuse the terminal preflight's own predicate and messages so both transports strip, refuse, and report identically, and cover the CLI transcript location that mobile native chat depends on. * Reach the Claude structured chat lane from the desktop UI The main process has had a complete, correctly gated Claude Agent SDK lane for a while, but no renderer ever asked for it: the launch route accepted only `codex`, and the create path was typed `agent: 'codex'` end to end. Widen both to the structured provider union that already exists (`AgentSessionHandleProvider`), and generalize the codex-named create path instead of adding a Claude twin beside it. The pending-launch registry is now keyed by agent as well as workspace — a shared key handed a second caller the first agent's intent, so a Claude and a Codex launch in one worktree collided. Windows, per agent. Codex's client-side win32 refusal is deliberate and settled elsewhere, so it stays exactly as it was. Claude's answer is no longer guessed from the client's platform: a structured session fences its provider child on that child's process start time, and only the executing host knows whether it can read one. `agentSession.createSupport` already answers precisely that, per agent, and had no renderer caller — so the Claude create path asks it before creating and turns a "no", or a probe it cannot get answered, into the definitive refusal the launch fallback already handles. Fail closed either way. That refusal mapping also closes a real gap: the host reports an unsupported location by throwing `structured_agent_session_unsupported`, which reaches the client as a transport rejection rather than a refusal envelope, so `StructuredAgentSessionCreateRefusalError` never fired. The launch would retry the create, strand itself in `visibilityUnknown`, run no legacy fallback, and show an error toast. Close a fail-open hole while Claude and win32 become reachable: `create` with a client-supplied location, and `ensure`, both skip the worktree-resolving support check. They now ask the executing host the same question directly, so a host that cannot fence a provider child no longer creates one on a client's say-so. Also deletes `structured-agent-session-provider-routing.ts`, a duplicate of `structured-agent-session-provider-support.ts` with no importers. WSL, SSH and paired hosts, floating workspaces, draft prompt delivery, explicit TUI customization and initial session options all keep refusing; folder workspaces keep working. * P1-1: make the structured Claude auth policy required and testable The optional dep plus a {stripAuthEnv:false} fallback meant a dropped wiring under-stripped silently. Required at all three hops, asserted at install time for the @ts-nocheck caller, and the settings-to-policy mapping is now a named tested function. * P2-3: mobile's default Claude transcript root must follow CLAUDE_CONFIG_DIR session-file-resolver's default ignored the variable the pinned account home follows, so a CLAUDE_CONFIG_DIR launch wrote one tree and mobile read another. The Task-4 test now resolves with no root override (mobile's own call) and checks the answer against the root the CLI itself reports, instead of mirroring the code under test's own expression. * P2-1/P2-2/P3: close the teardown window, join the live-auth gate, align the refusal P2-1: a switch beginning inside the acquire teardown left a dead chat and no replacement. Past that point the launch waits the swap out and refuses only if it never settles; the entry guard still refuses outright, because nothing is torn down there yet. P2-2: structured children now hold the same OAuth-refresh gate a Claude PTY does, so a managed refresh cannot rotate the token out from under a live turn. P3: the refusal now matches the strip it guards (case-folded on win32, presence not truthiness), and the dead structured-to-TUI builder states its auth policy instead of silently signing a system-auth user out. * Make the live-auth gate tests independent of sibling connection teardown order * Do not offer structured Claude under a WSL-only managed account Structured Claude launches against the ambient Claude config, which the account service keeps in sync with the selected HOST account. A WSL-bound managed account lives inside the distro and is never synced there, so on Windows a structured session would authenticate as whatever the ambient identity happens to be while the UI names the WSL account — the user is told one identity and given another. That was unreachable only because nothing offered structured Claude on win32. Enabling it makes it reachable, so gate it here rather than patching the auth layer: refuse the structured path when the active managed Claude account is WSL-bound, and let the terminal-backed path — which resolves the account per runtime — handle that account shape. The answer rides the agentSession.createSupport seam the renderer already consumes, so no new capability and no renderer knowledge of account internals. A create the host declines becomes the definitive refusal the launch fallback already turns into a legacy native chat tab, with no error toast. Unknown answers refuse. An install with no managed accounts claims no identity and is fine, but an active selection that cannot be resolved — or account state that cannot be read at all — is not evidence that the ambient identity is right. Claude only. Codex resolves its account through a different path and its createSupport answer is untouched, as is every Codex routing decision. * Read the structured Claude account gate through the auth policy's accessor The gate resolved the active account from the account-service snapshot's runtime map; the auth policy resolves it with getSelectedClaudeAccountIdForTarget(settings, { runtime: 'host' }). Those are two sources and two resolution rules, and they disagree on a legacy settings blob that carries the selection only in the flat activeClaudeManagedAccountId: the accessor falls through to it, a direct read of the runtime map does not. The gate would then refuse a launch the policy would have run under host-1 — and in the mirror case a session could be admitted under a policy computed from a different account than the gate approved. Read the same settings through the same accessor so agreement is structural rather than coincidental, and drop the controller accessor that existed only to reach the snapshot. No behaviour change for any state both already agreed on; Codex is untouched. * Round-3 review fixes: N-1 empty-value regression, N-2 gate leak window, N-4 lost history N-1: my presence-based conflict predicate refused a terminal launch that works today. 'ANTHROPIC_API_KEY=' is how a user blanks a variable and the settings pipeline preserves that empty value; an empty override cannot beat the pinned account and the strip removes the name anyway. Back to truthiness for the value, keeping the win32 case folding. N-2: enter the live-auth gate only after the exit/close handlers that release it, so no throw in between can leave an entry nothing reconciles. N-4: the Claude transcript resolver searches config-dir-then-default and de-dupes, matching the Codex sibling in the same file, so adopting CLAUDE_CONFIG_DIR no longer hides history written before it. * Run the managed-account gate on every Claude acquisition, not just create createSupport gates the create path, but a session's account state can change while it lives. A reacquire after an unexpected child exit re-resolves the launch and re-derives auth, with nothing re-checking the gate — so a session created while supported could come back up in the refused shape. With the strip predicate keyed on there being an active non-WSL account, the WSL-only user's normalized steady state (accounts exist, none active) does not strip, and that reacquire reaches the child with ambient auth while the UI names the account. Gate at resolveLaunch, the one choke point every acquisition passes through, refusing with the pre-spawn error the caller already handles. Same predicate as create-time, now sharing one settings reader so the two cannot drift. Claude only; Codex resolves its account on a different path and is untouched. The runtime class that wires this does not typecheck its own `this` calls — a missing hookup compiles clean — so the wiring is pinned behaviourally rather than trusted to the compiler. * Move the structured Claude gate out of the @ts-nocheck runtime files Both call sites of the managed-account gate sat in files whose first line is `// @ts-nocheck`, so neither was typechecked: three arguments to a one-argument function plus an undeclared identifier compiled clean. New auth-identity decision logic had no compiler behind it. Move the verdict into a checked module that takes the two facts the runtime owns — the adapter's answer and a settings getter — and decides. The runtime class now only forwards. Move the gate reader's construction into the checked installer too, so the nocheck file passes a plain settings closure and never names a gate symbol. Every reference to the gate predicate and its reader now lives in a checked file, so the ablation that used to pass silently is a compile error at both the create-support and reacquire sites. Removing the file-level @ts-nocheck is a separate, larger job and is not attempted here. * Derive the gate test's auth policy from the settings under test A hardcoded stripAuthEnv asserts a gate/policy pairing production cannot produce, and false additionally lets launch.env inherit the runner's real process.env. Derive via claudeStructuredAuthPolicyForSettings instead: the gate settings type is the same Pick the policy takes, and both resolve the account through getSelectedClaudeAccountIdForTarget. * Pin the absent-vs-empty distinction in the managed-account gate An empty claudeManagedAccounts array is a real answer: the user has no managed accounts, nothing claims an identity, and the ambient path is legitimate. A readable settings object with no such field is settings we failed to parse — the same unknown as unreadable — so it refuses. The two are one character apart in the code and the difference is invisible without the reasoning, so record it at the branch and pin both sides. The test fails under the obvious "consistency fix" of treating a missing field as empty. * fix(claude): keep command queue bookkeeping out of the transcript Claude Code 2.1.258 emits a `command_lifecycle` frame for every uuid-stamped command it starts, completes or cancels. The frame carries a command uuid and a state and no content, and the CLI keeps it out of its own transcript -- but it is absent from the SDK's SDKMessage union and so from Orca's frame catalogue, where an uncatalogued kind defaults to a substantive row. Every structured turn therefore painted raw JSON rows into the user-visible transcript. Catalogue it and disposition it as status chrome. The unknown-kind default stays `timeline-substantive`: a kind we have never seen is likelier to carry content than to be chrome, and a visible row we can catalogue later beats content we silently dropped. A lifecycle state that reads as a failure still surfaces, because the payload error check in `classifyProviderFrame` outranks the catalogue. * fix(claude): let a re-walked descendant become eligible for the forced sweep A descendant first observed by a capture inside its own birth second could never be SIGKILLed: `ps lstart` is second-resolution, so that capture cannot rule out a pid recycled later in the same second, and the merge pinned each retained row to the boundary of the walk that first saw it. SIGTERM-resistant children forked in that window were signalled and then never escalated -- they survived close, quit and restart, reparented to init, and had to be killed by hand. Advancing that boundary on any later capture would be unsound: a later capture matching pid, pgid and start-second is exactly what an impostor would also show. But a capture is not a match -- it is a fresh ppid walk from a root Node pins through its own handle, so a row it re-derives is proved ours at that instant without appealing to its start time. Chain the fence from there instead, and take that walk at the close boundary while the root certainly still lives: the root may leave inside the grace window, and the post-timeout refresh never runs. A row absent from the later walk still keeps its earlier boundary, and a row no walk has ever re-derived in a later second is still never escalated. * Treat an absent managed-account list as empty, not as unreadable An empty claudeManagedAccounts array and a missing one are the same answer: this user has no managed Claude accounts, so nothing claims an identity and ambient auth is the truth. Refusing on absence strands any profile that simply never wrote the key, and it disagrees with the auth policy, whose own predicate takes `(accounts ?? [])` for exactly this reason. Only settings that cannot be READ stay unknown, and those still refuse — as do a WSL-bound active account and a selection naming an account the list does not explain. The earlier reasoning treated a missing field as settings we failed to parse. That conflated "not present" with "not readable"; only the second is unknown. * Support structured Claude when accounts are registered but none is selected Registered-but-deselected Claude accounts were refused, which is behaviourally identical to having no accounts at all: the auth policy does not strip, ambient auth is the truth, and the UI names no host identity. A user who deselected their accounts silently got legacy chat with nothing explaining why. Nothing selected for the host runtime is two states the settings cannot tell apart after the fact, because pruneInvalidClaudeRuntimeSelection empties the host slot and persists null in the second one: honest deselection -> ambient auth, UI names nothing -> SUPPORTED the WSL-only steady state -> ambient auth, UI names the WSL account -> REFUSED The presence of any WSL-bound account in the list decides. Simplifying this to "none active -> supported" re-opens the auth-identity misrepresentation, so the tests fail loudly on exactly that: five of them, across the unit rule and the createSupport path. * Stop treating an unanswerable create-support probe as a refusal A worktree is not resolvable for a beat after createWorktree resolves, so a probe fired immediately after creation fails the RPC with selector_not_found instead of answering. The catch collapsed that into `supported = false`, so the composer refused and quietly built a terminal session — the gate never said no, it was never asked successfully. Elapsed time was the only input that decided whether a Claude launch went structured. "Could not answer" and "answered no" are different states and only the second is a verdict. Retry while the host cannot yet resolve the selector, with a bounded backoff that covers the measured window with margin, and keep refusing on the first ask for everything else. Fail-closed is unchanged: a probe that still cannot be answered when the budget is spent refuses. The retry is narrowed with the shared error-code matcher, which classifies a token that transports re-wrap into a longer message without matching prose that merely mentions it. Codex never probes, so this race has never been able to refuse a Codex launch — the race itself is identical for it. Recorded at the early return, because whoever gives Codex a probe inherits the bug. * fix(claude): fence the forced sweep on re-derivation, not on lstart's second A descendant forked in the same wall-clock second as every walk that sees it was signalled with SIGTERM and then never escalated, so a SIGTERM-resistant child survived tab close, app quit and a full relaunch. Two children of one parent 96ms apart across a second boundary took opposite paths. The leak predates this branch: it reproduces with the change reverted. `ps lstart` has one-second resolution, so a walk landing inside a row's birth second can never rule out a pid recycled later in that same second. But a walk is not a match: a ppid walk only reaches what the root actually parents, and the root is pinned by Node's own handle, so a row the walk re-derived is ours whatever second it was born in -- a stranger would have to have been forked into our tree, and then it is not a stranger. Fence the escalation on that. Rows a merge retained from an earlier walk are not re-derived and still answer to the start-time fence, which remains correct for them. Scoped to callers that revalidate identity before signalling, which is the Claude close path. Codex teardown reaches this same verifier and is unchanged; the argument holds there too, but widening it is its own deliberate change. Also reverts two changes from the previous attempt at this leak. Advancing the capture boundary on a later walk is inert once the sweep fences on re-derivation -- both key on the same set of rows, so the new term short-circuits for exactly the rows whose boundary it advanced. The extra ladder refresh was a duplicate full process-table read: close() already awaits tree.refresh() immediately before proveClaudeChildExit, on the only path that reaches it. Known property: the kill lands roughly a grace window after the walk that proved membership, so a pid recycled inside that gap could in principle be signalled. It is bounded -- matchingSnapshotRows already requires the live row to carry the same start-second and pgid, so an impostor must be born in the remainder of that one second, land on that exact pid, and sit in the same process group, and it has already received the unfenced SIGTERM from the same loop. * Run the Claude structured integration suite as a runtime client The suite exercises agentSession.* for Claude, not the mobile surface: nothing in it asserts anything mobile-specific and its sibling integration suites use 'runtime'. Mobile now additionally requires the experimental structured-chat setting, which structured-agent-session.test.ts pins in both states, so the stale 'mobile' fixture was claiming coverage it never had. * fix(claude): report effort from get_settings, which is the only frame that has it The composer's Effort pill rendered blank in every structured session. This is not a missing source: the publication reads `effortLevel` off the `system/init` frame, and that frame has never carried an effort of any kind, while the correct value is already fetched at acquisition and thrown away on the auth diagnostic. Verified two ways -- a live get_settings probe against Claude Code 2.1.258, and the shipped binary's own init frame construction, which lists `model` and no effort. So `reportedOptions.effort` was always empty, the options reader dropped the key, and the pill had no value. Model survived only because `currentModelId()` has a fallback chain. The get_settings call acquisition already makes reports the session's current effort as `effective.effortLevel`; pass that into the publication instead. Selecting an effort already worked, so this is the arrival value only. The legacy PTY path is unaffected and must not be "fixed" to match: it reads its effort by parsing the startup banner (`CLAUDE_MODEL_EFFORT` in src/renderer/src/components/native-chat/claude-terminal-session-options.ts), which is why it shows a value where the structured path does not. Also removes the fixture that hid this: the fake init frame invented `effortLevel: 'high'`, a field the CLI does not send, which is why every gate stayed green over a value that is always empty in production. The fixture's get_settings now returns the real {applied, effective, sources} shape instead of a bare `{env: {}}`, so the two adapter tests that asserted an effort keep asserting it through the path production actually uses. The reader returns null rather than defaulting: an effort nothing measured would repeat the fixture's mistake, and a blank pill is the honest degradation if the provider ever renames the key. * fix(claude): only record an effort the child confirms it adopted apply_flag_settings answers `success` for an effort it then ignores. Measured against Claude Code 2.1.258: applying `bogus-effort-xyz` returns subtype "success" with no error while `applied.effort` stays at its previous value, and a valid `low` moves it. The option write treated the absence of a throw as adoption and recorded the requested value unconditionally, so Orca would show and persist an effort the child was not using, with nothing anywhere reporting a problem. Read the effort back after applying it, through the same reader the arrival value uses, and reject when the child reports a different one. A readback that could not be taken is not evidence of a refusal -- the apply itself succeeded -- so it still records; only a readback that disagrees rejects. Not reachable from today's picker, which offers catalog values only, but the CLI's effort catalog is server-delivered and has changed before, so a retired id would otherwise become a pill confidently displaying a setting that never took. * test(claude): assert the effort contract against the real binary The blank pill survived every gate because the only tests that touched it were fixture-backed, and the fixture invented the field. A test that pins the shape we read cannot catch the provider renaming the key, which is the failure mode that produced this defect. Asserts both halves against a live authenticated CLI: that no frame it publishes carries an effort at all, and that the session's current effort arrives through get_settings. Which frame proves the session varies by host -- this machine proves it with a SessionStart hook rather than a system/init frame -- so the negative half asserts over every published frame rather than picking one. Skips with the rest of the file when no authenticated CLI is present. * fix(claude): stop the synthesised content-part kinds leaking into the transcript Sending an image put a bare `claude · message:user:content:image` row between the user's bubble and the answer. Two causes, and only the second is a family. An image part counted as modelled only when `source.type === 'url'`, but claudeDispatchMessageContent sends a local attachment as a base64 source and the CLI replays that shape back, so every attached image was classified unmodelled. Accept the base64 and file sources Orca itself sends. The family is the real defect. `message:<role>:content:<type>` kinds are synthesised at runtime from whatever `part.type` arrives, so unlike the top-level frame catalogue they can never be enumerated ahead of time -- the `?? 'timeline-substantive'` default then prints the synthesised name at a user who cannot act on it. That default is right for top-level frames, where "substantive" means show the frame; here it meant show our own vocabulary, which drops the content AND leaks the opcode. So an unrenderable part now renders a sentence saying exactly that, with the kind and payload still on the row's disclosure. A part that carries its own readable sentence keeps it -- the placeholder is a fallback, not an override. An unknown future part type is therefore visible, never silently dropped and never printed as a kind: the same principle as the effort readback, which records only what the provider confirms. * Declare agentSession.requestHandoff on the cross-version wire surface The manifest is a ratchet for cross-version reachability, so the method is declared with real HandoffParams rather than counted. requestHandoff is capability-gated through requireStructuredHost and has no client caller, so declaring it is the whole of the change. Also model two host capabilities the harness omitted: the stub host's supportsCreate, and the fake adapter's, without which adapterSupportsCreate falls through to a supportsLocation the fake also lacks. Every ensure was refused for the harness's silence rather than for its location. * Gate structured Claude session tabs on the client capability that names them The Claude structured lane deleted the projection's `agent !== 'codex'` filter and added CLAUDE_STRUCTURED_AGENT_SESSION_RUNTIME_CAPABILITY in the same commit, but never wired the constant to anything. Paired clients then received agent-session tabs for Claude, which no shipped client renders -- mobile's resolveMobileNativeChat returns null for every agent but codex, so the row listed and selected into a pane with neither chat nor terminal. Restore the filter behind the declared capability instead of the bare agent name. No client advertises it yet, so this matches main's behaviour today and becomes a negotiation a future client can opt into. * Confirm the structured Claude model against the model the CLI reports set_model answers success for any string, including a model it cannot resolve — the failure only surfaces when the turn runs — and get_settings reports the settings-file model, not the session's. The init frame that opens each turn is the only channel carrying the adopted model, so keep the session's reported model current from it instead of reading it once at acquisition. Also stop rejecting an effort the readback cannot represent: max is session-scoped and excluded from the persisted effortLevel, so a readback reporting the level underneath it is an absence of evidence, not a refusal. * Clear the session-option hedge when the provider confirms the value The pill claimed every option was unconfirmed for the life of the session: the renderer recorded each write as dispatched and nothing ever moved it, so a model the CLI had already reported back still read as unconfirmed. Carry the provider's own confirmation to the surface. Main reports which option ids the provider named rather than merely accepted, and the client re-reads options as a turn changes, because the frame that opens a turn is where the adopted model arrives. A value the provider has not reported stays hedged, including an effort whose readback could not be taken. The confirmed list is optional on the wire: a host that predates it sends nothing and the client keeps hedging, which is the behaviour it had. * Keep the model report current across an acquisition fence bump * Show the picked session-option value and let the provider report correct it The pill showed a "not confirmed" second tooltip line for any value we had sent but not yet seen reported back. Nothing acts on it, and for the PTY lane it was permanent — that transport has no report channel. The pill now shows the picked value immediately and the provider's per-turn report corrects it when the two disagree; a newer local write still outranks a report that precedes it. `dispatched` stays as a provenance member rather than collapsing into `applied`: it is produced independently by the PTY lane, and it is where the `confirmed` wire field lands, which would otherwise be unobservable. Effort keeps its readback and its rejection path. That matters more now, not less: with the hedge gone the rejection is the only user-visible failure signal on this surface, so a spurious one would be the loudest bug here. Skipping the readback for an effort the settings response structurally cannot echo is what prevents it — the response carries the persisted level, so reading it back for a session-scoped value would report the level underneath and fail a valid write. * Hedge a session-option value only when the terminal transport sent it Both lanes emit `dispatched`, so it could never say which one produced a value. The descriptor now carries the transport that built it, set once in the shared snapshot builder from a parameter that is required rather than defaulted — the builder is the only place a descriptor is constructed, so a new producer has to name its lane or fail to compile. The structured lane confirms every value from the provider's own per-turn report, which makes the hedge transient noise there. The terminal lane can only learn an outcome by parsing the screen back, and only for Claude: every other agent's `dispatched` value stays unconfirmed for the life of the session, so the line is the only signal that we sent something we never saw land. * Refuse an effort the session's model advertises no control for * Refuse tab mutations on a Claude row the client never negotiated The branch added a case asserting a client advertising only agent-session.structured.v1 may mutate a claude row. That is the same ungated behaviour the projection gate removes, encoded a second time — mutation authorization reads the projection, so hiding the row refuses the write. Assert that contract instead, and add the positive case for a client that does negotiate Claude rows. * Resolve the Claude session's current model in one place so the effort guard and the pill agree * Record an effort the child did not adopt instead of refusing the write apply_flag_settings answers success for an effort it then ignores, so the readback exists to detect that. Refusing on it made the detection a veto, and a veto is only correct if the readback can never be wrong about which model is current -- which it was, twice. The pre-flight guard already refuses a level the model advertises no control for, so the veto guarded a door that is now locked upstream. Keep the detection, drop the refusal: a disagreement records the child's own answer and omits the option from confirmed, so main stops vouching for a value the provider rejected without blocking the user's write. * Stop a slow whole-machine ps from being read as an absent process `ps -axo ...command=` pays a per-pid argv read: measured 1.15s for 1,948 processes (0.03s without `command=`), and CPU contention stretched the same capture to 6.0s. Two budgets sized for a cheap look then misreport a readable machine. The reader's 3s ceiling killed 6 of 20 consecutive captures at load 27, so every consumer answered "unverifiable" about a table it could read. Raise it to 15s, and stamp the capture instant at ps START so `capturedAgeMs` is the upper bound its contract promises -- a 6s capture used to report itself as freshly taken, understating staleness against a 5s kill gate. The TTL keys on completion so a slow capture still coalesces instead of forking ps per caller. `readStructuredTuiProcessIdentity` then spent its whole 5s wait inside one capture and concluded "no exact child" after a single look taken before the child existed (observed landing at ~3.5s). Absence needs a look that did not race the spawn, so require two captures before the deadline can end the loop. Both surfaced by the real-binary Claude TUI resume test, which failed ~1 in 5 under load; 14/14 now, 8 of those runs containing a capture the old 3s budget would have killed. * Let the desktop renderer negotiate Claude structured tabs The paired-client gate hides agent-session rows an agent the client cannot render. The desktop renderer's own IPC dispatches as clientKind 'runtime' advertising only agent-session.structured.v1, so the gate hid Claude rows from the surface this feature ships on. It renders them; it should say so. * Stop a slow process table from silently blinding every freshness gate Stamping `capturedAgeMs` at ps START made the number honest, and honest broke both consumers that read it. `ps -axo ...command=` measured 2.5-9.0s on an idle 2,002-process laptop and 4.0-18.6s at load 46, so the age it now reports lands past every budget: `planRelayPtySweep` refuses the stop as "too old", and the renderer's `admitRemoteForegroundEvidence` refuses the record outright. That second one is the expensive half and was outside the diff -- a refusal bumps `consecutiveInspectionErrors`, the poll scheduler backs off to its 10s floor, and agent-completion detection stops for the pane. The subsystem went blind on exactly the loaded hosts the honest stamp was meant to serve. The evidence-publishing read now gives up at 1,200ms instead of waiting out `PS_TIMEOUT_MS`. It is one budget for one question: these consumers ask whether an observation describes NOW, and past this it does not -- a late answer is refused by the age gate anyway, having first blocked a polled path for the whole capture, so a prompt `unverifiable` is both the truthful verdict and the cheap one. Both relay call sites already produce it from a rejection, and an admitted `unverifiable` costs a poll where a refusal costs the cadence. Identity proof keeps the full 15s through `getFreshProcessTableSnapshot`, because it asks whether a process EXISTS and must never read slow as absent. The budget bounds the wait, never the capture: the reader coalesces, so an abandoned wait leaves its capture running to fill the cache rather than forking a second whole-machine `ps` on the host that can least afford one. 1,200ms is bracketed rather than picked. The floor is the capture's own cost -- `command=` measured 1.15s for 1,948 processes on an idle host, and a budget under that answers `unverifiable` about a machine nobody is straining. The ceiling is the consumer's: 2,000ms, less the 500ms a TTL-shared capture may already have aged, leaves 1,500ms, and transit takes the rest. That ceiling only fits once the capture stops being charged twice. `ps` runs inside the RPC round trip, so its duration is already in `receiveDelay`, and `capturedAgeMs` is that same duration on the host's clock; summing them halved the budget this gate grants a host from ~2.0s of `ps` to ~1.0s, which is why a 1.2s capture arriving at 1.3s read as 2.5s old and was refused. Admission now takes the larger of the two. The sweep's gate keeps its sum, which is correct there: `evidenceAgeSinceListingMs` is stamped after the listing ARRIVES, so it measures planning time and overlaps nothing. A stated limit rather than an assumed one: 15s is not proven sufficient for identity proof. The same capture reached 18.6s at load 46, so that path can still time out and answer "no exact child" about a host it simply could not read in time. Narrowing it needs a cheaper question than a whole-machine argv read, not a larger number. The one test guarding this field could not fail. `beginPtyHandlerTest` installs fake timers, so `Date.now()` is frozen, the real reader reports exactly +0, and `0 <= 500` held identically for a hardcoded zero, for completion-stamping and for start-stamping -- while the real reader on that host returns thousands of ms. It now drives a measured age in and asserts the handler publishes it rather than restamping; that the reader MEASURES it correctly stays pinned separately, against a controllable clock. Both consumers get boundary coverage either side, and each new gate was ablated red before it went green. * Keep the compatibility fields off the capture the budget just abandoned inspectProcess falls back to processHasChildren and listProcesses to getForegroundProcessName, and both read the same TTL-shared capture with no budget of their own. On a slow host they joined the in-flight capture the budgeted evidence read had just given up on, so the call still blocked for the full 6-18s and the budget bought nothing -- once for inspectProcess and once per managed PTY for listProcesses. Use the degraded answers those helpers already give for an unreadable table, reached promptly. pty.hasChildProcesses keeps its unbudgeted fresh probe: it is a one-shot destructive gate that can afford to wait. --------- Co-authored-by: Merge Sim <merge-sim@local> Co-authored-by: Merge Sim <sim@local>	2026-09-04 15:55:20 -07:00
Jinwoo Hong	aa78d4af17	fix(release): restore version and harden staging confirmation ... Resolves release scan blockers STA-6611 and STA-6612.	2026-09-03 16:53:32 -04:00
Jinwoo Hong	3eec77c11a	chore(cloud): add the relay fence broker, ops console, Terraform root, scripts, and 24 cloud-* workflows (#18413) ... Phase 6 of the relay split: the relay's deploy/operate surface moves under cloud/ with 24 cloud-* workflows gated on ORCA_CLOUD_OPERATIONS_ENABLED, the Cloud SQL rollout lease action, the relay Terraform root (dual-accept identities for both repositories), scripts, docs, CODEOWNERS, and a terraform validate job in Cloud Verify.	2026-09-03 06:55:14 -04:00
Neil	968dbd905f	perf(renderer): take the English catalog and the xterm WebGL addon off the boot graph (#18326) ... * perf(renderer): take the English catalog, xterm WebGL addon and emoji data off the boot graph The renderer's boot graph — the entry chunk plus its 331 modulepreload links, all fetched and evaluated before first paint — carried three payloads nothing needs at that moment. `en.json` (644 KB) was an eager i18next resource, but every renderer string goes through `translate(key, fallback)` and `en` resolves that inline default, so most of the catalog was dead weight. The renderer now bundles a generated `en-runtime-required.json` holding only the 2,583 of 13,828 entries a default cannot reproduce: plural-suffixed keys, keys whose catalog value differs from a call site's default, and keys no call site references with a literal default. `en.json` stays the translator source and the input to the four lazy catalogs. `@xterm/addon-webgl` (243.6 KB) and `emojibase-data` (170 KB) are now primed right after the React root renders instead of statically imported. The load stays eager and `attachWebgl` stays synchronous — it reads the resolved constructor — so no terminal ever falls back to the DOM renderer for a frame. `isPluginPanelTabKey`/`isQualifiedPluginKey` move to schema-free sibling modules, re-exported from `plugin-manifest.ts`. This evicts the plugin manifest schema graph from the boot chunk but measures ~0 KB, because six other shared modules still put zod on the boot path. Boot graph: 332 chunks / 5107.2 KB -> 336 chunks / 4161.5 KB (-945.7 KB, -18.5%). A new ratchet parses the built index.html and fails if `en.json`, `@xterm/addon-webgl` or `emojibase-data` is preloaded again; it runs at the end of every `build:electron-vite`. * chore(i18n): pin the generated English subset to LF and mark it generated * fix(i18n): make the runtime-catalog gate merge-robust and prime emoji data in tests CI builds the merge of a PR with main, so a byte-for-byte comparison against a committed generated file fails the moment any unrelated PR adds a translate() call — which is what happened here. The check now asserts the property that actually matters instead of byte equality: every runtime-required entry is shipped, and nothing shipped disagrees with en.json. Entries that stopped being required are dead weight, never a wrong string, so they are reported and tolerated. Failures now name the offending keys rather than saying "stale". The generator itself was already deterministic (plain code-unit sort, no locale collation, order-independent set construction); a test now pins that a reversed call-site walk produces byte-identical output. Test fixes for the catalog prune and the deferred emoji load: - browser-search / NativeChatSupportedAgents asserted key presence on the renderer's runtime resource. The durable contract is en.json — the renderer deliberately no longer bundles entries a call site default reproduces — so they assert against the translator catalog. - Four emoji tests typed a shortcode in the same tick as mount, before the catalog the hook primes on mount resolves. Not reachable by a human; the tests now await the prime. * revert(renderer): keep the emoji shortcode catalog statically imported Deferring emojibase-data introduced a window that did not exist before: until the dynamic import settled, getPrimedEmojiShortcodeEntries returned [], so exactShortcodeIndex built an empty map and replaceCompletedWorkspaceEmojiShortcode returned null — leaving a typed `:wink:` in the field literally, and persisting it as the workspace display name. Pre-change the shared catalog was statically imported, so the first call at any tick returned full data. The window is reachable by anything that dispatches input in the same task as the field's mount effect — Playwright/CDP in the e2e suite and agent automation both do, and the WorktreeMetaDialog test failure was exactly that, producing 'Feature 😉' instead of 'Feature 😉'. Nothing that resolves a shortcode can be async without that race, and a wrong persisted name is not an acceptable trade for 166.7 KB, so the deferral is reverted rather than papered over in the tests. The boot-graph ratchet drops its emojibase-data probe and records why. Boot graph: 5108.9 KB -> 4329.9 KB (-779.0 KB, -15.2%), down from -945.7 KB. * fix(terminal): make the deferred WebGL addon load recoverable and refit on late attach Two defects the deferral introduced, neither possible with a static import. A failed load latched the DOM renderer for the whole session. `.then(onOk, onError)` settles fulfilled, so the memoized promise was cached forever with a null constructor: attachWebgl's re-prime got the cached promise back, and resetTerminalWebglSuggestion — the documented "GPU setting changed, retry" path — could not clear it either. The rejection path now clears the memo, latches the queued panes the way a failed construction does so they retry at a recovery boundary rather than every frame, and caps attempts so a genuinely missing chunk is not re-fetched forever. The recovery boundary re-arms it. The queued-attach drain skipped the refit. Every other late-attach path pairs attach with a refit because the grid was measured under DOM cell metrics and WebGL floors the device cell width. Post-deferral, openTerminal's attachWebgl queued and returned, the initial fit rAF then measured DOM metrics and sized the PTY from them, and the addon attached with no refit — a persistently narrow PTY and an unpainted right gutter, not a one-frame flicker. Both paths now go through one attachWebglAndRefit pairing so they cannot diverge again. Regression tests cover both, and each was verified to fail without its fix. The addon-load state machine moves to terminal-webgl-addon-loader.ts and the viewport presentation helpers to pane-viewport-present.ts, keeping pane-webgl-renderer.ts under the 300-line budget without a suppression.	2026-09-03 00:26:30 -07:00
Neil	f37d2fec97	fix(linux): land the reviewed Linux packaging stack on main (#18100) ... * fix(linux): give the CLI one entrypoint by extracting the AppImage once * refactor(linux): trim AppImage CLI registration seams * test(cli): assert registration lock serialization * fix(linux): fence AppImage terminal shim mounts * fix(linux): accept extracted AppImage runtimes with APPDIR only * docs(linux): make headless AppImage extraction runnable * refactor(linux): import bundled launcher directly * fix(linux): reclaim superseded AppImage payloads and packaged symlinks Pruning removed 3215 of 3216 files from a superseded generation and always stranded resources/app.asar, leaking ~105 MB per version update. Electron's asar shim reports a *.asar file as a directory, so the recursive remove tried to rmdir a real file and failed with ENOTEMPTY; the .catch(() => {}) hid it. Reproduced end to end on Ubuntu 24.04: 519M -> 623M across one update, and 519M again once the payload is actually reclaimed. removeExtractedAppImagePayload holds process.noAsar for the removal, counted so overlapping removals cannot hand the shim back early, and the prune site now warns with the path instead of swallowing the rejection. All three removal sites use it -- staging cleanup and displaced roots leaked the same way. Also reclaim symlinks left by a packaged deb/rpm install, which the extracted-cache-only rule turned into a hard conflict on a deb -> AppImage migration, and name the remedy in the conflict error. * fix(linux): bound the CLI registration lock wait `retries: 1000` caps the attempt count, not elapsed time, so at up to 1s per attempt an IPC-driven registration could hang ~16 minutes against a wedged holder with no feedback. A legitimate holder is bounded by the extraction timeout, so wait that plus slack and then fail with a message naming the lock file, rather than hanging. `maxRetryTime` is forwarded verbatim to the `retry` package by proper-lockfile. * fix(linux): stop re-extracting the AppImage on inode metadata churn The extracted-payload cache key hashed ctime alongside dev/ino/size/mtime. ctime moves on any inode metadata write -- `chmod +x`, which every AppImage user is told to run, plus `chown`, an ACL or SELinux relabel, and a backup restore -- none of which alter a byte of the payload. Measured on Ubuntu 24.04: `chmod +x` leaves dev, ino, size and mtime identical and moves ctime alone, so the key changed and the next launch paid a full ~519 MB re-extraction and a multi-second stall to rebuild a payload it already had, then pruned the old generation. Key on content identity instead. An in-place content change moves mtime and almost always size; a replacement moves the inode. The existing replace-in-place test still passes. * fix(linux): stop CLI commands from falling through to Chromium startup * refactor(cli): remove redundant command membership check * test(cli): cover command-named project selectors * fix(cli): redirect the open-url command before startup * test(linux): cover AUR serve wrapper flags * fix(linux): tighten CLI launch detection * fix(linux): respect CLI flag value boundaries * fix(linux): strip injected Chromium switches from CLI args * fix(linux): report a missing display instead of dying in uv_close * refactor(linux): read display locks without a preflight race * fix(linux): preserve unverified external displays * chore: format reliability gate manifest * test(packaging): split runtime resource checks * fix(linux): fail serve when no display is available * fix(linux): do not treat a lockless X socket as a dead display An X server writes its lock beside its socket and both survive a crash (verified against Xvfb under SIGKILL), so a socket with no lock was never left by a crashed server. It is an endpoint published from elsewhere: a container bind-mounting only /tmp/.X11-unix, WSLg, or a foreign PID namespace. Declaring those dead made the desktop gate exit(1) on displays that work, with no workaround, and the serve gate refuse to start. Liveness now splits by ownership. A foreign DISPLAY trusts a lockless socket; Orca's own :99 does not, because removeStaleDisplayArtifacts unlinks the lock before the socket and so manufactures that state itself -- adopting it would resurrect the orphan-socket bug and stop the cleanup from self-healing. The stale-lock rejection is unchanged. Also correct four doc statements this behaviour falsified. * fix(linux): fail closed when a stale socket blocks the Xvfb rebind Readiness only checked that /tmp/.X11-unix/X99 exists. A stale socket we could not unlink still exists after our own Xvfb refused to bind, so Orca set DISPLAY to a dead server and Chromium died in Ozone init. Measured on Ubuntu 24.04 against the pre-fix build: with a leftover :99 socket and no lock, serve exits 139 (SIGSEGV), the socket inode is unchanged before and after, and no lock is recreated -- it neither cleaned up nor respawned. To a user that is a crash, not a misconfiguration. This is reachable in the documented topology, where orca-xvfb.service has no User= and runs as root while serve runs as User=orca: /tmp is sticky, so the orca uid cannot unlink a root-owned socket, rmSync fails, and Xvfb exits with the display already active. Readiness now requires the display to actually be live -- our socket plus a lock naming a running process -- so the same state reports an unusable display and exits 1 with the existing diagnosis. * fix(linux): recognise abstract X sockets and inherited Wayland fds Two display setups this gate could not prove were refused outright, and on the desktop path that is app.exit(1) with no workaround. An X server may bind only the abstract namespace (`@/tmp/.X11-unix/X0`), which leaves no filesystem socket to stat. Abstract addresses are kernel-owned and vanish the moment the owner exits, so an entry in /proc/net/unix is proof of a live server -- no lock file needed and no stale entry possible. Verified on Ubuntu 24.04, where 139 such addresses were present. WAYLAND_SOCKET is an already-connected fd handed over by the compositor, so there is no path to stat and WAYLAND_DISPLAY may be unset entirely. Its presence is the display. Both are consulted only after the filesystem-socket check fails, so no existing verdict changes. * fix(linux): never treat Orca's own display number as a foreign endpoint Recognising a lockless X socket as live is correct for an endpoint published from elsewhere -- a container bind mount, WSLg -- because an X server writes its lock beside its socket and both survive a crash. It is wrong for VIRTUAL_DISPLAY_NUMBER, because Orca's own teardown unlinks the lock before the socket and so manufactures that exact state. The managed branch was already strict, but a caller that sets DISPLAY=:99 explicitly takes the foreign path and skipped it, accepting a dead display left by Orca's own interrupted cleanup. Route the managed number through the strict probe on both paths. Found by an adversarial audit of the asymmetry introduced earlier in this branch; the documented systemd topology is unaffected because its Xvfb writes a real lock. * test(linux): add a packaged-artifact contract for the CLI launch paths * test(linux): avoid buffered serve readiness detection * test(linux): signal AppImage serve owner directly * test(linux): tolerate readiness timeout boundary * test(linux): add startup margin to shutdown oracle * ci(linux): give package contracts timeout headroom * fix(ci): route all Linux packaging contract changes * test(linux): poll shutdown readiness without tail leaks * test(linux): bound shutdown cleanup grace * test(linux): assert on CLI output, not the harness's own control lines run-cli-case.sh echoes `RESULT status=N case=<name>`, and the two cases named *-skills asserted `expectOutput: 'skills'`. That substring was satisfied by the case name in the harness's own line, so 2 of 8 cases asserted nothing about the command -- gutting `skills` entirely would still have gone green. Control lines are now excluded before matching, and both cases assert the rendered help header, which only real help output produces. Verified on an Ubuntu 24.04 host: 8/8 still pass against a stack-tip AppImage. Also register the gate in reliability-gates.jsonc, which #15085 added a CI Docker gate without. Red/green is recorded from a stock release AppImage failing 4 of 8, three of them at status 133 (SIGTRAP). * fix(linux): require static AppImage runtimes (#17319) * test(linux): reject a wrong-architecture native binary at packaging time Cross-building the arm64 slice on an x64 host silently packed an x86-64 `pty.node` -- the rebuild logged "Forcing native rebuild for linux-arm64" and shipped the host's binary anyway. Every gate here inspects symbol versions, which are perfectly valid on the wrong architecture, so nothing noticed. Observed on a Raspberry Pi 5: the packaged app loaded, then failed with "Failed to load native module: pty.node", and the launch contract reported 3 of 8 cases crashed rather than naming the cause. Swapping in the aarch64 `pty.node` took the same build to 8/8. Compare ELF `e_machine` against the slice being packaged and fail with the offending path. Checked before the glibc pass, because a wrong-architecture binary's symbol versions are valid but meaningless and would send the reader down the wrong path. Release CI builds arm64 on a native runner, so this guards local and future cross-builds rather than a shipped artifact. * test(linux): judge per-arch vendored binaries against their own path The first CI run of the architecture gate failed the x64 package job on `@parcel/watcher-linux-arm64-glibc/watcher.node`. That binary is arm64 on purpose: the package ships every architecture and its loader picks the match, so its presence in an x64 build is correct. Judge a binary against the architecture its own path names, falling back to the slice when the path names none. That keeps the case this gate exists for -- `bin/linux-arm64-*/node-pty.node` holding an x86-64 binary, which is what shipped to a Raspberry Pi 5 -- while letting multi-arch dependencies through. Dry-run over the real dependency tree flags nothing for either target arch. * fix(linux): move deb/rpm update installation outside Orca (#17318) * fix(linux): complete deb/rpm package metadata * fix(linux): preserve CLI link during package upgrades * docs(linux): document local RPM build prerequisites * fix(linux): move deb/rpm update installation outside Orca * fix(updater): preserve Linux recovery across stale events * fix(updater): fence stale downloaded events by active target * fix(updater): preserve active Linux package recovery * test(linux): keep workflow order assertion in scope * test(updater): assert stale recovery stays silent * fix(updater): preserve Linux package recovery after checks * refactor(updater): keep Linux marker message with status * fix(linux): describe the right manual update path for deb/rpm hosts A remote host installed from .deb or .rpm now reports manual-service-update-required, and the guidance told the operator to "update through the service manager that starts this server" -- which is correct for unsupported-headless-serve but wrong for a package install, where nothing about the remedy involves the service manager. Say both, keyed on how the host was installed. * docs(linux): document orcad update restart safety * docs(linux): scope restart census omissions * docs(linux): use absolute service CLI launcher * fix(serve): validate in-process serve options before startup (#17683) * fix(linux): stop offering updates a distro-managed install cannot apply (#17918) Closes #17702. The resources/package-type marker is authoritative but never checked against the host, so any repackager that unpacks Orca's .deb -- AUR, Nix, a container rebuild -- inherits `deb` verbatim. Install feasibility was then computed after a ~165 MB download, so those users got check -> download -> a card promising an install command -> a dead end. Validate the marker against the host: a deb/rpm marker with no matching package manager in the trusted directories means a package manager owns this install. This reuses the exact lists and resolver that buildLinuxPackageInstallCommand already loops over, so a false positive is impossible by construction -- any host flagged here would have failed with no-package-manager after the download anyway. The gate only moves that verdict earlier. Verified across Debian 12, Ubuntu 24.04, Arch, Fedora 40 and openSUSE Leap: no false positive on a real deb host, correct on every repackaging host. The release is still reported, because the user does want to know 1.4.194 exists and to update through their distro; only the download path is closed. `externallyManaged` is an additive optional field on the existing `available` status, so older paired clients decode it unchanged. downloadUpdate() refuses authoritatively, since main owns this verdict rather than the card, and unwinds any pinned-build state first -- a Linux pinned jump resolves to 'release', and stranding isPinnedBuildActive would silently kill every background check for the rest of the process. Note the fix the issue suggests cannot work: electron-updater builds a PacmanUpdater whose doDownloadUpdate looks for a .pacman asset Orca does not publish, then dereferences undefined. * style(cli): restore prettier wrapping on install error copy * test(linux): re-pin the child-process ratchets and the batch-shim allowlist after the merge	2026-09-02 03:08:01 -07:00
Neil	b94a65a4fc	fix(lint): preserve TaskPage effect suppressions after split ... (cherry picked from commit 4a3bc23670)	2026-09-01 00:06:23 -07:00
Neil	2e30187560	feat(dev): sweep the backlog of idle dev Electron bundles (#17803) ... * fix(dev): make reclaim report real sizes on Windows and keep setuid intact Two bugs found by running the reclaim script on real Linux and Windows hosts. The size report shelled out to `du`, which does not exist on Windows, so every worktree measured 0 bytes and the script reported nothing reclaimable on the platform with the largest dist (374MB). Walk the tree in Node instead. makeTreeReadOnly chmod'd files to a flat 0o555, which clears setuid. On Linux that would silently strip the bit from chrome-sandbox if a developer had run the usual `sudo chown root && chmod 4755` workaround -- and under hardlink sharing it would strip it from every worktree and the cache at once. Clear the write bits and nothing else. Measured after the fix: 7.30 GiB across 23 worktrees on one Windows host and 18.31 GiB across 56 on another, both previously reported as 0. * feat(dev): sweep the backlog of idle dev Electron bundles out/electron-dev holds one ~275MB patched Electron.app per branch title x Electron version. The dev runner already prunes them, but only inside the worktree it is starting and only when that worktree holds more than one bundle -- and a worktree almost always holds exactly one, so the sweep returns early every time and nothing ever reclaims another worktree's bundle. pnpm reclaim:dev-bundles sweeps across every worktree of the repo. Bundles are pure build output that pnpm dev rebuilds on demand, and rebuilding is cheap now that the Electron dist is shared. Reuses the runner's own staleness rules, so a bundle a live process is running from, or one whose build is still in flight, is never removed. Refuses to run at all if the process table cannot be read, rather than guessing. Measured: 120 bundles, 32.2 GiB, on one machine. Also guards both reclaim scripts behind a direct-invocation check; importing one for tests previously ran a full sweep at import time.	2026-08-31 22:18:50 -07:00
Neil	fe0f2f9be7	perf(dev): share one Electron dist per repo instead of per worktree (#17664) ... * perf(dev): clone one Electron dist per repo instead of per worktree Every worktree extracted its own ~295MB node_modules/electron/dist, measured at 69GB across 241 worktrees on one machine. Extract once per repository into <git-common-dir>/orca-cache/electron, then APFS-clone it into each worktree: copy-on-write, so the second worktree allocates ~0 bytes and still gets a real, private, writable directory. Hangs off install-electron-package-binary.mjs, inside the transaction it already uses to swap dist. Every cache path returns a boolean and false means "install normally", so non-APFS, cross-volume, corrupt entry, no Git, folder workspace and CI all keep today's behavior. No symlinks, no lifecycle changes. out/electron-dev's per-branch Electron.app copy clones too, via the same helper. Refs #13709 * perf(dev): share the Electron dist on Linux and Windows too Extends the shared dist cache beyond macOS APFS. Three mechanisms, strongest isolation first: macOS APFS cp -c private copy-on-write Linux btrfs cp --reflink private copy-on-write ext4 / NTFS hardlink + 0555 shared inodes, forced read-only Reflinks cover btrfs/XFS/bcachefs/ZFS but not ext4, and Windows block cloning is ReFS-only, so most Linux and effectively all Windows developers need hardlinks to get any saving at all. Extracted dist is 327MB on linux-x64 and 374MB on win32-x64, both larger than macOS. Hardlinks share inodes, so a write through one worktree would rewrite every sibling and the cache. Nothing in this repo writes inside dist -- every mutation replaces the directory via rename -- but Electron's own install.js extracts over an existing dist with O_TRUNC, and is reachable through `pnpm rebuild electron`. Publishing the entry read-only turns that from silent cross-worktree corruption into EPERM. Directories stay writable so the install transaction's renames and unlinks still work. out/electron-dev's per-branch Electron.app is patched and codesigned after it is copied, so it uses copyPrivateTree, which never hardlinks. Refs #13709 * test(dev): keep shared-dist tests honest across ext4 and NTFS Verified on real hardware: Ubuntu 24.04/ext4 (no reflink support, so the hardlink tier is the only thing that helps there) and Windows/NTFS. Three tests faked platform: 'darwin' while invoking the real mechanism, so they failed on Linux where /bin/cp -c does not exist. Mechanism selection is now asserted with injected stubs; real filesystem behavior is asserted against whatever the host actually supports. Windows maps chmod onto the read-only attribute alone, so a directory never reports 0o755 and a read-only file reports 0o444. Mode-bit assertions that encoded POSIX semantics are now behavioral (the tree stays removable), and the executable-bit assertion is POSIX-only -- confirmed on NTFS that a read-only hardlinked .exe still runs. * fix(dev): stop a losing publisher from discarding a good cache entry Greptile caught a TOCTOU in the shared Electron dist cache. Quarantining an invalid entry happened before sharing the replacement tree, which takes seconds -- long enough for a sibling worktree to publish a good entry that this one would then rename away. If the follow-up publish also failed, the cache was left empty and every worktree re-downloaded. Stage first, then re-validate immediately before the destructive rename, so an entry that became good during the share is kept. On a failed swap, restore the quarantined entry instead of leaving no entry at all: a stale entry still beats an empty cache, because the next publisher re-validates and replaces it. An entry that cannot be validated is never displaced, matching the pre-staging rule. Also covers the Electron upgrade path end to end: a version bump gets its own cache entry and leaves the previous one for worktrees still on the old branch. * feat(dev): add a script to share existing worktrees' Electron dists An install only shares when Electron is (re)installed, and rebuild-native-deps returns early when the package is already usable -- so a worktree that already has a working dist never reaches the sharing path and keeps its own copy until the next Electron upgrade. pnpm reclaim:electron-dists reports what it would share; --apply does it. Each worktree is converted behind a rename, so an interrupted run leaves a working dist either way, and any worktree that fails is left untouched. Measured on one machine: 677 worktrees, ~195 GiB reclaimable. * fix(dev): keep the reclaim script's error formatting type-safe	2026-08-31 20:35:54 -07:00
Neil	a5796ec8eb	refactor(runtime): split OrcaRuntimeService and compatibility tests (#17605) ... * refactor(runtime): split OrcaRuntimeService into focused modules * test(runtime): cover admission tiers and strict worktree reconciliation * fix(runtime): preserve owner and structured session visibility * fix(runtime): port post-extraction compatibility fixes * fix(runtime): preserve skill-share cancellation barrier * test(runtime): update identity inventory after extraction * fix(runtime): preserve hook transport environment cleanup * fix(runtime): consolidate idle probe imports * test(runtime): retire split file process allowlist entry * fix(runtime): route child process types through shared boundary * test(runtime): preserve worktree host metadata precedence * fix(runtime): update extracted test seams * fix(runtime): gate the split's ts-nocheck set and restore the stop-confirmed contract Audit follow-ups for the OrcaRuntimeService split: - Freeze the 171 @ts-nocheck files behind a ratchet so no new file can disable type checking. The split's linear mixin chain cannot express forward references yet, so the existing suppressions are grandfathered; the baseline may only shrink. - Drop the stray @ts-nocheck at the end of orca-runtime-get-status.ts. It sat after the first statement, where TypeScript ignores it, so the module was already checked. - Restore `retireRejectedPty(ptyId, stopConfirmed: boolean)` as a required argument. The split widened it to optional and patched the resulting error with `stopConfirmed === true`; an omitted argument would have silently taken the unverified-stop path instead of failing to compile. - Guard that every orca-runtime-tests fragment is imported by the compatibility entrypoint. The fragments are .spec.ts, which no Vitest include glob matches, so one left out of the list would silently stop running. * fix(runtime): restore four behaviors the OrcaRuntimeService split dropped Audit findings against the refactor's true base (ad5ba2572e): - retirePtyAgentLaunchAuthority collected pane keys after deleting the restored-authority receipt instead of before it. collectPaneKeysForPty reads that receipt, so a receipt-only pane lost its key and never had its agent-hook compatibility authority retired. on-pty-exit.ts already carried a comment naming this exact invariant. - The PTY-exit path kept orchestrationMailboxNotifications.retirePty but lost the loop that schedules a debounced mail-pointer repoint for the dead pty's terminal handle and any run bound to its panes. Restores the schedule call count to 7, matching base. - subscribeToPtyExit lost isPtyKnownExited's leaf fallback and its post-registration lifecycle-generation recheck. leavesByPtyId is rebuilt from the renderer graph independently of ptysById, so a leaf can outlive its pty record; without the fallback a caller waiting on an already-dead pty never gets released. - The chain root declared `[key: string]: unknown`, which base had nowhere. It leaked through the exported runtime type into every consumer, so any misspelled member access typechecked as unknown instead of erroring, and it accounted for 957 of the suppressed errors. Removing it costs zero type errors. * fix(runtime): restore escalation prose and unscoped automation publication Two more behaviors the split dropped, each with a regression test that fails against the pre-fix code: - The worker-exit escalation stopped deriving its title through buildOrchestrationTaskDisplayMetadata and inlined `task.spec` instead. That ignored an explicit task_title, dropped the single-line normalization and the 80-character bound, and turned the no-spec case into a quoted, duplicated id. A multi-paragraph spec landed verbatim in the coordinator's banner. The existing 11 tests all use short single-line specs, where the derived title and the raw spec are identical, so none of them could see it. Also reverts an added `if (!handle) return` guard: the dispatch lookup is deliberately keyed on the pane as well, because a reminted handle no longer matches the row while the pane identity outlives the remint. - updateAutomation stopped going through automationChangePublications and published `source` unconditionally while gating the fallback on a non-null destination. A destination the store can no longer name then published only the stale source, so subscribers scoped elsewhere kept rendering a row that had left them — the exact case the helper documents. The helper had been left with zero callers; all three sites use it again. * fix(skills): stop swallowing lookup errors and hard-erroring on non-ssh hosts Follow-ups from auditing the skill install path against the refactor's base: - resolveWorktree wrapped showManagedWorktree in `.catch(() => null)`, so a transient git or IO failure surfaced to the user as skill-install-workspace-not-found with the real cause discarded. Errors propagate again; a genuine id mismatch still returns null. - resolveSkillSshTarget threw skill-install-workspace-host-unavailable when the execution host was neither local nor ssh, on both the repo and folder branches. Base gated these on connectionId, so a runtime-owned repo simply was not an SSH install and fell through to the local path. Both return null again, and the error code the split invented is now unreferenced. - listManagedSkillInstalls awaited the receipt walk and the worktree resolve in sequence. They are independent and either can hit disk, WSL, or an SSH scan, so Promise.all is restored. Deliberately unchanged: resolving the worktree through listResolvedWorktrees rather than showManagedWorktree, which disambiguates a worktree id colliding across hosts and is covered by its own test, and the SSH-folder skill-install-ssh-dispatch-required throw, which matches the repo branch. * fix(runtime): merge duplicate worktree-logic imports The #17448 port added a third import from ../ipc/worktree-logic, which the code-quality oxlint config rejects under --deny-warnings. Plain oxlint does not flag it, so it only surfaced in CI's static analysis job. * ci: run the ts-nocheck ratchet in PR checks pr-workflow-lint-parity requires every leaf command in `pnpm lint` to have a matching step in pr.yml. The ratchet was wired into lint but not the workflow, so PR CI would not have enforced it. * Merge remote-tracking branch 'origin/main' and retry the paired-host launch evaluate main advanced 9 commits; none touch the orca-runtime.ts this branch splits, so nothing needed porting. CI failed twice on `Execution context was destroyed` thrown from headless-paired-runtime-host's first `evaluate` after launch — a different spec each run, which is the signature of the flake #17780 describes rather than a regression. That commit added retryTransientMainEvaluate and adopted it in five helpers but not this call site, even though its docblock names exactly this case: the first evaluate after electron.launch() resolves, before the app is ready. Wrapped it the same way.	2026-08-31 19:34:55 -07:00
Neil	c09810b641	perf(rpc): restore compiled Zod request schemas without override (#17374) ... * perf(rpc): compile Zod request schemas lazily * chore(deps): pin zod 4.5.4 and except it from the release-age gate 4.5.4 is the first release fixing isRecursiveSchema (upstream 84e416f, #6500), which compile() calls on every schema — on 4.5.0 it fired .default() factories at compile time. Verified: compile-time factory calls 0 on 4.5.4, 1 on 4.5.0.	2026-08-31 00:47:22 -07:00
Jinjing	b3912ebed2	Split up combined-diff viewer into feature-organized modules (#17341) ... * Reorganize combined-diff components into feature-organized structure Splits flat combined-diff files into feature-focused subdirectories (browse-files, load-sections, resolve-changes, review-controls, scroll-viewport) to improve code organization and reduce clutter in the editor directory. Groups related logic by concern for easier navigation and maintenance. * Split up combined-diff viewer into feature-organized modules Decompose the 221-line monolithic CombinedDiffViewer into smaller, focused modules organized by feature: entry resolution, section loading, view state memory, file tree navigation, review controls, and scroll viewport handling. Main component now composes these hooks to orchestrate the combined-diff view. * fix(combined-diff): prevent replayed preference writes Move preference write outside state updater callback since React may replay state updaters, causing multiple writes. Add sideBySide to dependency array. * fix(combined-diff): re-resolve sections by key to handle list rebuilds The section list can rebuild while a write is pending (due to rebase, file changes, etc.); re-resolve by key instead of stale index to apply updates to the correct section. - Convert skipped conflicts message to structured i18n plural forms - Add oldPath field to git status signature for rename tracking * Suppress react-doctor diagnostics in combined-diff feature Add suppressions for react-doctor diagnostics that are necessary patterns for the combined-diff implementation, configured in both the quality check script and package.json.	2026-08-30 16:43:37 -07:00
Neil	e84042572c	Upgrade xterm to 6.1.0-beta.303 and generate addon patches ... * Upgrade xterm to 6.1.0-beta.303 and generate the addon patches Takes the current xterm beta line: xterm 287 -> 303, addon-webgl 286 -> 299, addon-serialize 287 -> 300, headless 302, the remaining addons -> 300, and the same set on mobile. All four packages stamp upstream commit d3e32b3. The reasons are upstream #6042/#6043/#6055 (a shared glyph atlas no longer garbles sibling panes on a page merge, clear, or sampler-budget overflow) and Note that core 303 is not image-addon-only over 302: it carries the buffer perf work, including the new BufferLineStringCache. addon-webgl and addon-serialize move into the patch generator -------------------------------------------------------------- Both were hand-edited minified bundles, which is what the Known Gaps section of docs/reference/xterm-patch-regeneration.md described. Both reproduce byte for byte from the pinned commit, so they are now manifest entries generated from a source patch like @xterm/xterm already was. Their sourcemaps now move with their bundles; before this they shipped maps whose offsets did not match the code beside them. The webgl patch shrinks from a 1.06 MB hand-edited bundle to a 6.6 KB source patch, because upstream took the invalidation half Orca had backported. What is left is only what upstream still lacks: the fragment-shader else branch for a v_texpage past the sampler budget, the clearTexture guard that no-ops once a merged page holds index 0, spending the merge retry budget before beginFrame latches the version it saw, and Orca's font-weight probe. The serialize source patch is byte-for-byte the same fixes as before; upstream changed nothing in that addon between 287 and 300. Generator fixes, each of which failed silently ---------------------------------------------- - `--relative` was appended after the `--` separator in CHECKOUT_DIFF_FLAGS, so git read it as a pathspec and kept repo-root-relative paths, dropping every source hunk from an addon's patch. - `git apply` run from a package subdirectory still resolves patch paths from the repo root, skips every hunk and exits 0. It now runs from the root with `--directory=<packageDir>`, and a source patch that leaves the checkout unchanged is a hard failure rather than an empty patch. - An addon's own `tsgo -p .` has empty files/include and only project references, so it emits nothing and the addon webpack then fails on a missing ./out/. The root build now runs first. - versionStampFile is optional; publish.js stamps an addon's package.json, which overlayBuildOutput never patches. - On a version bump the lockfile has no entry under the new key yet, so --write reports the gap instead of aborting mid-run. --check still fails on it. Adding the two addons pushed the generator and the Electron packaging contract test over max-lines, so the patch-text helpers move to xterm-patch-text.mjs (pure text: no checkout, no build) and the vendored-xterm assertions move out of the packaging contract into xterm-webgl-runtime-contract.test.mjs. Tests ----- Four tests asserted upstream bugs that are now fixed, not Orca behaviour: - xterm-user-scrolling-contract pinned headless and core by version string. Upstream bumps each package only when its own output changes, so headless 302 and core 303 are the same source. It now asserts they share a commit. - Five CSI 3 J assertions expected a reader stranded at the top after an erase. Upstream #6081 clears isUserScrolling there, so the erase releases them to the bottom instead. Orca's pin still lands them correctly, because its parser handler observes the erase before xterm's own handler runs. - The IME transaction test hard-coded the xterm version; it now reads the installed package, since the point is that bundle, map and version agree. - The Electron runtime contract asserted Orca's old clearModelGeneration. Shared atlas invalidation is upstream's now, so it asserts pageLayoutVersion on the resolved dependency, plus the Orca-only hunks on the patch. Verified: 66,008 unit tests, mobile's 3,863, the four WebGL atlas e2e specs, and `regenerate-xterm-patches.mjs --check` in sync on all three packages. Left alone deliberately: resetAllTerminalWebglAtlases still fans out globally even though clearTexture now self-heals siblings, and upstream #6068 (WebglAddon.dispose leaks the GL context) is still open. * Drop the two unused WebGL atlas fan-out exports resetAllTerminalWebglAtlases and presentAllTerminalPanesWithoutAtlasClear have no callers, and had none at cadfc55102 either — the last call site went in #6949, which routed reveal recovery through resetAndRefreshAllTerminalWebglAtlases instead. Only a comment in pane-manager.ts still named the first one; it now points at the live entry point. scheduleRevealPresent leaves the registry's structural type with them, though the manager method stays: terminal-visibility-resume.ts calls it directly. This is dead-code removal, not a consequence of the xterm bump. The live recovery path is unchanged. resetAndRefreshAllTerminalWebglAtlases stays, and so does the reveal-time escalation in pane-reveal-repaint.ts. Upstream 299 does make a pane-local clearTexture bump pageLayoutVersion so siblings rebuild on their next frame, which is the bug the escalation was written for, but I could not demonstrate that removing it is safe: with the escalation removed, floating-workspace-shared-glyph-atlas.spec.ts still passed headful, and it also passed with upstream's mechanism deliberately disabled (pageLayoutVersion pinned to 0 in the installed bundle, verified present in the built renderer). A guard that passes with the fix disabled cannot license removing the workaround, so the escalation stays until that spec can reproduce the garbling. Verified: pane-manager and terminal-pane suites (4,713 tests), typecheck, the headful shared-atlas spec, and the three headless WebGL specs. * Give the shared glyph atlas spec a trigger that can fail floating-workspace-shared-glyph-atlas.spec.ts guards the corruption where one terminal wiping the module-global atlas leaves sibling terminals drawing from stale texture coordinates. Both of its tests drive that through a floating panel reveal, and Orca's reveal paths escalate to a registry-wide atlas reset that repaints every pane — so the recovery under test heals the damage before the assertion runs, and the tests pass whether or not xterm propagates the invalidation at all. The new test clears the shared atlas straight through the floating manager with the panel closed, so nothing else repaints the workspace terminal, then repaints it with terminal.refresh(). That is the load-bearing detail: _updateModel skips cells whose content is unchanged, so the refresh reuses vertices baked against the pages that were just wiped, which is exactly the state the fix has to recover from. Verified as a discriminator rather than assumed. Pinning ITextureAtlas's pageLayoutVersion getter to 0 in the installed bundle, which disables the per-renderer invalidation upstream added in addon-webgl 0.20.0-beta.299, and confirming that reached the built renderer: fix intact: siblingClearIntact=true 1 passed fix disabled: siblingClearIntact=false 1 failed The failure renders the workspace terminal completely blank — stale coordinates into a wiped atlas sample nothing. The two reveal tests pass unchanged in both configurations, which is the gap this closes. * Compare shared-atlas screenshots with tolerance instead of byte equality Byte equality fails on sub-pixel antialiasing noise that leaves every glyph legible, so the headful spec flaked under xterm 303. Reuse the existing compareTerminalScreenshots helper: real stale-model corruption blanks the terminal at ~3% of pixels, twice the helper's 1.5% threshold, so the looser oracle keeps its teeth. Log the ratio so failures are diagnosable. * fix(xterm): cancel empty deferred IME compositions * test(xterm): strengthen runtime patch contracts	2026-08-30 15:14:49 -07:00
Neil	4bc2085271	Revert "perf(rpc): compile Zod request schemas lazily" (#17368)	2026-08-30 01:21:55 -07:00
Neil	7b86833120	perf(rpc): compile Zod request schemas lazily (#17353) ... * perf(rpc): compile Zod request schemas lazily * test: align window reveal assertion	2026-08-30 01:03:54 -07:00
Neil	4bb9dd5b89	chore(deps): bump electron 43.4.1 and other meaningful runtime deps (#17330) ... Take the high-value desktop and mobile upgrades that fix crashes, jank, or security holes. Leave Electron 44, Lucide 1, Reanimated 4.6, Expo 56/57, and xterm betas for later. Desktop: electron 43.4.1, @tanstack/react-virtual 3.14.10, mermaid 11.17.2, ws 8.21.3, react 19.2.8, pdfjs-dist 6.3.289, vitest 4.1.11, happy-dom 20.11.8. Mobile: Expo SDK 55 patch train, react-native 0.83.10 (IME patch ported), reanimated 4.3.4, webview 13.16.2 (thread-safe decision manager; restore WebView generic default so TS 6 does not collapse props to never). Electron 43.4 dropped marginType from PrintToPDFMargins; CDP print mapping now supplies the four sides only.	2026-08-29 20:44:43 -07:00
Neil	2dfaa676d8	chore: update oxlint and oxfmt (#17150)	2026-08-29 14:13:35 -07:00
Neil	b17f60d744	build: upgrade to pnpm 12 (#17156)	2026-08-29 14:13:26 -07:00
Neil	0bf5361c92	perf(markdown): update code highlighting incrementally (#17147)	2026-08-29 13:52:16 -07:00
Neil	eb00123a81	perf(markdown): skip unmatched list tokenizer scans (#17134)	2026-08-29 13:43:27 -07:00
Brennan Benson	fd9125ea8c	feat(native-chat): Codex structured native chat restructure (#16729) ... * feat(native-chat): port structured Codex sessions from restructure-recovery Rebuilds the desktop structured native-chat implementation from brennanb2025/native-chat-restructure-recovery (tip 4e31c08db3) on top of current main as a single commit, scoped to the local Codex path. Ported: - Structured agent-session core: durable record store + single-writer lease, canonical journal, agent-session wire host/attach/eviction/subscribers, `agentSession.*` RPC surface (registered via ALL_RPC_METHODS; host-side mobile allowlist included for wire compat), pty write gate, transcript additions, and the Codex app-server adapter/launch resolution. - Renderer: NativeChatStructuredSession view/composer stack, structured launch path with the single-flight guard, local structured session tabs sync, activation gate + structured inventory (read-only `agentSession.handoffStatus` probe), agent-session tabs in the tab strip, AI-vault structured session activation, and the settings pane with the parent Experimental Chat UI toggle plus the nested "Use updated structured native chat" toggle. New sessions require both flags, agent codex, no prompt, and a local non-WSL, non-Windows-host execution host (structured-native-chat-availability). - Fixes 72c013cea6 (verified Codex launch recovery), 8ddbaf5e3d (defer native terminal view switching affordances), and 4e31c08db3 (release the launch gate after a visibility retry) with their regression tests, including the third-launch-after-retry guard case. - Cross-version agent-session wire test + CI lane, packaging entries (proper-lockfile, agent-tooling asar excludes), and the wire-compat doc section. Deliberately not ported: mobile/ changes, the Claude structured runtime (only the claude-transcript-branch-proof and claude-structured-owner-identity leaf modules remain, backing the kept TUI-recovery arms), the terminal↔chat adoption/handoff flow (`agentSession.adoptTerminal`/`requestHandoff`, the handoff request engine, TUI adoption machinery, orca-runtime adoption methods), renderer switching affordances and their dead leftovers, the hook/subagent-status refactor cluster, and unrelated branch changes. The crash-during-acquisition recovery path (restart handoff adjudication, restore/reverse re-acquire, lease schema handoff keys) is kept because every plain direct launch depends on it; a trimmed handoff coordinator exposes only status/restore/close. Branch edits that targeted files main has since split (ipc/pty.ts, worktrees.ts, rpc/methods/terminal.ts, useIpcEvents, pty-connection, store/slices/terminals.ts, runtime-types, web preload) were re-applied to the split modules, preserving main's newer logic (Windows CIM fallback, browser tab close rework, cold-restore resume flow, dispatcher threading). Known seam: the mobile clipboard image-provenance CONSUMER gate ships (agentSession.send refuses unproven mobile image refs with agent_session_image_untrusted) but the producer hunk in rpc/methods/clipboard.ts stays with the unported mobile cluster, so mobile image sends into structured chat fail closed until that side ports. * fix(native-chat): trust only authenticated local image uploads * fix(build): preserve Windows process-tree patch application * test(windows): include process creation time in addon fixture * fix(build): run windows-process-tree node-gyp from the physical package dir gyp expands the node-addon-api dependency by probing node, whose cwd resolves to the package's physical directory in the store, so the emitted target is a store-relative ../../../../node-addon-api@... hop. gyp then resolves that hop against the rebuild cwd; from the node_modules symlink/junction it escapes the store and configure fails with "node_addon_api.gyp not found" (run 32999886072). Rebuild from realpath(package dir) so both bases agree, matching how the package manager itself runs native install scripts. The regression test replays gyp's expansion+resolution against the planned cwd and fails without the fix. * fix(native-chat): keep chat tabs visible through terminal closes and empty-worktree launches Two proven blockers in the native Codex tab contract: closeTerminalTab pre-empted the canonical unified close. With one terminal left it deactivated the worktree on a terminal/editor/browser-only check, blanking a workspace that still held a renderable agent-session tab; with two or more it pre-picked a successor from terminal entities only, re-stamping the group active before closeUnifiedTab's MRU/neighbor repair could land on the chat tab. Successor choice now defers to the unified contract whenever the terminal has a unified row, and deactivation is gated on the unified renderable count (matching leaveWorktreeIfEmpty), with the legacy pre-pick kept only for terminals without a unified row. A structured session created on an empty worktree was published into the host's headless group while preserveLocalLayout froze the local layout, leaving the tab in store but permanently off screen. A preserveLocalLayout owner now always takes client-owned placement — repairing a rendered leaf whose group record is missing, or materializing a rendered group on a truly empty worktree — and applies the client-derived layout repair while still rejecting host-authored layout. Regression tests drive the real store through closeTerminalTab (git worktree and folder workspace) and the real snapshot applier for the empty-worktree adoption states; all fail without the fixes. * fix(native-chat): close stale turns and retry rejected sends * fix(native-chat): retire hosted rows on structured tab activation * fix(native-chat): preserve rpc defaults across main merge * chore: format remote wire compatibility guide * test(native-chat): cover retry after unconfirmed send * fix(native-chat): reload outbox on session switch * docs(settings): disclose structured chat platform limits * fix(native-chat): await Codex launch-home preparation * fix(codex): align child-process allowlist with async trust bridge * test(identity): update inventory for tab surface refactor * fix(windows): preserve process-tree CRLF patch sources * fix(native-chat): anchor an unmatched chat echo where it was sent (#16117) * fix(native-chat): anchor an unmatched chat echo where it was sent The reported symptom was old user messages replaying below every new turn, so the conversation read as scrambled. The cause was not that the echo failed to match a transcript row. Claude consumes a mid-turn send through a `queued_command` attachment and writes no `type:"user"` record for it, so some echoes can never match, and no amount of matching will change that. The cause was WHERE an unmatched echo rendered: buildMobileNativeChatTransientData appended every pending item after the entire transcript, so it re-read below each turn that landed afterwards. Render each echo directly after the transcript row it was sent against, using the baseline the send already captures. An unmatched echo is then at worst a duplicate in the right position rather than a scrambled one, and it stays visible. Echoes sharing an anchor keep send order; a send with no baseline, or one whose anchor folding dropped, still falls back to the tail. Deliberately NOT fixed by deleting the echo. Inferring from send ordering that an echo can never match, then removing it, loses the user's own text for a message the agent did receive, and it cannot fire in the common case anyway - measured drain groups are 1,017 of size 1 against 55 larger. It also escalates an existing gap: the count pass has no baseline-tail guard, unlike the glue pass, while `messages` is a 40-row window that head-trims, resets on reconnect and grows at the front on loadEarlier, so a false landing there would license deleting a DIFFERENT outstanding message. That count-pass gap is real and left for a separate change; anchoring makes its worst case a duplicate in place rather than a scrambled conversation. * fix(native-chat): preserve folded echo anchors * fix(native-chat): preserve forward-folded echo anchors * fix(native-chat): keep leading folded echoes in place * fix(workspace-cleanup): show git status for every row (#16690) * fix(native-chat): refuse structured chat on every Windows execution path canUseStructuredNativeChat only refused win32 when a project runtime resolved, so folder-workspace keys (and other keys with no project runtime) failed open into structured chat on Windows. Fail closed on win32 unconditionally after the host check, matching the settings copy: local macOS/Linux only; Windows/WSL/SSH stay on terminal chat. * fix(native-chat): restore runtime refusals behind the win32 gate 506d375de3 replaced the project-runtime checks with a bare platform test, so a WSL or repair-required runtime resolution would no longer refuse structured chat off-win32. Keep the unconditional win32 refusal and re-run the runtime resolution after it, so the gate does not depend on the resolver's own platform guard. Tests inject WSL and repair-required resolutions on darwin/linux and fail against the regressed gate. * fix structured session journal durability * fix structured tab active pointer after restart * fix(native-chat): await optional lease renewal callbacks * refactor(skills): extract install error messages * fix(agent-session): harden recovery ownership * fix(native-chat): retain panes across tab activation * fix(native-chat): address round-one review findings * test(native-chat): align integration coverage after main merge * fix(native-chat): harden round-two reliability * fix(native-chat): harden round-three reliability * fix(native-chat): close round-four recovery gaps * fix(native-chat): separate bounded journal key forms * fix(native-chat): reset outbox error in render on session switch The switch effect adjusted error state after the sessionId prop changed, tripping react-doctor's no-adjust-state-on-prop-change on the changed-code gate and flashing the old session's banner for a frame. Reset it with the render-time previous-value guard instead. * fix(native-chat): invalidate stale outbox settlements * test(native-chat): restore settled-error session-switch regression a6e2379bd1 replaced this test with the in-flight settlement race test, leaving the render-time error reset unpinned: deleting the reset block still passed the whole native-chat suite. Keep both scenarios pinned; they are distinct (settled error clears on switch vs stale settlement invalidated in the commit-to-passive window). * test(wire): make release checkouts race safe * test(wire): pin cross-process checkout single-flight and importer specifier contract * test(wire): harden release checkout lifecycle * fix(build): drop CR-byte residue from windows-process-tree patch The two trailing CR bytes on the patch's deletion lines are a proven no-op: pnpm hashes patches CRLF-normalized (both forms hash to the lockfile's 946ffb2b) and materializes this package without applying the patch in either form, so the load-bearing build edits come solely from applyWindowsProcessTreeBuildFixes() (#16947), which handles both source EOL forms. Restore byte-identity with main and repin the contract test to the post-#16947 reality: LF-only patch bytes plus lockfile hash sync. * fix(native-chat): skip empty startup recovery	2026-08-28 16:45:58 -07:00
Neil	971d987c4b	ci(e2e): trigger the Docker-SSH lane from SSH source and claim every gated spec (#16746) ... The Docker-SSH e2e lane only ran when a PR's changed specs happened to include `ssh-startup-exec-readiness.spec.ts` or `paired-startup-exec-readiness.spec.ts`. Editing SSH source itself did not trigger it, and pruning either spec from a route's list would have silently retired the whole lane. Meanwhile the sharded lanes set no `ORCA_E2E_SSH_DOCKER`, so every Docker-gated spec skipped itself while the shard still reported green -- the exact silent-skip shape `docs/reference/ssh-reconnect-source-recovery.md` blames for four regressions that reached users. Separately, the modules that actually own direct-SSH workspace and tab restore carry no "ssh" in their names, so the `ssh-terminal-source` route never reached them. Measured on the real script before this change: printf '%s\n' src/renderer/src/hooks/remote-workspace-session-merge.ts \ src/main/ipc/remote-workspace-snapshot-normalization.ts \ src/renderer/src/lib/worktree-initial-terminal-seeding.ts \ src/shared/remote-workspace-session-projection.ts \ | node config/scripts/pr-e2e-source-routing.mjs => [] Three changes, all pinned by the executable gate contract: - `hasSshSourceChange` derives an `ssh_source_changed` signal from the SSH routes themselves, plumbed pr.yml -> e2e.yml, so the lane triggers on source rather than on a spec name surviving in a list. One list, so the two cannot drift. - A sibling `ssh-workspace-session-restore` route names the restore seams (`remote-workspace-*`, `worktree-initial-terminal-seeding`, `worktree-default-terminal-tabs`, `initial-terminal`) and routes them to the two restore specs -- a sibling rather than more paths on `ssh-terminal-source` so a tab-tombstone edit does not run the whole SSH terminal list. - A new `test:e2e:ssh-docker` runner claims the remaining Docker-gated specs on the one VM that sets the flag, and the contract now fails by name when any Docker-gated spec is claimed by no runner. `ssh-docker-relay-perf` and `ssh-codex-display-artifacts-repro` are recorded exemptions (wall-clock budgets; needs a real remote codex binary) and the contract asserts each exemption still corresponds to a real gated spec, so a stale one cannot quietly excuse a gap. Lane timeout raised 35 -> 60 minutes for the added serial specs. The lane's first act was to surface four latent bugs in a spec that had been silently skipping. `ssh-docker-bulk-open-freeze-repro.spec.ts` is four call sites out of date against `tests/e2e/helpers/terminal.ts`: `startDockerSshRelayTarget()` is called with no argument though the helper dereferences `testInfo.workerIndex` (a 100% failure, not a flake), `execInTerminal` gained a `ptyId` parameter, and `splitActiveTerminalPane` gained a direction. It was invisible because it ran nowhere and `typecheck:e2e` is red on main with 240 pre-existing errors, so four more could not be seen. The `testInfo` bug is fixed here -- correct on its own, and it removes one real error from `typecheck:e2e` (240 -> 239). The other three are not, because they are not argument plumbing: repairing them requires choosing which ptyId to capture and which split direction to use, and both change what the repro measures. The spec is therefore added to the exemption list rather than repaired, for two independent reasons recorded in the runner: it is a perf oracle, not a correctness one (`SOFT_FREEZE_LAG_MS=2500` / `HARD_FREEZE_LAG_MS=5000` measured under a deliberate 5-pane flood on a 420s budget -- the same rule already applied to `ssh-docker-relay-perf.spec.ts`), and it is known-rotted. Repair is tracked in stablyai/orca#16764. Applying an existing written rule to a sibling that plainly meets it is consistency; inventing a new exemption to dodge a red would not be. Three hardening fixes to the contract itself: - Runner text is comment-stripped before the claimed-by-a-lane scan. A substring scan over raw text lets a spec merely *discussed* in a runner comment count as claimed -- the silent skip this assertion exists to catch, re-entering through the documentation. Not live today only because the existing comments write the spec names without their `tests/e2e/` prefix. - An exempt spec must not be invoked by any runner. `unreachableSpecs` short-circuits the unclaimed check, so a spec could be documented as exempt while a runner still ran it -- an exemption that reads as coverage removal but changes nothing, leaving the lane red for a reason the file says it excluded. This is not hypothetical: adding the bulk-open exemption without removing it from the runner's spec list produced exactly that state, and this assertion is what caught it. - The Docker-gate detector is now `/ORCA_E2E_SSH_DOCKER\s*[!=]==\s*['"]1['"]/` rather than one fixed string, so a double-quoted or `!==` spelling can no longer escape the contract. `ssh-restart-tab-accumulation.spec.ts` is a new three-cycle restart fence asserting tab-id set identity, not just the active pane's reclaimed ptyId as `ssh-cold-activation-restore.spec.ts:241` did. It passes today; it was validated by a negative control that injected one tab after cycle 1 and correctly failed.	2026-08-27 19:40:38 -07:00
Neil	5631aa00dd	feat(orcad): items 2–7 — degradation, natives, daemon, ops, deploy (#16398) ... * fix(ports): stop joining an undefined resourcesPath on a non-Electron host `resolveWorkerEntryPath` branched on `isPackaged` alone and joined `process.resourcesPath`. orcad reports `isPackaged` true — correctly, it is a production build, and ~15 consumers read it that way to gate HTTPS-only skill downloads and the real CLI name — but `process.resourcesPath` is Electron-only and `undefined` under plain Node. So the packaged branch threw `TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string` where a clean "worker unavailable" was the honest outcome. The type said `resourcesPath: string`, which is how it went unnoticed; it is now `string | undefined`, so the compiler carries the fact. A host with no Electron resources tree has no asar to look in, so it falls back to the module directory and lets the caller report a missing worker. Found by the item 1 agent while auditing the same `isPackaged` defect class in the watcher. Verified in both directions: reverting the guard reproduces the TypeError. * feat(orcad): prove node-pty loads before anything requires it Of the two ways node-pty fails, only one is catchable. A missing module throws MODULE_NOT_FOUND. A module built against the wrong libc or Node ABI is refused by the dynamic loader, and in the worst case takes the process down before any handler exists — that is #9902, which crashed the desktop app on Ubuntu 20.04 before a window appeared. There was no libc or ABI precondition anywhere in the tree. So orcad now proves the load in a CHILD process, from main.ts, before anything requires node-pty. Whatever the child does — throw, abort, die on a signal — is data rather than our own death, and the operator gets a sentence naming the host's libc, Node ABI and prebuild slot plus the command to run. Proven-unloadable exits 78 (EX_CONFIG), so a supervisor does not restart an unequippable host forever. A probe that never answered is unverifiable, not blocked: refusing to boot on an inconclusive signal would take down hosts that work. The child dlopens the file node-pty would have chosen, before requiring the package. node-pty's loader walks several directories and rethrows only the LAST error, so a refused binary reads as "Cannot find module ./prebuilds/..." — which sends the operator to install a module that is already there. It also reports through stdout: node echoes the whole -e source above a stack trace, and matching tokens against stderr made the probe's own source text answer for the verdict. Verdicts reach clients as a terminal_unavailable degradation alongside the existing browser_unavailable one, through the same cause-registry shape. degradations[].code is now an open vocabulary; clients already render only `message`. Prebuilds are compiled from PATCHED sources — the patch IS the glibc-floor fix, so an upstream tarball reproduces #9902 — into linux-{x64,arm64}-{glibc,musl} and darwin-{x64,arm64} slots. libc is in the slot name because node-pty's loader falls back to prebuilds/<platform>-<arch> and cannot tell glibc from musl. orcad installs the matching slot at boot, so a host with no compiler serves terminals. The relay's five pure toolchain-diagnosis functions moved to a transport-free module so the Node bundle can reuse them without dragging ssh2 in behind them; the relay keeps its API by re-export. macOS gets `xcode-select --install` rather than the cross-distro apt/dnf/pacman/apk menu, every line of which is wrong there. * test(orcad): pin the node-pty precondition to ground truth, not a prepared host CI's test shard runs `vitest` directly, so `ensure-native-runtime --runtime=node` never prepares node-pty for the Node ABI — `degraded` is the correct verdict there, and asserting 'ok' encoded an environment the shard does not have. Asserting whatever it returned would be vacuous, so the expectation is now derived from an independent require() of node-pty. Verified it still bites: forcing the precondition to always report 'ok' fails the suite. * feat(orcad): run the terminal daemon, and the ops contract around it orcad declared `canRecoverPersistentLocalPtys: () => false` because it did not run the terminal daemon, so every restart, update and rollback SIGKILLed every running terminal — on the host whose selling point is that work survives the client going away. That is the one property `ssh-execution-boundary.md` recommends the peer model for. Item 4 — the daemon: - Port the launch path off electron: `daemon-init.ts`, `daemon-host-relocation.ts` and `observability/logs-directory.ts` now read the `AppEnvironment` port. Relocation additionally asks whether the app root is an asar archive rather than whether the build is packaged, so a Node host answering `isPackaged() === true` no longer walks into an Electron-only NSIS-escape path (same precedent as `parcel-watcher-entry-path.ts`). - `build-orcad.mjs` emits `daemon-entry.js` beside `orcad.js`, scans the forked children's metafiles for electron/node:sqlite, and load-checks the child under plain Node. - orcad spawns and adopts the daemon; shutdown disconnects and never kills it. `canRecoverPersistentLocalPtys` now reads the live provider and is false under degraded routing, where fresh terminals would die with the process. Item 3 — the ops contract (docs/reference/orcad-operations.md): - Bind policy: `--bind`, default loopback, pinned so neither `orca serve`'s wide default nor the connected-device widen can override it, and so a paired client cannot rebind the listener from outside. - Instance lock on the data root before profile load, scoped to the runtime role so it never refuses a restart that a live daemon makes worthwhile. - Supervision: exit codes a supervisor can act on (78 = do not retry), second-signal escalation, a shutdown deadline, and crash-loop containment on daemon respawn. - Health in the readiness payload: build hash, Node ABI, and a PTY self-test that spans both processes — the daemon spawns a real PTY in its own process and the verdict crosses its socket. Both bundle load-checks now assert on exit codes: these bundles are minified onto one line, so Node's uncaught-exception report echoes every string literal in the bundle and the previous message match passed against a bundle that never loaded. * feat(orcad): deploy, activate and roll back a versioned orcad install Plan items 6 and 7 from docs/design/shipping-orcad.html. Install reuses the relay's transaction verbatim — per-version lock, staged SFTP write, .install-complete sentinel, stale-lock recovery — under a parameterized namespace, so orcad-<v>/ sits beside relay-<v>/ permanently (§06). Parameterizing GC is the trap that creates: each model now collects only its own directories, enforced twice (prefix-scoped remote listing plus a local ownership re-check), and a client picks its model from how the host is registered, never from what it finds on disk. Activation is separate from installation, because a versioned directory selects nothing. A candidate is launched, publishes orca_server_ready, and only becomes active if its cross-process health payload passes: right build hash, listening, daemon live, PTY self-test green. A rejected candidate is stopped and the incumbent restarted, so a careful deploy cannot cause the outage it was being careful about. Update and rollback are shaped by the daemon. An update restarts orcad, the daemon outlives it, and the surviving daemon was forked from the outgoing bundle — so live terminals defer the update rather than proceed, and GC pins the active version, the rollback target and the live daemon's bundle. Orca's persisted state carries no schema version, so rollback restores a pre-activation snapshot rather than trusting backward-readability; the point past which it is unsafe is the first terminal created after activation, which the snapshot cannot describe and the surviving daemon still owns. Running the generated shell for real found two bugs the text assertions missed: tar members re-quoted inside a shell variable captured nothing, and kill -0 reports a zombie as alive. * test(orcad): assert the precondition is self-consistent, not environment-shaped The real-host case cannot predict a status: CI's shard runs vitest directly, so node-pty is never built for the Node ABI and 'degraded' is correct there, while a prepared checkout gives 'ok'. The previous attempt used require('node-pty') as ground truth, which resolves the JS wrapper while the native binding loads lazily — it proved strictly less than the precondition checks, and failed CI for exactly that reason. What is invariant on a host with node-pty installed: never 'blocked', and never a degraded verdict carrying an unestablished reason. The injected-input tests keep the logic coverage. * fix(orcad): drop an eslint-disable the rule no longer needs * test(orcad): separate slot placement from the load verdict Both remaining CI failures were the same shape: tests reaching into node_modules for a pty.node that only exists after `ensure-native-runtime --runtime=node`, which CI's shard never runs because it invokes vitest directly. Slot *placement* is the logic worth checking on every host, so it now uses a synthetic payload and asserts the verdict stays honest about not loading. The three assertions that genuinely need a Node-ABI binding are gated on it existing. Verified: breaking slot installation fails both placement tests; with the real pty.node hidden the file is 17 passed / 3 skipped instead of ENOENT. * test(orcad): gate the load-dependent cases on a real load, not on the file existing CI ships a pty.node built for Electron's ABI, so existsSync was true while require still failed — the gate ran exactly the tests that host can never satisfy. It now probes the binding in a child process, so a bad one cannot take the runner down. The self-consistency assertion also allowed too little: 'blocked' is the honest verdict for a corrupt binding, alongside 'ok' on a prepared host and 'degraded' on an unprepared one. What stays invariant is that anything other than 'ok' names an established cause, so a terminal is never declined for a reason nobody worked out. Verified against all three host states: prepared (19 passed), unprepared, and a corrupt binding (17 passed / 3 skipped, no failures). * test(orcad): gate on the whole premise — binding AND spawn-helper CI has a loadable pty.node but no spawn-helper, and a slot without the helper is legitimately 'degraded'. So the previous gate let a test run whose premise ('a complete slot yields ok') that host cannot satisfy. Verified in both states: with the helper present 19 pass; with it removed the load-dependent cases skip (17 passed / 3 skipped) instead of failing. * fix(orcad): preserve degradation types after rebase	2026-08-27 00:18:51 -07:00
Jinwoo HongandJinwoo-H	a9781a4118	STA-4150: client-hosted remote browser (consolidated) (#15448) ... Co-authored-by: Jinwoo-H <jinwoo@stably.ai>	2026-08-25 15:36:51 -07:00
Jinwoo Hong	c618ec7393	test(reliability): protect recent P0 regression invariants (#16163)	2026-08-24 09:38:46 -07:00
Jinjing	f5fd7303ab	test(e2e): cover tab-bar agent launches on Windows and WSL (#16110) ... * test(e2e): gate the tab-bar agent launcher on Windows shells and WSL The `+` menu agent launcher had no golden coverage in the Windows lane, so a Windows-only break anywhere in its chain (detection row, startup-plan build, tab create, PTY spawn, startup-command injection) could ship unnoticed. Adds a golden spec that launches a stub agent from the menu and asserts the agent's own banner reached the pane — a tab that spawned a bare shell instead is indistinguishable at the store/tab layer. Runs two agents everywhere, and on Windows also PowerShell, cmd, Git Bash and a WSL project runtime. * test(e2e): track WSL stub agent staging state for precise cleanup Refactor `stageWslGoldenStubAgent` to track which artifacts it creates during setup, then only remove those artifacts during cleanup. This prevents the test from destructively removing pre-existing symlinks or state from previous runs, improving test isolation and idempotency. * test(e2e): track WSL stub agent staging state for precise cleanup - Back up and restore pre-existing stub agents to avoid destroying them - Simplify verbose test comments to match project style guidelines * test(e2e): serialize WSL stub agent setup with distributed lock - Add mkdir-based lock to prevent concurrent staging invocations - Reclaim stale locks after 10 minutes to recover from crashes - Track lock ownership in stage state for safe cleanup * test(e2e): track WSL stub agent staging state for precise cleanup Track which stubs this test helper stages by writing a marker file, then only remove stubs during stale-lock recovery if we created them. Prevents cleanup from removing stubs left by other processes.	2026-08-24 08:58:19 -07:00
Neil	03fcfdfb92	feat(orcad): boot the Orca runtime on plain Node (#15968) ... * refactor(host): resolve the app root through the port in fork-reachable modules `parcel-watcher-entry-path.ts` and `session-scanner-service-entry-path.ts` read the app root via `require('electron').app` inside a try/catch that already returns null when Electron is absent. They were therefore correct under plain Node at runtime and only failed the *static* text check — which is real, not pedantic: the comment in `ports/port-scan-command-client.ts:19` records that the plain-node-entry-guard fails on that literal text, try/catch or not. `hasAppEnvironment() ? getAppEnvironment() : null` gives the identical "no app root here" answer without the text. That restores `hasAppEnvironment`, which an earlier commit in this stack deleted as unused — it now has the caller it was waiting for. Ratchet baseline 27 → 25. Verified: 74 files / 458 tests; `pnpm typecheck` clean; `oxlint` clean. * feat(orcad): boot the Orca runtime on plain Node Closes the last two Electron couplings and makes `orcad` a working artifact: a 4.43 MB Node bundle that boots, pairs, registers a repo, creates a real git worktree and round-trips a PTY — with zero `require("electron")`. Ratchet 2 -> 0, so `config/runtime-electron-baseline.txt` is now empty and its test asserts exactly that: any reachable electron import is a regression. - speech: inject the service factories, so importing ModelManager for its type no longer drags Electron's streaming net.request into the graph - filesystem-watcher: add a WorktreeWatcherRemoval port. Every entry in those maps arrives through an ipcMain handler carrying a renderer sender, so a host with no renderer has nothing to close, restore or forget — the inert default is what the desktop code does against empty maps, not a stub hiding work - user-data-path / profile-storage-paths: resolve userData through AppEnvironment. These surfaced only once orcad pulled the store in Both host ports now anchor to a realm-global symbol. `vi.resetModules()` gives the re-imported graph a fresh module copy, so a binding installed before the reset silently read back as uninstalled. The acceptance smoke drives both hosts through one code path (`--target orcad|electron`) and seeds its own git repo, so it is hermetic and asserts the same contract of each. Wired into PR CI. * test(smoke): remove the seeded workspace container, not just the worktree * test(smoke): surface the server's stderr when it dies before ready * fix(smoke): build node-pty for Node before booting orcad in CI * fix(smoke): drive the CLI built from this checkout, not one on PATH * docs(ratchet): say the baseline must stay empty, not merely shrink * build(orcad): externalize only the native modules actually in the graph	2026-08-22 21:47:46 -07:00
Neil	f975035809	refactor(ipc): split preflight and SSH registry out of the ipcMain modules (#15927) ... * refactor(preflight): split agent detection out of the ipcMain registration First of the IPC extractions the revised design requires. `src/main/ipc/preflight.ts` mixed 285 lines of agent/tool detection with 35 lines of `ipcMain.handle` registration, and the runtime calls that detection during normal operation (`orca-runtime.ts:573`, plus the preflight RPC methods). So the runtime dragged `ipcMain` into its graph to reach pure logic. Detection moves to `src/main/preflight/agent-detection.ts` — named for what it contains, per AGENTS.md. `ipc/preflight.ts` keeps only the handler registration and re-exports the domain module so existing importers are unaffected. The runtime and its RPC methods now import the domain module directly. Ratchet baseline 36 → 35: `src/main/ipc/preflight.ts` is no longer reachable from the runtime. The gate detected the improvement and refused to pass until the baseline tightened, which is the behaviour it was built for. Verified: 2 files / 1,187 tests pass across every suite touching preflight; `pnpm typecheck` clean; `oxlint` clean. * refactor(ssh): split the SSH target registry out of the ipcMain module Second IPC extraction, and by far the biggest win: this removes **eight** modules from the runtime's Electron graph, taking the ratchet baseline 35 → 27. The runtime needed five thin accessors from `src/main/ipc/ssh.ts` — `connectRegisteredSshTarget`, `getRegisteredSshState`, `listRegisteredSshTargets`, `listRegisteredRemovedSshTargetLabels`, `getActiveMultiplexer`. Each is a one-line read over module-level state. Importing them dragged in `ipcMain`, `powerMonitor` and a `BrowserWindow` accessor — and, transitively, `ipc/pty.ts` (8,031 lines), `ssh-browse`, `ssh-passphrase`, `ssh-relay-deploy`, `ssh-remote-cli-host-passthrough`, `wsl-hook-relay-launch` and `user-data-path`. `src/main/ssh/ssh-target-registry.ts` now holds that state plus its accessors. `registerSshHandlers` populates it; the runtime reads it. The indirection is kept deliberately: SSH providers register after construction and may reconnect, so callers must resolve the current generation rather than freeze one. `ipc/ssh.ts` re-exports all five, so non-test importers are unaffected. `connectRegisteredSshTarget` still throws `ssh_handlers_not_registered` when no handler layer registered — a headless host must fail loudly rather than report a target as unreachable, which would read as `exited` (see ssh-execution-boundary.md). Verified: 9 files / 59 tests across the ssh, automations and trust-preset suites; orca-runtime.test.ts 1,183 pass; `pnpm typecheck` clean; `oxlint` clean. * refactor(host): resolve the app root through the port in fork-reachable modules `parcel-watcher-entry-path.ts` and `session-scanner-service-entry-path.ts` read the app root via `require('electron').app` inside a try/catch that already returns null when Electron is absent. They were therefore correct under plain Node at runtime and only failed the *static* text check — which is real, not pedantic: the comment in `ports/port-scan-command-client.ts:19` records that the plain-node-entry-guard fails on that literal text, try/catch or not. `hasAppEnvironment() ? getAppEnvironment() : null` gives the identical "no app root here" answer without the text. That restores `hasAppEnvironment`, which an earlier commit in this stack deleted as unused — it now has the caller it was waiting for. Ratchet baseline 27 → 25. Verified: 74 files / 458 tests; `pnpm typecheck` clean; `oxlint` clean. * test(ssh): mock the SSH target registry alongside the ipc/ssh mock Thirty-eight suites mocked `vi.mock('./ssh')` for `getActiveMultiplexer`. That factory went inert when production started importing the accessor from `../ssh/ssh-target-registry`, so the real module loaded and the assertions drifted. Adds a companion registry mock returning the same stub, plus a `sshTargetRegistryModuleMock` builder beside the existing `sshModuleMock` so the shared harness stays one place. No assertion changed. Found by a full-suite run: the targeted ssh/runtime suites were green while 30 tests in ipc/worktrees and ipc/repos were not. * refactor(runtime): read app paths and the packaged flag through the port `orca-runtime.ts` is the last module in its own graph that imports `electron` directly. Nineteen of its uses were `app.getPath` (12) and `app.isPackaged` (7) — exactly what the AppEnvironment port already covers. Also removes a dead `const { app } = require('electron')` inside `getOrchestrationDb`. It was left unused once the path came from the port, and it is precisely the dynamic-require pattern `plain-node-entry-guard.ts` exists to catch, sitting in the runtime's own constructor path. What still binds `orca-runtime.ts` to Electron is now three sites, not nineteen: `new Notification(...)` (one), `BrowserWindow.fromId` (one), and the `ipcMain.on('terminal:tabCreateReply')` renderer round-trip — which is the browser tab path, and the same one that would hang a headless host for ten seconds. Two suites drove `electronMocks.app.isPackaged` directly; they now install a fake AppEnvironment reading the same mutable field, so their per-test toggles work unchanged and no assertion moved. Verified: 376 files / 4,717 tests across src/main/runtime; typecheck and oxlint clean. * test(serve): add the built-artifact terminal round-trip acceptance smoke "The server started" proves almost nothing. Terminal creation dispatches into OrcaRuntimeService, and without an installed headless PTY controller that path falls through to a renderer reply that never arrives and times out after ten seconds. A boot probe, a port bind, and a `host.platform` call all pass against a server whose terminals are dead — which is exactly the gap the design doc's own boot proof was retracted for. This boots the BUILT `out/main/index.js --serve`, parses its ready payload, pairs a real client over the advertised endpoint, lists worktrees, creates a terminal, runs a command through the PTY, asserts the output comes back, and asserts clean shutdown. It drives nothing but the public pairing + RPC surface, so the same script is the acceptance gate a future Node-only backend must pass unchanged. The sentinel invokes `process.execPath` rather than `echo`, because the shell differs per platform and node does not. Verified both directions: passes against the real server, and fails with an actionable message when the command produces no output — a smoke that cannot fail is worthless. * fix(ssh): fail loudly when the multiplexer resolver was never installed `getActiveMultiplexer` resolves through a resolver that `ipc/ssh.ts` installs at module scope. A process that never loads the SSH layer — which is the whole point of the Node-only backend — would get `undefined` from every call. `undefined` already means something specific here: "not connected". So a missing resolver and a disconnected target were indistinguishable, and a host with no SSH layer would quietly report every target as not connected. That is the unverifiable-reported-as-exited conflation `docs/reference/ssh-execution-boundary.md` exists to prevent — the doc is explicit that absence of contact is never evidence of absence of the thing. A missing resolver is a wiring error, not a connection state, so it throws, matching what `connectRegisteredSshTarget` already does for unregistered handlers. Verified: 432 files / 4,759 tests across ipc, ssh, preflight, automations and trust presets; typecheck and oxlint clean. * refactor(pty): stop faking a BrowserWindow for the headless PTY path `registerHeadlessPtyRuntime` passed `registerPtyHandlers` a stub object cast to `BrowserWindow` whose `isDestroyed()` returned true and whose `webContents.send` was a no-op — a window-shaped thing that lied about being a window, purely to satisfy the type. Adversarial review named it as the same "looks fine, silently returns a lie" pattern this codebase rejects elsewhere, and it is the shape that keeps `electron` on a path that otherwise needs none. `registerPtyHandlers` now takes `BrowserWindow | null`. An absent renderer is semantically identical to a destroyed one — all 42 call sites already guarded on `isDestroyed()` and skipped — so `src/main/ipc/pty-renderer-surface.ts` states that directly: `isRendererGone`, `sendToRenderer`, `rendererWebContents`. The compound `isDestroyed() || webContents.isDestroyed()` guards collapse into one predicate. `isPtyWriteEventFromMainWindow` becomes null-tolerant and fails closed: with no renderer no sender can legitimately match, so every write is rejected. Those handlers cannot fire headless today, but failing closed is the right answer if that ever changes. This is the precondition for installing a PTY controller without Electron, which is what a Node-only backend needs and what `terminal.create` actually calls. Verified: 129 files / 2,473 tests across ipc/pty, providers and orca-runtime; the built-artifact acceptance smoke still passes end-to-end (boot → pair → terminal.create → sentinel → close), which is the check that matters most here since this changes the headless PTY path itself; typecheck and oxlint clean. * refactor(pty): read app paths and the packaged flag through the port Follows the fake-window removal. `ipc/pty.ts` had nine `app.*` reads — all `getPath`, `getVersion` or `isPackaged` — which the AppEnvironment port already covers. The `BrowserWindow` import was also dead after the null-window change. What still binds this file to Electron is now `ipcMain` (75 uses, all handler registration) and `powerMonitor` (2). That is a clean statement of the remaining job: split logic from registration, the same shape already applied to preflight and the SSH registry. Test wiring: the shared `pty-ipc-suite-environment` beforeEach installs a fake AppEnvironment that reads through the existing `vi.mock('electron')` app object rather than freezing values — suites toggle `app.isPackaged` mid-test to exercise dev-mode spawn paths, so the port has to observe the same mutable field. One edit in the shared harness covers every pty suite. Verified: 128 files / 1,290 tests across ipc/pty and providers; the built-artifact acceptance smoke passes; typecheck and oxlint clean; ratchet unchanged at 25. * refactor(pty): inject the ipcMain surface so the PTY module loads without Electron This closes the round-3 blocker: "the doc never says how orcad installs setPtyController without Electron." `registerPtyHandlers` owns the `RuntimePtyController` that `terminal.create` actually spawns through — the thing a Node backend needs and cannot get from the provider thunks. The module was otherwise host-agnostic already; the only thing pinning 8,031 lines to Electron was a static `ipcMain` / `powerMonitor` import used purely to register renderer handlers that no headless host will ever receive. `src/main/ipc/pty-host-bindings.ts` makes those surfaces settable, defaulting to no-ops. Unlike AppEnvironment and SecretStore, the default does NOT throw: a host with no renderer legitimately has nothing to register against, so not registering handlers nobody can call is correct rather than a hidden downgrade. The desktop installs the real objects in `attach-main-window-services` before its handlers run. Also converts the remaining electron import to a top-level `import type`. oxlint's `no-import-type-side-effects` caught that inline `type` specifiers still leave a side-effect import — precisely the "type-only is not enough if esbuild still emits require('electron')" trap a reviewer flagged. **`src/main/ipc/pty.ts` now bundles with zero `require("electron")`.** A Node entry can call `registerPtyHandlers(null, runtime, …)` and get a working PTY controller. Verified: 128 files / 1,290 tests across ipc/pty and providers; the built-artifact acceptance smoke passes end-to-end — which is the check that matters, since this changes how every PTY handler registers; typecheck and oxlint clean. * fix(pty-bindings): drop two unused eslint-disable directives CI runs oxlint with unused-disable reporting; the two `@typescript-eslint/no-explicit-any` suppressions I added were never triggered by any enabled rule, so they failed static analysis as dead directives. The `any[]` rest args stay — they mirror electron's own IpcMain signature, and narrowing them would reject the real object at the desktop call site. Verified with the exact CI invocation: `oxlint --format github` reports 0 warnings, 0 errors across the repo. * fix(pty): install the host bindings per process, not per window A real regression my own change introduced, caught by the SSH docker E2E (`paired-startup-exec-readiness` — "recovers startup exec through a headed paired desktop owner"). It reproduced on rerun, so it was not a flake. `setPtyHostBindings` was called inside `attachMainWindowServices`, i.e. when a window attaches. But `registerHeadlessPtyRuntime` (index.ts:3163) calls `registerPtyHandlers` on the serve path *before* any window exists — so those handlers registered against the no-op default and never reached the real `ipcMain`. A paired desktop owner then attached to a runtime whose PTY handlers were wired to nothing. The bindings describe the *host*, not the *window*: an Electron main process always has `ipcMain`, whether or not a window is open. Installing them beside `setAppEnvironment`/`setSecretStore` at the top of bootstrap fixes both paths. Verified: 128 files / 1,290 tests; the built-artifact acceptance smoke passes; typecheck clean; `oxlint --format github` (the exact CI invocation) reports 0/0. * feat(orcad): de-electron the runtime core and add the Node entry + build gate **`src/main/runtime/orca-runtime.ts` — 41,048 lines — no longer imports electron.** Its last three sites go through `runtime-desktop-surface.ts`: a native notification, the authoritative-window lookup, and the one `ipcMain` channel used by the renderer-backed tab-create fallback. All three are unreachable without a renderer — `createTerminal` already takes the background branch when no window exists (#10333) — so a Node host installs none and the runtime relays notifications to paired clients, which is the better destination anyway. Ratchet 25 → 24. Adds `src/main/orcad/orcad-entry.ts`: Node host adapters plus a `startOrcad` that constructs the runtime, installs the PTY controller via `registerPtyHandlers(null, …)`, and serves RPC. It sets two defaults the constructor gets wrong for a headless host — `canRecoverPersistentLocalPtys: false` (no daemon here) and `getDesktopWindowStatus: 'blocked'` (a Node host can never be promoted to a desktop window, which is what `'openable'` claims). Adds `config/scripts/build-orcad.mjs`, which **currently fails, on purpose**: 25 modules still import electron (browser and speech clusters, plugins, jira/proxy, filesystem-watcher, and four `require('electron').app` one-liners). It names them. Two bugs found while building it, both worth recording: - The first bundle looked clean and was not. `electron` was bundleable, so esbuild rewrote the metafile `path` to the resolved file under node_modules and a check for `path === 'electron'` passed while the package was in the bundle — it failed at runtime with electron's own installer message. The check now reads `original`, and electron is marked external so a residual import fails loudly instead. - `jsonc-parser`'s UMD build breaks the bundle at load; aliased to its ESM entry, the same fix `build-relay.mjs` already carries. Verified: desktop unchanged — the built-artifact acceptance smoke passes, runtime/pty/ provider suites green, typecheck clean, `oxlint --format github` 0/0. * refactor(host): drop the last two require('electron') app lookups `computer/sidecar-client.ts` and `ports/port-scan-command-client.ts` read the app root through `require('electron').app` inside a try/catch. Both were already correct under plain Node at runtime — they return null when it throws — but the literal text fails the plain-Node entry guard regardless, which is why port-scan carried a comment warning it must never become reachable from a fork entry. Reading the AppEnvironment port gives the identical "no app root here" answer without the text, so that warning is now obsolete and the comment says so. Ratchet 24 → 22. Every remaining entry is a real coupling: the browser cluster (15, which variant B does not ship), speech (2), plugins (2), and jira/proxy-settings (2, needing an HttpClient port for Chromium session partitions). Verified: 25 files / 209 tests; acceptance smoke passes; typecheck and `oxlint --format github` clean. * docs(orcad): record that the ratchet under-counts orcad's graph The ratchet reports 22 electron importers; the orcad build reports 23. The extra is agent-hooks/wsl-hook-relay-launch.ts, and the cause is a gap in the gate rather than a rounding error: the ratchet measures what orca-runtime + runtime-rpc reach, while orcad's entry also imports ipc/pty directly to install the PTY controller. Once orcad ships it must become a ratchet entry point, or the two numbers drift and the gate quietly stops covering the artifact it exists for. * refactor(runtime): inject the browser commands factory Drops 14 modules from the runtime's Electron graph in one change — the whole Chromium browser cluster. Ratchet 22 → 8. `OrcaRuntimeService` constructed `RuntimeBrowserCommands` as a field initializer, and that construction is what pulled in `BrowserWindow`, `session`, `webContents` and the cookie jars. Importing the class for its *type* is free; only building it costs. So the class import becomes `import type`, and the instance comes from `runtime-browser-commands-factory.ts`. The desktop installs the real factory at the Electron entry. **All ~80 existing `this.browserCommands.*.bind(...)` delegations are untouched** — a review round specifically warned that rewriting those was the expensive, risky part, and this avoids it entirely. With no factory installed, browser commands reject per call with `browser_unavailable` rather than resolving to a stub that silently succeeds. The runtime already filters browser capabilities out of `getStatus()` when no backend exists, so clients do not offer the affordance in the first place. Also corrects a stale comment in `pty-renderer-surface.ts` that still described the fake window as present tense; it was deleted two commits ago. Verified: 451 files / 5,513 tests across `src/main/browser` and `src/main/runtime` — the entire browser automation suite; the built-artifact acceptance smoke passes; `pnpm typecheck` and `oxlint --format github` clean. * refactor(host): extract the plugin client list and port two app lookups Ratchet 8 → 5. - `listPluginsForClients` moves to `src/main/plugins/plugin-client-list.ts`. It needed only three `plugins/*` helpers, none of them Electron — it was colocated with `ipcMain.handle` registrations, so the runtime's `plugins.list` RPC dragged all of Electron in to call a function that reads a lockfile. Same shape as preflight. Dropping it also releases `ipc/plugin-marketplaces.ts`. - `agent-hooks/wsl-hook-relay-launch.ts` and `speech/stt-service.ts` read `getAppPath` and `isPackaged` through the AppEnvironment port. The five that remain are all genuinely Chromium and need the HttpClient port or a watcher split, not another mechanical swap: `browser/cdp-bridge` (webContents), `ipc/filesystem-watcher` (ipcMain), `jira/authenticated-request` and `network/proxy-settings` (net + session partitions), `speech/model-manager` (`net.request`, which honors app proxy settings that Node https does not — replacing it is a behaviour change, not a rename). Verified: 219 files / 1,922 tests across plugins, speech, agent-hooks and the runtime RPC methods; the built-artifact acceptance smoke passes; typecheck and `oxlint --format github` clean. * refactor(network): resolve the default proxy session lazily Ratchet 5 → 4. `proxy-settings.ts` needed exactly one Electron value: `session.defaultSession`, as the fallback when a caller does not pass `options.proxySession`. Callers could already inject a session; only the default was hard-wired. It now comes from a settable resolver, so the module loads under plain Node. **A resolver rather than a Session, because a Session eagerly throws.** The first attempt installed `session.defaultSession` directly in pre-ready bootstrap and broke startup outright — `TypeError: Session can only be received when app is ready`. The acceptance smoke caught it before commit. Deferring to first use is always after ready. Behaviour with no session is not a degradation: there is no Chromium proxy config to discover, so `resolveProxy` is skipped and the environment variables become the whole answer rather than a fallback. Applying rules to a session that does not exist is likewise skipped; settings are still honoured because outbound requests read the env. This reaches past Jira — a review round noted `ensureElectronProxyFromEnvironment` is also on the Claude HTTP path via `oauth-refresh.ts` and `rate-limits/claude-fetcher.ts`. Verified: 48 files / 526 tests across network, jira and rate-limits; the built-artifact acceptance smoke passes; typecheck and `oxlint --format github` clean. * fix(index): merge the duplicate proxy-settings import CI's code-quality lint (`oxlint --config config/oxlint-code-quality-native-plugins.json --deny-warnings`) flags a module imported twice in one file. My earlier insertion added a second `./network/proxy-settings` import beside the existing one. Verified with CI's exact invocation: exit 0. * refactor(network): add the HttpClient port and lift BrowserError out of cdp-bridge Ratchet 4 → 2. Two unrelated couplings, both of the same shape — a small thing living inside a Chromium-heavy file. `BrowserError` is a seven-line error class with no dependencies, but it lived in `browser/cdp-bridge.ts`, which imports `webContents`. The runtime catches that type on paths with nothing to do with CDP, so one import kept a Node host from loading the runtime at all. Moved to `browser/browser-error.ts`; cdp-bridge re-exports it. `jira/authenticated-request.ts` fetches through `net.fetch` and reads `session.defaultSession`. `network/http-client.ts` makes both settable. This one is a **named port rather than a silent fallback, because the fallback is not transparent**: Electron's net follows Chromium session/proxy state, avoids undici's stale keep-alive sockets after a VPN path change, and sends a Chrome user agent that Jira's XSRF check depends on. A Node host gets `globalThis.fetch`, reads proxy config from the environment, and sends Node's user agent. That difference is documented at the port. `session.defaultSession` is read per call, not captured at install — it throws before the app is ready, which is the mistake the previous commit made and the acceptance smoke caught. Test wiring: `jira/client.test.ts` installs the port *inside* `loadClientModule`, after its `vi.resetModules()`, since the reset gives the module a fresh singleton. Verified: 461 files / 5,616 tests across jira, browser, network and runtime; the built-artifact acceptance smoke passes; typecheck, `oxlint --format github` and the code-quality lint with `--deny-warnings` all clean. * fix(http-client): register the Node fetch fallback with the call-site audit `global-fetch-call-site-audit.test.ts` guards every global-fetch use, because the global runs on undici where an unread response body can crash the whole process (orca#8695). The HttpClient port's Node fallback is a new such call site and was unregistered — the guard caught it in a full-suite run. Registered with the reasoning, and the port's doc comment now states the body-safety contract explicitly: it hands the Response straight to its caller and never inspects it, so the consume/cancel obligation stays exactly where it already was — with the caller, unchanged from when they called Electron's net directly. Two comments elsewhere mentioned the global by name and tripped the line scan as false positives; reworded to describe the behaviour rather than name the API. Verified: audit passes; typecheck and `oxlint --format github` clean. * fix(app-environment): read hasAppEnvironment through the realm slot	2026-08-22 21:34:39 -07:00
Neil	cbea7530b4	build(runtime): gate new Electron imports reachable from the Orca runtime (#15919) ... * build(runtime): gate new Electron imports reachable from the Orca runtime The runtime is meant to become host-agnostic so it can also run on plain Node, but nothing enforced that. `orca-runtime.ts` reaches dozens of modules that import `electron`, and the count grows silently: the import that breaks portability is usually several hops away, so no reviewer sees the edge. Add a reachability ratchet, modelled on the existing max-lines one. It bundles the runtime and its RPC server with esbuild, reads the metafile for every module importing `electron`, and diffs that against a checked-in baseline. A new module fails; a removed one forces the baseline to tighten. The list may only shrink. A per-file lint rule cannot do this — the point is precisely the transitive edges — so this runs as a build gate in `pnpm lint`. Baseline starts at 36, down from 50 before the SecretStore and AppEnvironment ports landed, which is the migration made measurable. Verified: gate passes clean, fails with an actionable message when an `electron` import is added to a runtime module, and passes again when reverted. * fix(runtime-ratchet): resolve paths from the script, not the caller's cwd Run from anywhere but the repo root, the gate died with an unhandled ENOENT stack instead of a usable message. It failed closed, so it was never unsafe — just undebuggable. Anchor ROOT to import.meta.dirname and pass absWorkingDir to esbuild so metafile keys stay repo-relative. * ci(runtime-ratchet): actually run the gate in CI The ratchet was wired into the `lint` npm script, but CI's static-analysis job runs the individual checks rather than `pnpm lint`, so the gate would never have fired on a PR — it would have looked enforced while enforcing nothing. Runs on ubuntu-latest alongside the max-lines ratchet, so the checked-in baseline is only ever produced by one platform. * fix(runtime-ratchet): mark native addons external so CI can run the gate ssh2's optional cpu-features dep points at a prebuilt .node that only exists where a build toolchain has run. Loading it made the gate pass locally and hard-fail on CI with 'Could not resolve ../build/Release/cpufeatures.node'. The gate only reads the import graph, never the addon, so resolve every .node to an external stub instead. Verified by hiding the local prebuild — which is CI's state — and re-running: still 36 entries, exit 0. * fix(runtime-ratchet): stop the gate failing open on Windows The entry guard compared import.meta.url against a `file://${process.argv[1]}` template. On Windows argv[1] is a native path (C:\repo\...) while import.meta.url is file:///C:/repo/..., so they never match: main() never ran and `pnpm lint` exited 0 on Windows without bundling, reading the baseline, or enforcing anything. Use pathToFileURL, which is the idiom check-max-lines-ratchet.mjs:225 already uses. CI runs this on ubuntu so enforcement was never actually lost, but a Windows developer got a green gate that checked nothing.	2026-08-22 21:22:07 -07:00
Neil	057fbfcffc	perf(windows): read the process table natively instead of forking PowerShell (#15749) ... * perf(windows): read the process table natively instead of forking PowerShell Seven independent readers each forked powershell.exe to run Get-CimInstance Win32_Process, with a wmic fallback that Windows 11 24H2 has removed. On a domain-joined host with PowerShell Transcription enabled by policy, one of them running every ~2s recorded ~289GB across 1.4 million files (#15209). The same scan cost ~700ms and ran per pane (#15036), and a Group Policy or AV block turned it into 'unavailable', which callers read as 'no evidence' -- which is how a PTY tree survives its own teardown (#9045, #10475). A Toolhelp32 snapshot answers the same question with no child process. Measured on Windows 11 with 1050 processes, p50/p95: pid+ppid+name 15.9 / 17.5 ms +memory +command line 30.6 / 33.7 ms Get-CimInstance 706 / 723 ms Two upstream defects needed patching, both found by running it on real hardware. The binding requires Spectre-mitigated libraries our agents do not carry (node-pty is patched the same way). And enumeration stopped after 1024 processes: on a host with 1051 the module returned exactly 1024, and the querying process was itself among the 27 missing -- a truncated snapshot silently hides the descendants teardown is looking for, which is the failure this whole change exists to remove. Migrated: the foreground/descendant reader (the #15209 scraper and the teardown identity gate) and the port scanner's PID attribution. NOT migrated: the memory collector and three identity probes, which need Win32_Process.CreationDate and have no native equivalent. Start time is a proxy for identity anyway; an inherited job handle is the real answer, so those belong with the job-object work rather than here. Packaging follows the windows-native-registry contract exactly: optional, absent from onlyBuiltDependencies so macOS/Linux never run node-gyp, win32-only in the packaged runtime. Asserted by the existing contract test, which also stops pinning a whole source literal that only tested its own formatting. * chore(process): ratchet the child_process allowlist down windows-foreground-process-rows.ts no longer spawns anything, so its allowlist line is stale. The guard fails on a stale entry as well as a new one, precisely so a migrated file cannot keep a slot open and hide the next regression in the same path. * fix(ports): import the process-table reader the scanner uses Missing import: the migration replaced the PowerShell call but the new symbol was never imported, so tsc failed. Vitest transpiles without typechecking, which is why the port-scanner suite stayed green. * fix(deps): sync this branch's lockfile with its patch set Same class as the fix on the tip branch: pnpm records a hash per patched dependency, and this branch introduces the windows-process-tree patch without its lockfile entry matching. Every job here failed at install with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH. Verified with --frozen-lockfile, which is what CI runs and what my local runs were not. * test(relay): drive the relay's Windows fixtures from the native snapshot Two relay cases fed a PowerShell CIM payload through a mocked execFile. That reader is gone, so both failed -- deterministically, on every PR run for this branch and the one above it. I did not catch it because my own verification sweep was 'src/main src/shared config/scripts' and never included src/relay. The relay is a first-class consumer of the process table; leaving it out of the sweep is how a deterministic failure survived six review rounds.	2026-08-21 21:54:57 -07:00
Jinjing	d8e9fa1bb9	Revert "fix(terminal): apply pane padding on all four edges (#15544)" (#15623) ... This reverts commit 4b2ed5ddd4.	2026-08-20 09:57:55 -07:00
Brennan Benson	4b2ed5ddd4	fix(terminal): apply pane padding on all four edges (#15544) ... * fix(terminal): apply pane padding on all four edges Move the configured inset onto xterm so the terminal fills its pane while the fit calculation accounts for both sides of each axis. Add a geometry golden that forces cell remainders and verifies dynamic padding without relying on renderer pixels. * fix(terminal): normalize imported padding for fitting * fix(terminal): align stored and fitted padding	2026-08-20 01:07:56 -07:00
OrcaWin	471bc9d8ce	Ship the WSL transcript helper with the Windows relay (STA-4831) (#15529)	2026-08-20 00:16:04 -07:00
Neil	fdd4091ebd	fix(hooks): isolate lint-staged backups per worktree (#15388)	2026-08-19 22:37:02 -07:00
Neil	13b10e0b54	ci: cut PR wall clock by caching what CI recomputes every run (#15211) ... None of these change what CI checks — they remove work the runners repeated on every PR. - install-node-dependencies installed with --no-frozen-lockfile, so every job re-resolved the graph against the registry to recompute what the lockfile already pins. Measured at ~62 MB of packument metadata per job; the pnpm store cache does not cover the metadata cache, so this was paid ~39 times per run. The `git diff` guard that made the re-resolution redundant stays. - --ignore-scripts leaves node-pty with no build/Release, so ensure-native-runtime node-gyp-compiled it in every job asking for a runtime. Cache the build under an ABI-bound key (runtime, resolved Node version, node-pty patch) with no restore-keys, since a partial match is exactly the mismatched build that would be recompiled anyway. - The four fetch-depth: 0 checkouts pulled full history including every historical blob (blobs are ~89% of this repo's pack). They only need the commit graph for a merge-base diff, so fetch them blobless. Measured 30-43s each today versus 8s for the shallow checkouts. One of them, e2e-paths, gates the entire E2E chain. - E2E jobs ordered setup-node before pnpm, which meant setup-node could not find the store and no E2E job cached dependencies at all. Reorder and cache; this sits on the critical path in both the build job and each shard. - git_compatibility rebuilt Git 2.25.5 from a pinned tarball on every PR. Cache the build; the sha256 assertion still guards the miss path. - typecheck ran three independent tsc passes back to back and discarded the .tsbuildinfo each project already emits. Run them concurrently and cache the incremental state. - package (windows) built the electron-vite targets serially via build:release. Use a :parallel variant that overlaps them, matching what the Linux package job already packages and smoke-tests from. Contract tests cover each new cache's ordering and key so none of them can silently start serving a stale or ABI-mismatched artifact.	2026-08-17 19:20:13 -07:00
Neil	24e662adc1	feat(ssh): verify host keys, and restore panes correctly across a reconnect (#14844) ... * docs(ssh): design for real host key verification (STA-4319) Today's ssh2 verifier records a fingerprint and returns true — every host key is accepted, with no known_hosts consult and no change detection anywhere in src/main/ssh/. Scope is per-connection, so exec, SFTP, port forwarding, the watcher and relay deploy all ride that one unverified handshake, and the ProxyJump path puts the final hop — the topology most likely to cross untrusted network — on ssh2 specifically. Decisions worth calling out: - Read the user's known_hosts as a trust source but NEVER write to it. That file is shared with every other SSH tool on the machine; appending means line endings, permissions, concurrent writers and a corruption blast radius well beyond us. Accepted keys go to our own per-target store. Reading theirs is also the entire migration story: most developers already have their hosts there. - Mismatch is scoped to the SAME key type. A host with only an RSA entry that presents ed25519 is unknown, not changed. ssh2 negotiates ed25519 first, so without this we would fire a change-of-key alarm at nearly every existing user on their first upgraded connect — training them to dismiss the one warning that is supposed to mean something. Flagged in review as the decision I am least sure of; a downgrade-vector argument against it is being tested. - Changed key hard-fails with no override button; recovery is a separate explicit action, offered only when OUR store is what disagreed, because forgetting our record cannot unblock a known_hosts conflict. - Background reconnects deny rather than prompt. A dialog the user cannot place in context only teaches click-through. Two traps are documented because either would make the fix silently do nothing: an async verifier returns a Promise, which ssh2 reads as truthy and accepts immediately; and the existing test mock invokes hostVerifier with one argument and ignores the return, so it would pass against a verifier that never decides. Design only — no behaviour change. The doc is added to the tracked-reference allowlist in .gitignore alongside the other docs/reference entries. * docs(ssh): revise the host key design after security and migration review Three things the reviews changed, kept visible rather than quietly edited out. THREAT MODEL WAS WRONG IN THREE PLACES. Jump hosts are not the worst case — they are already safe: shouldUseSystemSshTransport branches on exactly the inputs resolveEffectiveProxy does, and attemptConnect returns after the system probe, so ProxyJump goes through OpenSSH and is verified. Agent forwarding was overstated (gated on the user's ForwardAgent). Credential theft was understated: any auth error counts as agent fallback, so a MITM walks the user to the password AND private-key passphrase prompts, and cachedPassword replays without prompting. The relay claim was backwards — the attacker owns their own machine; the real impact is the return direction, where they become the host our workspace trusts. TYPE SCOPING IS A DOWNGRADE VECTOR WITHOUT ALGORITHM ORDERING. This was the decision I flagged as least certain and asked to have argued both ways. OpenSSH is safe only because order_hostkeyalgs() puts known types first and RFC 4253 gives the client's order priority. ssh2 negotiates ed25519 first regardless, so an attacker who cannot forge the RSA key on file just presents ed25519 and gets a friendly first-contact prompt instead of a hard failure. Keep scoping, but set algorithms.serverHostKey to lead with the types on file — and add a sixth outcome for 'unknown type, known host', which must never read as first contact. SHIP THE DEFENCE BEFORE THE DIALOG. Startup restore fires eager connects for all targets in parallel with a 15s timeout while a prompt would live 120s; ephemeral VM targets present a new key every launch; paired-web connects run on the host desktop, so the dialog opens on someone else's screen. Phase 1 is therefore no modal at all: consult known_hosts and our store, match connects, unknown persists with accept-new semantics, mismatch and revoked hard-fail. That is the whole MITM defence with none of the migration risk. Also folded in, verified live against OpenSSH 10.2p1: the without-port fallback (bracketed lookup first, then bare, where the second pass can only yield match or unknown — otherwise a bare line plus a non-default port produces a spurious prompt); hashed entries hash the candidate form; multiple files union; a cert-authority line does not match a plain key. IPv6 and bracket parsing moved INTO scope — that is a parser requirement, not a scope call, and getting it wrong produces the prompt-training harm the design exists to avoid. * feat(ssh): parse and match OpenSSH known_hosts The matcher half of STA-4319. No behaviour change yet — nothing calls this. Hand-rolled because no maintained JS implementation exists, and written against behaviour observed from OpenSSH 10.2p1 rather than inferred from the man page. Three of those behaviours a reasonable reading gets wrong: - A non-default port is TWO ordered lookups, not one candidate set: '[host]:port' first, then bare host ('checking without port identifier' in ssh -v). The fallback pass can only yield match or unknown — OpenSSH downgrades a wrong key there rather than reporting a change. Collapse them and anyone holding a bare line who connects off-port gets a spurious first-contact result; treat the fallback as authoritative and they get a false change-of-key alarm. - Revocation resolves in its own pass so the verdict cannot depend on line order. Verified both orderings. - A cert-authority line never matches a plain host key; it only validates certificates. A normal line alongside it still decides. Mismatch is scoped to the same key type, and a host known by a DIFFERENT type returns unknown-type-known-host rather than plain unknown — an attacker who cannot forge the key on file must not get a friendly first-contact result by presenting another type. That outcome is only half the defence; the other half (leading serverHostKey with known types) lands with the wiring. 47 tests from vectors executed against real sshd, including ssh-keygen -H hashed entries. Each of six mutations reddens it: collapsing the passes, letting the fallback report mismatch, dropping type scoping, resolving revocation in line order, honouring an unrecognised marker, and skipping the blob/type agreement check. * feat(ssh): decide what to do with a presented host key The policy half of STA-4319, kept separate from the ssh2 wiring so it is testable without a handshake and injected rather than importing its sources, so a test states its own trust state instead of writing files. Phase 1 ships no dialog — a test asserts the decision is never 'prompt'. Startup restore opens every previously-active target at once, ephemeral VM targets would ask every launch, and paired-web connects run on the host desktop where the dialog would appear on someone else's screen. Ordering that matters: revocation outranks everything including StrictHostKeyChecking=no, because a revoked key is a statement that this key is known-bad rather than merely unrecognised. known_hosts is named before our own store on a change, because its remedy (ssh-keygen -R) is the one that also unblocks ssh and git — pointing at a remedy that cannot work is worse than none. Two carve-outs with reasons: an ephemeral runtime target accepts WITHOUT recording, since a fresh VM presents a new key every launch and a stored record would accumulate per launch and eventually read as a spurious change; and when ssh -G ran on the HOME-divergent path that suppresses /etc/ssh/ssh_config, an unknown host is denied, because a site-wide policy may forbid it and being laxer than ssh is the one outcome that is never acceptable. Rejection text deliberately avoids 'authentication failed' and 'permission denied': the reconnect ladder classifies on those substrings, so a denial phrased that way is retried forever against a decision that will never change. Pinned by a test. * feat(ssh): build the host key verifier and the algorithm order that makes it safe Still not wired into the handshake — that lands next. This is the piece that turns a decision into an ssh2 callback, plus the half of the design that is easy to forget because it lives in a different config field. The verifier MUST be a plain function returning undefined. ssh2 does 'const ret = verifier(key, verify); if (ret !== undefined) verify(ret)', so an async function returns a Promise — neither undefined nor falsy — and ssh2 accepts the key immediately while ignoring whatever the callback later decides. Making this async would silently restore exactly the accept-everything behaviour the module exists to remove, so a test asserts the return value is undefined. orderServerHostKeyAlgorithms is what makes type-scoped matching safe rather than a downgrade. RFC 4253 gives the client's algorithm order priority, so leading with the types we already hold for a host denies a server the choice of presenting some other type to convert a hard failure into first contact. Without it, an attacker who cannot forge the key on file just offers a different algorithm. Revoked entries never contribute to that order. Also fails closed on two paths that would otherwise hang or over-trust: a key whose own length-prefixed header cannot be read is refused rather than reasoned about, and a throw from any dependency denies, because ssh2 may not catch an exception raised inside the verifier and the handshake would hang instead of failing. 18 tests. Includes the two negative cases that matter — first-contact keys are recorded, but keys we already know, rejected keys, ephemeral runtime targets and a lax StrictHostKeyChecking are not. * fix(ssh): promote every RSA signature algorithm for a known ssh-rsa key A known_hosts entry names the KEY type, which is not the negotiated ALGORITHM name. One ssh-rsa key is offered as rsa-sha2-512, rsa-sha2-256 or ssh-rsa depending on the signature algorithm, so matching the literal name only would leave a host we know by RSA ordered behind ed25519 — precisely the ordering this function exists to prevent, and precisely the population (RSA-era known_hosts entries) it was written for. Verified from ssh2's own negotiation while wiring this: kex.js iterates the CLIENT list and takes the first entry the server also offers, so client order does decide, as RFC 4253 says. ssh2's default order leads with ed25519 and places the RSA algorithms fifth through seventh. * fix(ssh): verify host keys instead of accepting every one (STA-4319) The actual fix. ssh-connection's verifier recorded a fingerprint and returned true, so every ssh2 connection accepted every host key — no known_hosts consult, no change detection. It now consults the user's known_hosts plus our own store and refuses a changed, revoked or unverifiable key. Phase 1 by design: no dialog. Unknown hosts are accepted and recorded (accept-new semantics), because startup restore opens every previously-active target at once, ephemeral VM targets present a new key each launch, and paired-web connects run on the host desktop where a prompt would appear on someone else's screen. The MITM defence lands now; the prompt is Phase 2. Also sets algorithms.serverHostKey to lead with the types already known for the host. Without it the type-scoped matching is a downgrade — an attacker who cannot forge the key on file just presents another type and turns a hard failure into first contact. Verified from ssh2's kex.js that the client list decides. Denial replaces ssh2's generic handshake error with the specific reason, because the reconnect ladder cannot distinguish a generic failure from a transient fault and would retry forever against a decision that will never change. An unreadable trust store degrades to known_hosts only rather than failing the connect: a changed key is still refused, and a host trusted only by us falls back to first contact and is re-recorded, reaching the same decision. The ssh2 mock now uses the callback form and aborts the handshake on denial. As written it called hostVerifier(key) with one argument and ignored the result, so it would have passed against a verifier that never decides — flagged in the design as a mock that had to change, not a test to quietly rewrite. Two new tests pin the wiring rather than the module: an unidentifiable blob is refused, and a well-formed key is accepted. Note for review: commit 2d2a0880ba unintentionally swept in two modules built concurrently (ssh-known-hosts-source, ssh-host-key-store) because I staged with 'git add -A'; its message describes only the verifier. Both are covered by their own tests, but the attribution in that commit is wrong. 1461 SSH tests pass. * fix(ssh): bind the host key store to the active profile at startup Without this the store reports nothing trusted on every launch. Safe — known_hosts still decides, and a host trusted only by us degrades to first contact and is re-recorded — but it silently discarded our own accept records, so the store the design calls for was not actually in use. Bound beside the profile Store, since it is a sidecar of the same data file. Also records why the paired-web carve-out the migration review asked for is NOT implemented in Phase 1, rather than leaving it looking forgotten. That carve-out exists to stop a web client waiting out the 120s prompt timeout — a hang only reachable if a prompt exists, and Phase 1 has none, which the decision function pins with a test asserting it never returns 'prompt'. An RPC connect therefore behaves exactly like a local one. Adding a fail-fast path now would introduce a failure mode for a hang that cannot occur; it becomes load-bearing when the dialog lands and is listed under Phase 2. Noted there for whoever builds Phase 2: runtime/rpc/methods/ssh.ts already swallows the specific error and rethrows a generic one, so the host-key reason will not reach a web user without a change there too. Full unit suite: 52,352 pass. The 8 failures are the known environment baseline (5 osc8, 2 IME) plus one browser-cookie suite-ordering flake that passes in isolation — none in src/main/ssh, and none related to this change. * fix(ssh): close two downgrades the implementation review found Both were in my wiring, not the design, and two reviewers found the first independently. 1. OUR STORE WAS TYPE-DOWNGRADABLE. The inline lookup filtered by key type first and could only answer match/mismatch/unknown, so a record of a DIFFERENT type for the same endpoint read as "unknown". A host learned on first contact — ed25519, since ssh2 proposes it first — and absent from known_hosts could then be impersonated by presenting RSA: both sources say unknown, so accept-and-remember, silently. That is exactly the downgrade D3 says the design cannot ship without, applied to the records we create ourselves. The store's own isTrusted already computed the right answer and had no production caller. Stored types now also feed the algorithm ordering, without which the guard is only half present. 2. WE KEYED ON THE ORCA LABEL, NOT THE DIALED HOST. "ssh -G" echoes its own argument back as its hostname field when no Host block matches, so for a manual target that field IS the Orca label — the one name D2 forbids keying on, and one ssh never wrote. We consulted no entries at all, so an impersonated host read as first contact. Now keys on the dialed host, which buildConnectConfig has already resolved through HostName, with HostKeyAlias still winning. That inverted an existing test rather than deleting it: "uses the resolved hostname, never the Orca label" encoded an assumption disproved against OpenSSH 10.2p1, so it is renamed and reversed with the reason recorded in the test. 3. NO READABLE SOURCE IS NOT FIRST CONTACT. Every known_hosts file failing to read was indistinguishable from "this host is unknown", so a changed key would be accepted the one time we could not check. The loader now reports how many files it could read, and zero readable sources with an empty store takes the strict path instead of recording trust. 4. A superseded attempt's rejection could replace the live attempt's error, and substituting a new Error drops ssh2's code, so a transient ECONNRESET would stop being classified as retryable. The rejection is now local to its attempt. 5. displayHost was the Orca label, so a mismatch could print "ssh-keygen -R <label>" — a remedy that removes nothing. Also adds the tests that would have caught 1 and 2, the stale-attempt denial, and IPv6 literals, which the design moved into scope and nothing covered. 1,469 SSH tests pass. * fix(ssh): stop offering credentials to a host we just refused A refused host key ended the handshake and then fell into the credential ladder, because ssh2 reports a denied key as a generic auth failure and the passphrase branch is eligible on message shape alone whenever an encrypted identity file is configured. So the sequence was: decide this host may not be who it claims to be, then ask the user for their passphrase and hand it to it. Failing that, prompt for a password. Failing that, retry over the system ssh binary, which for a disagreement with our own store rather than known_hosts would simply connect. That inverts the point of checking at all. A denied key is now final for the attempt: recognised by type before any fallback runs, and again inside the agent-fallback retry, which re-runs the handshake and so can be the attempt that denies. Two things had to change for that to hold. The rejection is now a HostKeyVerificationError rather than a rebuilt Error, so the connect path recognises it by type. Substring matching would have worked today and quietly stopped working the first time a reason string was reworded — and these strings are already worded around the auth-error classifier, so they are exactly the kind that get edited. And the verifier now reports the denials that skipped the policy: an unreadable key blob and an internal failure both denied without calling onDecision, so the connect path saw only ssh2's generic failure and walked the ladder. That was the actual path the new test hit first. The report carries no fingerprint, since there is no host key to identify, and the connection no longer overwrites the fingerprint it holds with an empty one — the relay keys install-lock isolation on that value. The reconnect ladder also refuses to retry it. Its classifier is otherwise substring-driven, so a reason containing "connection reset" would have been retried until the ladder gave up, burying the reason under nine attempts. Tests: no credential prompt after a refusal, an encrypted key configured so the passphrase branch is eligible; refused reports as 'error', not 'auth-failed', which would invite the user to re-enter credentials that are not the problem; no retry; both bypassing denials report; a throwing listener still denies rather than hanging the handshake. Also drops three test files a bisect resurrected from before the revert that deleted them. 172 tests pass across the three touched files; typecheck and lint clean. Pre-existing on origin/main and untouched here: 3 failures in ssh-connection-sftp-namespace.test.ts. * fix(ssh): stop treating an absent known_hosts as a source we failed to read The previous commit's "no readable source is not first contact" guard was right about the danger and wrong about how to detect it, and the version that shipped would have refused every connection a new profile ever makes. A file that does not exist and a file that refuses to open both arrive as a rejected readFile, and I counted them the same way. They are opposites. An absent known_hosts is the normal state — ssh creates it on its own first connect, and an Orca profile that has never connected has none — and it is real evidence that no host is known. A file that exists and will not open is evidence withheld: the entry that would have said "this key changed" may be sitting in it. The default list is the reason this was fatal rather than obscure. It always names known_hosts2, which essentially never exists, so on a machine with a normal known_hosts the count was 1-of-2 and everything worked; on a fresh profile it was 0-of-2 and every connect failed with "the system SSH configuration could not be read" — a message about a file the user does not have and an error they cannot act on. The suite passed only because the machine running it happens to have a known_hosts. Pointing HOME at an empty directory fails 62 connection tests, which is what the new wiring test does. So the count is now unreadableFileCount: files that exist and could not be read, which is the condition the guard was always trying to express. Any one of them takes the strict path; an absent or empty file takes none. The store clause is gone with it — a store hit already returns accept before this is consulted, so it never changed an outcome. Tests: absent, empty, permission-denied, directory, and all-parsed at the source; first contact with no known_hosts at all at the wiring level. 1,482 SSH tests pass. The 3 failures in ssh-connection-sftp-namespace.test.ts are pre-existing on origin/main and untouched here. * fix(ssh): let an ephemeral runtime outrank sources we could not read Three things, all about the same question: when we cannot see everything that decides a host key, what does that actually license us to refuse? 1. ON-DEMAND RUNTIMES WERE REFUSED FOR A POLICY THEY COULD NEVER SATISFY. A machine provisioned a minute ago cannot be in known_hosts, by construction — which is why it has a carve-out at all. But the carve-out sat BELOW the incomplete-sources check, so anyone whose HOME diverges from their passwd home (sandboxes, our own E2E isolation) took the `-F` path, and every on-demand runtime connection was refused, pointing at a config file the user cannot fix. Refusing there buys nothing. No policy, seen or unseen, is satisfiable by a host that did not exist yesterday; the trust comes from the provisioning channel. So the carve-out now outranks it. An EXPLICIT StrictHostKeyChecking=yes still wins over both — that one we can read, and the user asked for it. 2. THE FLAG WAS NAMED FOR ONE OF ITS TWO MEANINGS. `siteConfigSuppressed` started as "-F hid /etc/ssh/ssh_config" and had since grown "a known_hosts file exists and would not open" — which is not a site config, and reading the name in the decision function told you nothing about why an unreadable file landed there. It is `verificationSourcesIncomplete` now: we could not see something that decides this, so do not extend NEW trust. A host we already know still connects, because a match is decided before this is reached, and that is now pinned by name. 3. THE COPIED ssh2 ALGORITHM LIST HAD NO DRIFT ALARM. We reorder ssh2's default host-key proposal, which meant hand-copying a list ssh2 exports only from a deep internal path. ssh2 throws `Unsupported algorithm` on anything outside its supported list, so drift does not degrade — every target stops connecting, before a socket opens, with a message about an algorithm the user never chose. Worth knowing that the list is also built conditionally on ed25519 support. Kept as a literal rather than a deep import, since silently adopting a new proposal order is the wrong default — the order is what makes type-scoped matching safe, so a change deserves review. A test now compares it against ssh2's real constant and checks every entry is one ssh2 accepts. Moved next to the ordering function it feeds, and out from between the import statements. 1,488 SSH tests pass. The 3 in ssh-connection-sftp-namespace.test.ts are pre-existing on origin/main. * docs(ssh): record what review changed and the STA-4319 follow-ups The design survived implementation; every defect found afterwards was in the wiring. Worth recording the pattern, because it repeated five times: each one made us either blind or unusable, never subtly wrong — and four of the five broke legitimate hosts rather than admitting bad ones. Action items separate the things Phase 2 must decide (UpdateHostKeys, which is now the likeliest way a legitimate user meets a rejection; the web client never seeing the reason; RPC fail-fast) from the gaps Phase 1 knowingly accepts (WSL, CheckHostIP, ca-only hosts, the hand-copied ssh2 algorithm list). Also flags the rollout risk plainly: this is the first release in which Orca can refuse an SSH connection at all. * test(ssh): pin the ephemeral carve-out where it is actually observable The first version of this test asserted an on-demand runtime connects on first contact, which every target does — it would have passed with the carve-out deleted. Pointing HOME at a home whose known_hosts exists and will not open makes the two cases diverge: a normal target is refused there, an on-demand runtime is not. Removing the carve-out now fails three tests instead of none. Also covers the wiring for the unreadable-source refusal itself, which until now was only pinned at the decision level. * test(ssh): pin the parser against real ssh -G output, and accept-new against ask Two gaps the audit named. The ssh -G fixtures were all hand-written, which means they encode what I expect ssh to print. This one is verbatim OpenSSH_10.2p1 output for a Host block using HostName, HostKeyAlias, StrictHostKeyChecking accept-new, two UserKnownHostsFile paths and a non-default port. The format detail that matters: each file list arrives space-separated on ONE line, so reading it as a single path would consult nothing for anyone with more than one file configured. And accept-new was untested despite being a real OpenSSH value. It currently behaves identically to ask, which is exactly right while no dialog exists and is what lets the defence ship without a modal — so the equivalence is now pinned, and Phase 2 has to break it deliberately rather than discover it. Plus a guard that accept-new never falls into the strict branch. * test(ssh): cover the wire from an accepted key to a record on disk Nothing covered the store end to end. Every connection test runs with it unwired — a real path, since it degrades to known_hosts only — so an accepted first-contact key was never observed becoming a record, and the record was never observed being believed on the next connection. Without that wire the store is dead weight: an unknown host connects every time and is never learned. Its own file for two reasons. initSshHostKeyStoreFile binds module-level state for the rest of the process, and binding it makes the connect prelude do real disk I/O — which the shared suite cannot absorb, because its reconnect tests drive the clock with fake timers and an fs round trip does not complete inside an advanced tick. Adding these there turned 12 unrelated tests red. Covers: the record is written; it is read back as a match; the same key is not recorded twice; a DIFFERENT key for a host we recorded ourselves is refused (the store's entire security value, and a case known_hosts cannot catch since it has never heard of the host); and an on-demand runtime records nothing. Stubbing rememberHostKey to a no-op fails four of the five. * fix(settings): stop truncating the SSH connection error to one line The host key messages are written to be actionable — a mismatch ends in "Run: ssh-keygen -R <host>", which is the remedy that also unblocks ssh and git. The only place in the renderer that displays an SSH connection error clamped it to a single line with `truncate` and carried no title attribute, so the remedy was unreachable, not even on hover. The careful wording reached a CSS ellipsis. Wraps instead, with [overflow-wrap:anywhere] because a long hostname offers no break opportunity and would overflow the column on its own. The paragraph only renders on failure, so the extra height costs nothing in the normal case. CORRECTION to the four preceding commits: they each claimed 3 pre-existing failures in ssh-connection-sftp-namespace.test.ts. That was my error — I had been running `npx vitest` without `--config config/vitest.config.ts`, so the project's setupFiles and execArgv were absent. Under the real config those 3 pass, and have throughout. The whole SSH suite is green: 1,504 passed, 13 skipped. Still failing on this branch and unrelated to it (different subsystems, no file overlap): 5 in terminal-snapshot-osc8-roundtrip and 2 in browser-cookie-import. * fix(terminal): show why the SSH connection failed, not just that it did The reconnect overlay took only a status, so every failure rendered the same sentence: "The SSH connection to devbox failed. Connect again to continue this terminal session." A refused host key and a network timeout were indistinguishable there, and the host key message — the only place that names the remedy, down to `ssh-keygen -R <host>` — reached no terminal user at all. The state carried it the whole way; the overlay simply never asked for it. Adds it as a second line rather than replacing the sentence. The sentence says what to do, the detail says what happened, and keeping both means an errno failure does not lose its guidance to make room for "connect ETIMEDOUT". Wrapped, for the same reason as the settings card: the remedy is at the end. Suppressed for a removed target, which already explains itself and can never reconnect — a stale connection error underneath would contradict it. The new selector mirrors selectRuntimeAwareSshStatus branch for branch, including the unreachable-environment and un-hydrated-bucket nulls, so the pair cannot disagree about which source they read and a detail is never shown next to a status it did not come from. Known and NOT addressed here: "Connect again" is still the wrong advice for a decision that will never change. Telling those apart needs a typed reason on the wire rather than a string, which is a remote-wire-compatibility decision; it is recorded in the STA-4319 follow-ups. Pre-existing on this branch and untouched: 2 failures in terminal-ime-xterm-resumed-preedit-visibility. * docs(ssh): record where the rejection message actually lands Traced end to end, because a rejection the user cannot read is a half-shipped feature — and two of the surfaces were dropping it entirely, both now fixed. What is left is written down rather than guessed at: the status bar renders only 'Error', the terminal overlay's call to action still invites a retry that cannot succeed, toasts carry Electron's remote-method prefix, and the paired-web path replaces the text with 'SSH connection unavailable' on every route — which also affects a DESKTOP user viewing a host owned by a remote Orca server, not just web clients. * refactor(ssh): give the store one matcher instead of two The connect path had its own copy of the store comparison, because ssh2's verifier decides synchronously and cannot await the file, so records are preloaded. That copy is precisely where the type downgrade came from: it answered only match/mismatch/unknown, so a record of a different type for the same endpoint read as first contact and a host learned on first contact could be impersonated by presenting another key type. Fixing it left two implementations that have to agree forever, which is the same bug waiting to happen. matchTrustedHostKeys is now the single pure matcher; isTrusted is a load plus a call to it, and the connect path calls it directly on preloaded records. Same for the key types that feed the algorithm ordering, which the connect path was also filtering by hand. The two copies had in fact already drifted: the connect path lower-cased the query host where the write trims AND lower-cases. Not reachable today — the host is trimmed before it reaches there, which I confirmed by mutating the normalisation and watching the wiring test pass anyway. So this is not a bug fix, and the wiring-level test I first wrote for it proved nothing and is gone. The unit test that replaces it drives the matcher directly, where the input is mine to control, and it does fail when the normalisation diverges. Also adds an equivalence test across all six outcomes between the preloaded and awaited paths, so the two can never answer differently again. Restores the local name siteConfigSuppressed for the `-F` check; it was renamed along with the decision input, but at that site it really does mean only the one thing, and the union with the unreadable-file count happens one line later. 1,509 SSH tests pass. * test(ssh): check the matcher against a live OpenSSH client, not against my beliefs Every other test in the parser file states what I believe ssh does. These state what it did: an OpenSSH 10.2p1 client against a real sshd on 127.0.0.1:2222, with the client's own verdict recorded from its output, and ssh-keygen -H's own salt and hash pinned as a vector. Two assumptions the design leans on were worth more than an argument. THE FALLBACK PASS MAY NOT REPORT A CHANGE. We look up `[host]:port` first and retry the bare host, and only the first pass may answer `mismatch`. With StrictHostKeyChecking=accept-new, a bare line holding a DIFFERENT key, dialed on 2222, ssh connected and appended a new `[127.0.0.1]:2222` line — no IDENTIFICATION HAS CHANGED banner. It read that as first contact. Had we reported a change there we would refuse hosts ssh connects to happily, and the wrongness would have been invisible: refusing looks like the cautious choice. AND THE TYPE-SCOPING REJECTION IS NOT AN INVENTION. known_hosts holding an ssh-rsa key while the server offers ed25519 makes ssh print IDENTIFICATION HAS CHANGED and refuse. So unknown-type-known-host is neither stricter nor laxer than ssh — treating it as first contact, which is what a naive type-scoped lookup does, is the laxer mistake. That second result also fixes the message. ssh is blocked too, so `ssh-keygen -R <host>` is the remedy that unblocks both, and we were naming it only for a same-type mismatch — leaving this case with a diagnosis and no way out. Named now when known_hosts is the source that disagrees, and still not named when it is our own store, which ssh-keygen would not touch. 1,516 SSH tests pass. * docs(ssh): record the two assumptions a live client confirmed Both were load-bearing and neither was obvious: the bare-host fallback pass may not report a change, and unknown-type-known-host is what ssh itself does rather than something we invented. Getting the first backwards would have refused hosts ssh connects to happily, which is the failure mode that looks like caution. * style(ssh): satisfy the code-quality lints in the two new test files A string concatenation that should be a template literal, and an inline import() type annotation that should be a type-only namespace import — erased before vi.mock's hoisted factory runs, so the mock is unaffected. pnpm lint is clean. * fix(ssh): honour StrictHostKeyChecking, which had never once been read correctly `ssh -G` does not echo the value the user wrote. StrictHostKeyChecking is rendered through fmt_multistate_int, which prints the first entry of multistate_strict_hostkey, and that table lists true/false before yes/no: yes -> true | no -> false | off -> false | accept-new -> accept-new | ask -> ask Verified against OpenSSH 10.2p1 from both a config file and -o. Not 10.2-specific; the table ordering is old. The decision function tested only 'yes'/'always' and 'no'/'off' — spellings that cannot arrive. So `StrictHostKeyChecking yes` fell through to the default branch and we accepted AND PERSISTED a host the user's config explicitly says to refuse. That is the worst outcome this feature can produce, and it was the behaviour for every strict user from the first commit. `no`/`off` landed there too, breaking the documented "lax settings never persist" invariant. Every unit test passed throughout, because they fed the function 'yes' — the value a human writes, not the one that reaches the code. My ssh -G parity test did capture real output, but I happened to configure accept-new, one of only two values that round-trip unchanged. The new table is keyed on configured value -> what ssh -G actually prints, and asserts both reach the same verdict, so the question "is this the spelling that arrives?" cannot be assumed again. Found by a parity review against a live OpenSSH client. * fix(ssh): stop the fallback pass accepting a changed key, and refusing a new one One wrong loop scope, two opposite errors, both reproduced against a live OpenSSH 10.2p1 client and an ed25519-only sshd on 127.0.0.1:2223. ACCEPTING A CHANGED KEY. ssh runs the bare-host fallback only when the port-qualified lookup matched no plain entry of ANY key type. We ran it unless pass 0 produced a match or a SAME-TYPE mismatch. So with an off-port RSA entry plus a bare, correct ed25519 line — an ordinary shape, an old off-port entry beside one written by a port-22 connect — ssh printed IDENTIFICATION HAS CHANGED and refused, with no "checking without port identifier" in -v because the fallback never ran, while we reached the bare line and returned `match`. REFUSING A NEW ONE. sawKnownHostOtherType and sawCertAuthority were declared outside the pass loop, so an entry found only on the fallback pass could set them. A bare ssh-rsa entry, dialed on a non-default port against an ed25519-only server, made ssh add the host and connect — plain first contact — where we returned unknown-type-known-host and hard-failed. That is Gitea/Forgejo, dev containers, Gerrit, Vagrant: an off-port service on a host already in known_hosts. So the flags are per-pass now, and pass 0 decides as soon as it finds any plain entry for the host. Which of the two rejections it reports only picks the message; ssh calls both HOST_CHANGED. Also drops the type check from the match test: byte equality already implies the types agree, because the blob carries its own algorithm name and parsing rejects any line whose declared type disagrees with it. Reverting either half of the scope fix fails exactly the two new tests. 1,526 SSH tests pass. * fix(ssh): refuse the known_hosts lines ssh itself refuses to parse Three ways a line could be trusted by us and invisible to the user's own ssh — or, worse, raise a CHANGED alarm from an entry ssh drops. Buffer.from does not fail on bad base64, it SKIPS invalid characters, so `<key>!!!` and a blob with `@@` spliced into it both decoded to the correct key and matched. Verified live against OpenSSH 10.2p1 on 127.0.0.1:2224: the unmodified control reached authentication and all three malformed variants produced "No ED25519 host key is known". A re-encode-and-compare makes us agree. `<key>AAAA` is the interesting one, and the reason the first fix was not enough: 68 characters plus 4 is still legal base64, and the algorithm header still reads ssh-ed25519, so neither the base64 check nor the existing header check sees anything wrong. ssh parses the whole key structure. We decoded 54 bytes where an ed25519 key is 51 and reported `mismatch` — a man-in-the-middle warning caused by a typo in a file ssh silently ignores. So the blob is now walked as what it is: a run of length-prefixed fields that must consume it exactly. Algorithm-agnostic on purpose, so a key type we do not model is checked as well as one we do. It also rejects a length prefix that overruns the buffer, which readHostKeyType only checked for the first field. And ssh's extract_salt demands exactly one SHA1 digest — "expected salt len 20, got 16" — where we accepted any non-empty salt. A short salt is still a usable HMAC key for us, so a hand-crafted line could match for us and be a parse error for ssh. ssh-keygen -H always writes 20 bytes, so refusing loses no real entry. Worth recording that ssh-keygen -F cannot answer any of this: it matches host names and prints lines without ever decoding the key, so it reports "found" for all four blobs. The real client was the only instrument that worked. Found by a parity review; the base64 finding as reported was right about the behaviour and wrong about the mechanism for the padded case, which is what led to the structural check. 1,533 SSH tests pass. * fix(ssh): name a ssh-keygen -R target that actually removes the entry Verified against OpenSSH 10.2p1: with both `[h.example]:2222` and `h.example` on file, `ssh-keygen -R h.example` removes only the bare line and leaves the bracketed one — and there is no port flag, `-R host -p 2222` is "Too many arguments". An off-port target is keyed `[host]:port` in known_hosts, so the command we printed removed nothing: the user runs it, reconnects, and meets the identical failure with no indication of why. The message now names the bracketed form, quoted because the brackets are shell glob characters, whenever the port is not 22. Found by a parity review. * fix(ssh): read ssh2's host key algorithm list instead of copying it ssh2 builds DEFAULT_SERVER_HOST_KEY at load time and prepends ssh-ed25519 only when a RUNTIME PROBE succeeds — it signs and verifies with a fixed Ed25519 key. On a build where that probe fails, ssh-ed25519 is absent from ssh2's SUPPORTED list too, and generateAlgorithmList throws `Unsupported algorithm: ssh-ed25519` from inside client.connect. That throw matches no retry classifier and no transport-fallback classifier, so it is permanent — and because we only set `algorithms` for hosts we already know, it would fire on trusted hosts while new ones kept working. A copied list cannot be merely stale here; it can be wrong. So it is read from ssh2 now, which also removes the drift risk the previous commit could only report. ssh2 is external in the main bundle and the bundle is CJS, so the deep path resolves at runtime from packaged node_modules. The copy stays as a fallback in case a future ssh2 moves the file — losing the proposal order degrades the type-scoping guarantee, but refusing to connect at all is worse. The test that used to pin the copy against ssh2 now pins the fallback, which is the only part that can still drift. Found by an availability review. pnpm lint clean; 1,537 SSH tests pass. * fix(ssh): look a HostKeyAlias up the way ssh does — without the port HostKeyAlias suppresses the port entirely. Verified against OpenSSH 10.2p1 on port 2225 with HostKeyAlias=myalias: an entry keyed `myalias` authenticates, and one keyed `[myalias]:2225` gives "No ED25519 host key is known for myalias". We built [['[alias]:port'], ['alias']] and consulted a form ssh never writes. On its own that was a stale-entry false alarm. The previous commit made it worse: now that the first pass decides as soon as it finds any entry for the host, a leftover `[alias]:2225` line STOPS the bare lookup ssh actually performs — so the one population D2 cites HostKeyAlias for, bastions tunnelled through localhost:port, would get a hard failure on a host ssh connects to. So resolveKnownHostsLookupHost reports whether the name came from the alias, not just what it is, and that flag reaches both the matcher and the algorithm ordering. Returning the name alone is what made the bug invisible: the caller had no way to know it was holding something that must not be bracketed. Found by a parity review. 1,543 SSH tests pass. * fix(ssh): only claim the site config was suppressed when ssh -G actually ran sshGArgsForHost reports which arguments WOULD be used, not what happened. It returns the -F form whenever ~/.ssh/config exists and os.homedir() diverges from the passwd home, so a machine with no usable ssh at all — Windows without OpenSSH, a restricted sandbox, a timed-out probe — was judged by whether it happens to have a ~/.ssh/config, and rejected every unknown host permanently if it did. The same broken machine WITHOUT one stayed fully permissive, which is the tell: the flag is a claim about a config file we could not read, and when ssh never ran there is no such claim to make. Narrow but total where it lands: anything that sets HOME explicitly (wrapper scripts, sudo -E, devcontainers), macOS mobile and network accounts, and the E2E isolation this branch was written for. Found by an availability review. * fix(ssh): stop refusing hosts that ssh itself connects to Two product decisions, both taken deliberately after a review priced their blast radius, and both moving us from stricter-than-ssh to matching it. CERTIFICATE-AUTHORITY HOSTS NO LONGER FAIL. The point of an SSH CA is that the client holds ONE line — very often `@cert-authority *` — instead of per-host entries. That line matches every candidate, so for a Teleport / Vault-SSH / Smallstep / in-house-CA user EVERY target failed, not just CA-signed ones, including on-demand runtime VMs, and StrictHostKeyChecking=no did not help. The documented escape was an environment variable, which an Electron app launched from the Dock or Start Menu never sees. Meanwhile OpenSSH, verified live, treats a CA-covered host presenting a plain key as first contact and connects: ssh2 cannot validate certificates at all, so refusing bought nothing ssh was not already giving up. The residual risk is real and accepted — for a CA-protected host we take a plain key we cannot tie to the CA — and the ca-only outcome is carried through the decision so it stays visible in the log. AN UNREADABLE known_hosts NO LONGER REFUSES EVERYTHING. Any non-ENOENT read error on any configured file rejected every unknown host, with a message blaming the system SSH configuration, which was not what happened. The common trigger is not exotic: a Windows OneDrive Known Folder Move placeholder while offline fails with a cloud-file error, not ENOENT. It was also asymmetric with our own store, which degrades an unreadable file to "nothing trusted" and connects. We now connect as ssh does — it warns and treats the host as unknown — but record NOTHING, so a first contact we could not check never becomes durable trust. That second half is the reason the first is acceptable, so it is pinned end to end with the store actually bound. Which meant splitting verificationSourcesIncomplete back apart. It had been one flag for two claims that now diverge: "a site policy may exist that we cannot read" still refuses, "a file we could not open may contradict this" does not. Merging them was what made the second inherit a strictness only the first justified. Both still lose to evidence we DID read: a mismatch, a revoked key, or an explicit StrictHostKeyChecking still refuse in either state. pnpm lint clean; 1,549 SSH tests pass. * docs(ssh): correct the design where a live client disproved it D2, D3 and D4 each stated something about OpenSSH that turned out to be wrong when tested against a real client and sshd rather than read from the source. D3's premise is the notable one: OpenSSH is not type-scoped at all, so it does not avoid the RSA-era false alarm the way the doc claimed. It avoids the situation via order_hostkeyalgs and hard-fails when the situation arises anyway. The conclusion survives — the ordering is still what makes our scoping safe — but for a different reason than the one written down, and a reader would have drawn the wrong lesson. D2 gains the two rules that actually bite: the entry condition to the fallback pass, and HostKeyAlias suppressing the port. D4 records both reversals with their reasoning and the residual risk each one accepts, and the ssh -G spelling trap that made StrictHostKeyChecking dead on arrival. Corrections are kept visible rather than edited out, per the note at the top of the file. * fix(ssh): repaint the panes after a reconnect, not just reattach them Reported: disconnect an SSH host from the Remote Hosts popup, reconnect, and the terminals come back blank — but resizing a split or toggling the sidebar makes them render correctly. That last detail is the diagnosis. The panes were never broken: reattach restores each pane's buffer but not its painted frame. xterm repaints on a write or a resize, and a reconnect produces neither for a pane that was already correctly sized — so nothing paints until a relayout forces it, which is exactly what resizing or toggling the sidebar does. The renderer already has refitAndRefreshAllTerminalPanes for this shape ('after bulk desktop restore, background panes may have correct cols/rows but a stale xterm renderer until focus forces a repaint'). Its only callers were the mobile fit-reclaim paths; the SSH reconnect path never used it. Scheduled from finalizeHydratedTerminalPanes, on both a frame and a 100ms settled pass — the same pattern the desktop-restore path uses, because rAF alone lands while panes are still remounting. Mutation-proved: removing the schedule reddens the new test, which is the reported symptom. * fix(ssh): repaint background-tab panes revealed after a reconnect Completes 834a495038, which only fixed the ACTIVE tab. Reported: split panes of plain shells on another tab were still blank after reconnect until a divider drag or a sidebar toggle. The repaint did reach background managers — they stay mounted, only rendererVisible flips — but it could not land. A tab-hidden pane measures as a 0-size box, so canMeasurePaneForFit bails and the fit is a no-op, and refreshAllPanes marks rows dirty on a pane with no presented frame, which cannot repair a grid the reattach's direct terminal.resize left diverged. The reveal then takes the light resume path, which deliberately does not fit, and scheduleRevealRepaint only reattaches WebGL. So nothing ever fixed the geometry — and a divider drag or sidebar toggle is a real fit, which is why those appeared to work. Parks the repaint on a hidden manager and replays it on reveal, reusing the existing reveal-fit machinery rather than adding a mechanism. Flag-gated so the light path still does not fit in the ordinary case — 'does not fit on a light tab reveal' stays green. Splits are not special: the gap is per-manager, so it is identical for 1 or N panes. Splits just expose it, because users find the workaround (drag a divider) that a single full-tab pane rarely gets. A never-mounted tab is unaffected — it has no live manager and fits through the normal initial-fit lifecycle. Mutation-proved twice: removing the deferral, and reverting the reveal-side condition. Each reddens only the new tests. * test(terminal): pin that panes are PAINTED, not merely bound — and fix a broken commit Two problems, both mine. 1) 0103a80b48 swept in an untracked fixture and left the branch failing typecheck (unused Terminal import in painted-pane-fixture.ts). Its canvas stub also threw 'clearRect is not a function' on every refresh. Fixed here. 2) direct-ssh-reconnect-repaint.test.ts, which I wrote to guard the reconnect repaint, is VACUOUS: it re-implements finalizeHydratedTerminalPanes inside the test and mocks the registry, so deleting the real fix from useIpcEvents leaves it green. direct-ssh-reconnect-repaint-wiring.test.ts replaces that guarantee by capturing the real callback the hook hands the coordinator and running it against live panes — deleting the two scheduling lines now reddens it. The gap this closes: content survival was already well covered at the BYTE layer (snapshot roundtrip, hide/reveal stitching, cold-restore scrollback), but every pane test stubbed terminal as {cols, rows, refresh: vi.fn()}, so 'repainted' only ever meant 'a spy fired'. No test ran a real xterm through a real PaneManager. pane-content-survival.test.ts does, reading .xterm-rows — what the user actually sees — across reconnect, restart-shaped restore, tab reveal, window show, split and unsplit, for plain shells and alt-screen TUIs. The alt-screen distinction is now pinned explicitly: forcing a resize inside fitAllPanes reddens only the TUI test, because a plain shell reflows and survives while a TUI frame does not. That asymmetry is why the reported bug looked like a plain-shell problem. 11 tests, each mutation-proven to redden only its own. 760 pane-manager tests green; the 2 failures here are the known environmental IME baseline. Flagged, not fixed: the unsplit path reparents the DOM without the dispose/ reattach that splitManagedPane does explicitly because 'DOM reparenting can silently invalidate a WebGL context without firing contextlost', and follows it with a safeFit that no-ops when the box is unchanged. Same shape as the reconnect bug. happy-dom has no WebGL, so only a real-GPU E2E can confirm it. * fix(ssh): send the pane its screen back on reconnect A reconnect left every remote terminal blank. Measured on a live relay, not inferred: pty.attach returned no replay for every pane, taking the activation === 'existing' early return in the relay's attach. 'existing' means a source delivery is already open for this client, so it must already be receiving live output and cannot need its screen re-sent. That holds for a duplicate attach. It is false for a reconnect, for a reason neither side can see alone: the client keeps its id across the drop (detachClient refuses to detach the primary, and setWrite revives that same id) so the delivery outlives the dead transport, while the RENDERER has already thrown its terminal away. A reconnect bumps tab.generation, which is the pane's React key, so TerminalPane remounts and the old xterm is disposed with its buffer, and nothing on that path captures it first. Both halves are individually reasonable and together they guarantee a blank pane: the relay reports the client already has the screen, to a client holding a brand-new empty terminal, and nothing paints until new output happens to arrive. Resizing appeared to fix it only because a TUI redraws itself. So the client says which case it is. reattachSshPtySession is by definition painting into a new terminal, so it asks; nobody else does, and the early return keeps working for them. Optional on the wire, so an older relay ignores it and behaves exactly as it does today. Falling through rather than returning the replay inline is deliberate: the path below already drops the pending batched bytes that are also in the buffer, which is what stops the live delivery rendering them twice. Reproduced first as a test against the real dispatcher, source publication and PTY handler (the second attach for one client, which is what a reconnect is) and it fails on the exact symptom before the fix. A second test pins that a caller which does NOT ask still gets nothing, so this cannot become a double-render for the duplicate-attach case the early return exists for. Also updates four provider tests that assert the exact attach params. NOT yet verified in the running app; the log will show replay=true on reconnect. * chore(ssh): drop the temporary reconnect-replay diagnostic Served its purpose: it is what turned 'the panes look blank' into replay=false, replayLen=0 on every pane, and then into replay=true with real byte counts once the relay fix landed. The permanent log line keeps the boolean, which is the part worth having. * revert: drop the reconnect repaint commits; they cannot fix the blank panes Reverts 2fdab478c0, 34fc1424f0 and dc6f6bf685, which I cherry-picked onto this branch to test alongside the host key work. Their stated premise is 'reattach restores each pane's buffer but not its painted frame'. That is false for this flow: a reconnect bumps tab.generation, which is the pane's React key, so TerminalPane remounts and the old xterm is disposed WITH its buffer, and nothing on that path captures it first. Refitting and refreshing a terminal whose buffer is empty paints an empty pane. The blank screen was the relay declining to re-send the scrollback, fixed separately and verified on screen. Their tests pass without exercising the real case: the fixture blanks the painted rows and deliberately LEAVES THE BUFFER INTACT, which is the one situation that never occurs here, and the hidden-tab test replaces the pane manager with a stub that reports no panes. They may still address a separate symptom — a diverged grid after a resize on a hidden tab — but that is unproven, unrelated to this branch, and the originals are untouched on nwparker/sta-3077-fix-v3 where they came from. Carrying unproven renderer changes with a false premise in their message on a security-focused branch is not worth it. Reverting first and re-running the full two-step reconnect test is the point: the earlier verification passed with these present, so it did not establish that the relay fix stands alone. * fix(ssh): repaint a reconnected pane from the grid, not a byte tail A reconnect restored plain shells correctly but was reported to bring full-screen apps back as fragments of a frame — Claude Code showed a few rules and its cost line until a resize forced it to repaint. The two payloads are not interchangeable. Relay replay is a byte TAIL: it can begin mid-escape, and it misses the alt-screen enter, the clears and the absolute cursor positioning that built the frame, so replaying it into a fresh terminal paints whatever fragments survive. The model snapshot is a serialized GRID — which is what tmux repaints on attach, and the only payload that reliably restores a TUI. Orca already had the grid path and already preferred it; it was gated to PARKING. A reconnect needs it for the same underlying reason a park does: the pane paints into a terminal holding nothing, because a reconnect bumps tab.generation, which is the pane's React key, so TerminalPane remounts and the old xterm is disposed with its buffer. So the gate now admits both, and prepaintParkedSshSnapshot is prepaintSshModelSnapshot since parking is no longer the only caller. Deliberately NOT inheriting the parking kill switch: main keeps its headless model regardless of terminalSshViewParking, so a user who turns view parking off would otherwise be stranded on the tail. Every safety gate below eligibility is untouched, and pinned that way: null, renderer-sourced, sourceless, empty, and escape-tail-only snapshots all still degrade to relay replay, so widening WHY the model is trusted cannot widen WHAT is trusted and cannot regress to a blank pane. Reverting either half of the gate fails three of the new tests. HONESTY ABOUT WHAT THIS IS VERIFIED TO DO. I could not reproduce the corruption it targets. Two attempts against a live host, both on a build WITHOUT this change, both restored correctly: a freshly started Claude Code and Codex side by side, and an alt-screen `less` scrolled 4000 lines so its original full paint had aged out of the relay's 100KB tail. The reporter's case also involved pulling wifi — an abrupt drop rather than a clean disconnect — which is the one variable I cannot simulate here. So this is verified to be correct-by-construction and non-regressing: with it applied, the same scenarios still restore correctly (top live, less at its scrolled offset in alt-screen, both agent TUIs coherent). It is NOT verified to fix the reported symptom, because the symptom did not reproduce. Treat the symptom as open until someone confirms it on an abrupt drop. Also: top was a poor proxy for a TUI in my earlier verification precisely because it repaints every second and therefore self-heals within a tick. * fix(ssh): stop the reconnect prepaint firing after its mount is spent Regression I introduced with the snapshot-first reconnect paint. The payload path consumes mountFollowsTerminalPark — it clears the flag after the first reattach so a later in-place reconnect on the SAME mount cannot repaint. I replaced the prepaint's read of that mutable flag with a const snapshot of it, so my combined flag stayed true for the life of the mount. A snapshot could then be written on a later reattach, into a terminal that already had live content, and its own isCurrent() guard could no longer go false either. The visible symptom was a tab that came up blank with no prompt and stayed generically titled Terminal N — the title only stays generic when the shell never printed a prompt for Orca to read one from. Every such tab in my session had been through a remount; four tabs created cleanly with Cmd+T were all fine. So the flag is mutable again and is consumed alongside the one it was derived from. Both reasons a mount paints into an empty terminal — a park and a reconnect — are spent by the first reattach, which is what the original code meant. Worth stating plainly: my earlier claim that the snapshot change was non-regressing was tested only against reconnect scenarios. I never exercised creating a tab afterwards, which is exactly where this showed up. * test(ssh): cover what a pane SHOWS after a reconnect, and after a new tab The gap that let both regressions reach a user. Nothing asserted the rendered pane: the existing SSH coverage checks pty ids, statuses and spy calls, and every one of those was correct while the screen was blank. Covers one flow end to end against the dockerized relay: write a marker, reconnect, require the marker to still be on screen, then open a tab and require the new shell to answer. Three choices worth keeping: A MARKER, NOT A PROMPT. A prompt reappears on its own after a reconnect, so asserting one cannot tell restored scrollback from a fresh shell. The marker only exists if the pane kept what it had. ECHO, NOT EXISTENCE. The new tab must run a command and show its output. A pty id proves a session was created; it does not prove the pane is usable, which is the exact distinction the reported bug lived in. AND THE TAB TITLE. It stays 'Terminal N' only when the shell never printed a prompt for Orca to read one from, which is what the report showed and the cheapest signal available. Gated on ORCA_E2E_SSH_DOCKER=1 like the other relay specs. * chore(ssh): rename the snapshot prefetch off its park-only name The probe serves reconnect remounts as well now, so parkedSshSnapshotPrefetch described only half of what it holds. * revert: drop the snapshot-first reconnect paint; unproven and it regressed Reverts e6541fe9b8, its follow-up c497a26788, and the rename f680a0b1cb. The reasoning behind it still looks right — a byte tail cannot rebuild an alt-screen application, a grid snapshot can, and that is what tmux repaints on attach. What I could never do is show it fixing the reported symptom. Two attempts to reproduce the corruption on a build WITHOUT it both restored correctly: freshly started Claude Code and Codex, and an alt-screen `less` scrolled 4000 lines so its full paint had aged out of the relay's 100KB tail. Meanwhile it cost two real regressions. It fired on mounts that were not reconnects, leaving a new tab with no prompt and a placeholder title, which a user hit within minutes. The fix for that consumed the eligibility flag with the one it was derived from — and after it, a reconnected Claude Code came back as fragments of a frame, the exact symptom the change was meant to remove. So the consume-once semantics that stop stale paints and the repaint a reconnect needs are in direct tension, and I do not yet understand the ordering well enough to satisfy both. Shipping an unproven change that has already broken two things twice is worse than shipping the blank-pane fix alone, which IS reproduced, A/B'd and visually verified. The TUI corruption goes back to open — but now with something it never had before: a reproduction. It shows up on a reconnect against a Claude Code that has been running a while, not one just started, which is why my earlier checks kept passing. The e2e coverage stays. It asserts what the relay fix guarantees — a marker surviving a reconnect, and a tab opened afterwards reaching a shell that answers — and neither of those depends on this change. * docs(ssh): name the root cause the reconnect replay fix does not address requireReplay fixes the blank pane at the symptom. The cause is that a PTY source delivery is the only per-client relay state that outlives its client detaching: fs-handler, git-handler and relay-filesystem-watch-registry all subscribe to dispatcher.onClientDetached and release theirs, and relay-pty-source-publication never does. The primary client keeps its id across a transport replacement, so its delivery survives a dead transport and activate() answers 'existing' to a client that cannot receive anything. Retiring the delivery on detach is the real fix. Not doing it here is a choice, not an oversight — it is the flow-control and credit path, and I could not verify it before handing this over. Recorded in the test that guards the symptom, which is where someone changing this will actually look. * docs(ssh): record the three root-cause routes that do not work I went after the cause and failed three times. Each attempt looks correct until it runs, so the dead ends are worth more written down than the time they cost: RETIRING THE DELIVERY ON onClientDetached — the obvious fix, and the one I argued for, since fs-handler, git-handler and the watch registry all release their per-client state exactly there. It breaks checkpoint recovery: 10 tests across relay-pty-source-recovery-interleavings and restore-retry. A delivery outliving its client is DELIBERATE; that is what lets a reconnecting client resume from a checkpoint instead of re-receiving everything. This class omits the subscription on purpose, and that omission is not the bug. RETIRING WITHOUT session.cancelDelivery() — the credit ledger keeps one upstream owner per pty, so dropping the record without releasing it leaves the slot taken and the next open throws 'PTY source delivery already has an upstream owner'. I saw that live as an error toast over a blank pane. COMPARING clientGeneration — the delivery identity carries one, but it is client-supplied through pty.openClient and RequestContext has none to compare against, so the relay cannot tell the generations apart on its own. Which points where I would start next, unverified: the SSH client presents the SAME clientGeneration across a reconnect, so the relay cannot distinguish the new connection and reuses its delivery. reattachSshPtySession never sends sourceRecovery at all — the recovery protocol exists and the SSH reattach path simply does not participate in it. That is likely the real fix, and it is on the client, not in the relay. The symptom fix stays because it is verified and the tree is green; the cause stays open with a map instead of a guess. * fix(ssh): repaint a reconnected full-screen app from the grid A reconnected TUI came back as fragments of a frame — Claude Code showed a few rules and its cost line until a resize made it repaint itself. Relay replay is a byte TAIL. It can begin mid-escape and it misses the alt-screen enter, the clears and the absolute positioning that built the frame, so replaying it into the fresh xterm a remount just created paints whatever fragments survive. Main already keeps the thing that does restore a frame: a real @xterm/headless grid, alt-screen aware, fed unconditionally for SSH. Local terminals already repaint from it; SSH was the only path that did not. So this routes an SSH reconnect into the painter that already exists, at the one expression that chooses model over tail. No new call site, no second lifecycle, and every existing gate still applies — a null, renderer-sourced or empty snapshot still degrades to the tail, so it cannot paint blank. ONLY ON THE ALTERNATE SCREEN, and that is the whole design. The reconnect replay reaches the renderer without passing through main's model — forwardReattachReplay and the inline attach replay both bypass onPtyData — so at that moment the model is stale by exactly the outage. For a full-screen app that trade is right: a tail cannot rebuild a frame it no longer contains, a grid can, and the SIGWINCH the restore already sends makes the app redraw the delta. For a scrolling shell it would be wrong: the tail holds output the model never saw, and preferring the grid would drop it for good. A park has no such hole, so it keeps using the model either way. Derived from the PENDING retry, not directSshRetryAttempt. That also matches the live binding, which is written at the same tab generation once a reconnect succeeds and then outlives it — so it stays truthy for every later remount of that generation. Reading it directly is what made my first attempt fire on mounts that were not reconnects. Consumed alongside mountFollowsTerminalPark for the same reason. Verified live against the reported app: Claude Code restores identical to its pre-disconnect frame, top restores coherent and live, and a plain shell still shows output written before the disconnect. 5,470 tests pass across the touched suites. Not the whole story, and the remaining half is already written down: the model's gap exists because the SSH reattach asks for a tail instead of participating in the checkpointed resume the relay already implements. Close that and this paint is not merely coherent but exactly correct, for shells too. * test(ssh): cover a full-screen frame across a reconnect, not just scrollback The case a byte tail cannot serve, and the one that reached a user twice. A tail can begin mid-escape and misses the alt-screen enter and absolute positioning that built the frame, so replaying it paints fragments — which is what a reconnected Claude Code showed. Uses top: present on any Linux image, and it repaints on a fixed interval, so a whole header after the reconnect is unambiguous rather than a timing artifact. Asserts the header AND the column row, because a tail that lost the frame start still shows rows. The spec now covers all three payloads one reconnect has to get right: a shell's scrollback, a full-screen app's frame, and a tab opened afterwards reaching a shell that answers. * ci(e2e): actually run the Docker-SSH specs in the changed-specs lane "I am surprised this was not caught" has a mechanical answer: these tests do not run. A spec that reads ORCA_E2E_SSH_DOCKER test.skip()s itself when it is unset, and exactly one place in CI set it — gated on tests/e2e/ephemeral-vm-provisioned- root.spec.ts being among the changed files. So editing any SSH spec ran it as a skip and reported green. Eighteen specs reference that variable, including both reconnect regressions I have been chasing. Now it is also enabled when any changed spec references the variable, which is the same grep -l idiom the @headful check two lines below already uses. The original clause stays: that spec needs Docker without naming the variable, so replacing it rather than adding to it would have traded one silent skip for another. Simulated against the real files — the reconnect spec, the original trigger, a multi-spec change, a non-Docker SSH spec, and a deleted path — enabling in the first three, staying off in the last two, and not failing the step on a path that no longer exists. * fix(ssh): let the replay veto a stale alternate-screen belief Adversarial review of the previous commit found a case where it is worse than the bug it fixes, and it is the exact inverse of what that commit reasoned about. The model reports alternateScreen from bytes it consumed, and it never consumes the outage. So if a full-screen app EXITS during the disconnect — an agent finishes, a command ends, the process dies — the model still says alternate. The gate then painted a frozen frame of an application that no longer exists and, via the else-if chain, discarded the replay carrying the shell's real output. Frozen and wrong beats fragments, which were at least current bytes. The replay is the only witness to the outage, so it now gets a veto: its last 47/1047/1049 transition, if any, outranks the model's belief. Leaving reset means the frame is gone and the tail wins; re-entering means the model is right after all. Same review found the width-mismatch guard drops the alt frame and leaves a cleared screen for the app to repaint — free for a park with no tail to lose, but here it meant discarding a usable one for a blank pane, so that degrades too. Both vetoes are skipped when there is no replay, where they would only trade a stale frame for an empty one. Extracted as sshReconnectPaintsFromModel rather than more inline ternary, because every interesting case is a disagreement between a stale belief and a replay — awkward to stage end-to-end, trivial to state as a table. 14 unit tests, including the two that fail against the previous commit. The e2e comment is corrected in the same spirit: top redraws itself, so it never discriminated the paint source and should not have claimed to. Also from the review: the kitty flag stack was left stale on this path, since the app's pushes during the outage exist only in the replay we discard — scanned now, after the snapshot so the outage layers on the pre-outage baseline. And the consume-once comment asserted an invariant that does not exist; followsDirectSshReconnect is a const captured per connect, bounded by connectStarted and the gates rather than by the read. Corrected rather than restructured. Known and NOT fixed, because it predates this work and is a behavior change of its own: the model probe is gated on the terminalSshViewParking kill switch, so turning off view parking also silently disables this repaint. Defaults on. * docs(ssh): make the parking kill switch's reach over the reconnect repaint deliberate Review flagged that terminalSshViewParking silently disables the full-screen reconnect repaint, since both go through the same model probe, and that nothing said so. Keeping the coupling and documenting it rather than threading a reason through. The switch is the kill for painting an SSH pane from main's model at all, and a reconnect does exactly that; off should restore the relay-tail behavior that predates the machinery, which is what an escape hatch is for. That matters more than usual here: this repaint is new and review already found one case where it was worse than the bug, so a way to turn it off in the field is worth its cost — a user who disables parking also loses the reconnect repaint. The alternative is worse than it looks anyway: the probe memo is keyed on ptyId and shared with the park path, so a per-call reason would be reused by whichever path created it first. * docs(ssh): record why the obvious reconnect follow-up does not work I proposed making the pane-retry path request source recovery the way reattachKnownPtys does, and argued it was probably client-side routing. Tracing it says the wiring is indeed trivial and the checkpoint state does survive a drop — and that the change would still be wrong three ways, one of them harmful. The relay short-circuits to 'existing' on a same-clientId attach BEFORE it looks at the recovery argument, and the reconnecting client has already rotated the delivery onto its id. A failed reattachKnownPtys then deletes the checkpoint on purpose, so a later pane retry presents checkpointUnavailable, which becomes restoreRequired and then SSH_SESSION_EXPIRED_ERROR — trading a blank pane with a tail for a killed session. And the payloads answer different questions anyway: recovery replays the post-checkpoint delta to keep main's model whole, while the tail is a screen snapshot for a fresh empty xterm. Even a successful recovery would put almost nothing in a remounted pane. Also corrects the argument I had been leaning on hardest. "Old relays ignore requireReplay, so those users still get blank panes" is false for the SSH relay: the client deploys its own relay into a version-scoped directory and rejects any grant whose serverBuildId differs, because client and relay ship in one build. Mixed versions cannot occur on this channel. The independent-update rule still governs remote runtime hosts, just not this one — so there is no stranded population, and the urgency that framing created was imaginary. What replaces it is a sharper question. Source recovery is gated on outputFlowControl and on the client presenting a NEW clientId. We have empirical evidence it does not: the blank-pane bug existed because the relay concluded this client already held the stream, and the shipped fix works by bypassing that exact early return. If the id is reused, reattachKnownPtys' recovery hits the same short-circuit — meaning checkpointed recovery may never have run for SSH reconnects, and the tail is not a fallback but the only path. Whether that is so turns on daemon versus stdio-primary relay mode, which I did not verify and which decides whether the work is "extend recovery" or "recovery has never run here." * docs(ssh): the root cause — checkpointed recovery never runs on a reconnect Chasing why the pane-retry path could not request source recovery turned up the real answer: nothing can. Recovery is dead on every SSH reconnect, and the byte tail is not a fallback but the only path that has ever run. Five links, each read rather than inferred. setWrite reuses primaryClient including its id, so a reconnected client presents the SAME clientId. activate() tests exactly that at line 99 and returns 'existing' at 108, which makes the rotateDelivery branch at 118-142 reachable only when the ids differ — never here. So no sourceRecovery comes back, so finishSourceRecovery fails its !pendingRecovery guard and abandons, cancelling the delivery and deleting the checkpoint. The pane retry then opens fresh and takes the tail. This also explains the blank panes exactly. The relay concluded that this client already held the stream because, by its own identity rule, it does. The fix that implies is smaller than anything proposed so far and avoids what sank the three earlier attempts: bump a transport generation on the client record in setWrite and compare it alongside clientId, so a reconnect rotates the delivery instead of matching as 'existing'. Deliveries still outlive their clients and nothing retires on onClientDetached — the rotation happens on re-attach, which is what the recovery design already intends. RequestContext, setWrite and the publication are all relay-internal, and client and relay ship in one build, so there is no wire change and no compatibility exposure. Left explicitly unverified: whether rotateDelivery's identity preconditions hold at that moment, whether outputFlowControl is granted on the reconnected session, and what a rotation gives the RENDERER — which still remounts an empty xterm and needs a screen, not a post-checkpoint delta. Recovery keeps main's model whole; it does not by itself repaint a fresh terminal, so the tail may still be wanted for the pane even once the model stops going stale. * ci(e2e): run the Docker-SSH specs when SSH SOURCE changes, not just specs The earlier fix only helped when a spec file itself changed. Edit pty-connection, pty-handler or ssh-relay-session and touch no test — which is what every one of these regressions actually looked like — and the lane still did not run. pr.yml now maps SSH source paths onto five Docker-backed specs. Five rather than all fifteen because the rest are covered by unit tests that prove the same source without paying for a container; that is a deliberate narrowing and this comment is where it is admitted rather than left implicit. Test files are excluded from triggering, since they prove themselves. Simulated against the real paths this PR touches: pty-connection.ts, pty-handler.ts, ssh-relay-session.ts and ssh-pty-session-reattach.ts all now pull the SSH specs in, while pty-connection.test.ts, ssh-known-hosts.test.ts, SshTargetCard.tsx and README.md correctly do not. The gate contract test covers the mapping: 11 pass. e2e.yml pays for it — 30 to 45 minutes, because the lane can now build a container image and run SSH specs serially on top of whatever changed — and installs openssh-client, which the fixture shells out to and which the lane did not need back when it never received these specs. * test(ssh): make the reconnect spec actually run — it now fails on a real bug It had never executed once. The CI condition that enables Docker-SSH was gated on an unrelated spec, so this skipped and reported green — and running it for the first time found two bugs in the spec itself, both of which a typechecked tests/ would have caught instantly. startDockerSshRelayTarget returns a DockerSshRelayTarget, which has no targetId; the id comes from connectDockerSshRelayTarget's return value, which the spec discarded. So every reconnect call passed undefined and the relay answered 'SSH target "undefined" not found'. And openNewTerminalTabInActiveWorkspace takes the group to open into; called with no argument the new tab lands nowhere. The third problem was the fixture rather than the spec. The image ships Debian's /etc/bash.bashrc with the xterm title block commented out and an all-comments /root/.bashrc, so its shell never emits OSC 0 — which is what Orca derives a tab title from. The title assertion could not have passed for any shell, healthy or not, so it was proving nothing. enableDockerSshRelayTargetShellTitle opts a spec into the title-setting PS1 a real user's shell already has. IT STILL FAILS, and that is the point: it fails on a PRODUCT bug it was written to catch. An SSH reconnect destroys the terminal state behind a tab whose local creation has not yet reached the host. remote-workspace-session-merge.ts:86-89 spreads the host's tab list over the local one for that worktree, so a local tab missing from the host snapshot has no surviving branch; the upload that would have put it there is DROPPED rather than deferred inside the 1s suppression window after a snapshot apply. The tab bar still renders the tab, correctly titled, but the terminal slice holds one tab and no pane manager exists for the second — so the user clicks a tab that never paints, with no error and no recovery, while the process keeps running on the host. Pre-existing: none of remote-workspace-target-sync.ts, remote-workspace-session-merge.ts, use-app-session-persistence.ts or remote-workspace-snapshot-apply.ts is touched by this branch, and nothing in the merge range touches them either. Not worked around here. Waiting for the upload would hide it, and a user opening a tab right after a reconnect has no such signal to wait on. An earlier version of this message claimed the spec passes. It does not; I had seen five green runs out of six and generalised from them. Sustained runs are about three in eleven before the merge and zero in four after. * chore(e2e): add a typecheck entry point for tests/, unenforced for now tests/ has never been typechecked. That is how a spec could read target.targetId off a type with no such field, and call a function without its required argument, while the suite reported green — the spec was skipping, so nothing ever disagreed with it. Pointing tsc at tests/ finds both immediately. It also finds ~198 errors across ~94 files, which is a cleanup project rather than a change to make here, so this ships as pnpm typecheck:e2e and is deliberately NOT added to the typecheck chain or to CI. An unenforced script is worth less than a gate, but it is worth more than nothing: it is runnable, it is discoverable, and the header says plainly what it is so nobody mistakes it for coverage we have. runtime-types.ts is the one fix included, because it was actively misleading: every PaneManagerLike method was optional, so every call site was a possibly-undefined invocation that TypeScript could not help with. They are real methods on a real instance. Also widens AppStore to the StoreApi that window.__store actually is. * test(ssh): separate the reconnect paint guard from the tab-destruction bug The paint guard was failing about two runs in three, and after the merge every run, for a reason that has nothing to do with painting. It staged its full-screen check in a tab it had opened AFTER a reconnect — which is exactly the tab an unrelated session-sync bug destroys on the NEXT reconnect. Two independent failures were riding on one assertion, and the one that fired was not the one the spec is for. Running top in the ORIGINAL tab fixes it. That tab predates every reconnect, so it is in the host snapshot and survives. No assertion changed, none were weakened, and the new-tab case simply moves after the full-screen case rather than before it — it still opens its tab after a reconnect, which is the regression it exists to cover. Five consecutive runs pass at ~13s, against three in eleven before. The bug itself is not swept up. ssh-reconnect-tab-destruction.spec.ts records it as a fixme with the mechanism written down: session-merge spreads the host tab list over the local one, so a local tab missing from the host snapshot has no surviving branch, and the upload that would have put it there is dropped rather than deferred inside the 1s window after a snapshot apply. It is worse than a vanishing tab — the tab bar keeps rendering it, correctly titled, while the terminal slice has dropped it and no pane manager exists, so the user clicks a selected tab that never paints, with no error and no recovery, while the process runs on untouched. fixme rather than a workaround because waiting for the upload would hide it, and a user opening a tab right after a reconnect has no such signal to wait on. It is pre-existing: none of the four files in that path is touched by this branch, and nothing in the merge range touches them either. Also lifts openTerminalTab into a shared helper, since both specs need it and the group argument it must pass is the kind of thing worth stating once. * fix(ssh): stop a reconnect deleting local state the host has not seen Reported from a 60-second manual test: reconnect an SSH workspace and the app drops to the home screen, a second tab running pnpm install is gone entirely, and one launched agent is listed twice. Three symptoms, one cause. The snapshot is applied as the whole truth for the reconnecting target. The tab merge iterates only the host's worktrees, then the result is spread over a gap where every local tab for that worktree has just been dropped — so a tab created locally whose upload has not landed has no branch that keeps it. Not a race: it cannot survive. Same for the pointers, where a snapshot that names no active worktree nulls activeWorktreeId and activeWorkspaceKey, which is the home screen while the user's terminals are still running. So the host is now authoritative for what it knows and not for what it has never been told. A local tab absent from the snapshot is kept, the worktree union is used so a snapshot with no entry for it at all cannot erase it, and a null active worktree only defers to local state when that workspace demonstrably still exists in the merged result. Two guards this change had to earn rather than assume. A null activeTabId is NOT missing information — it is a deliberate deselect that arms the duplicate-tab repair, and my first attempt defeated it and broke that test; it is honoured verbatim now. And preserving by tab id alone reintroduces the duplicate agent, because the host can carry the same session under a new tab id, so the preserve also checks the remote session id — the identity that survives a tab-id change. Testing, which is the part that failed here before. Eight tests fail on the unfixed code and pass on this one, at two levels: the merge decision table, and the real apply path driven through a store. The end-to-end version of the same scenario is deliberately NOT the guard and now says so in its header — measured against unfixed code it only reproduces about one run in three, because the destruction needs the tab created inside the debounced upload's suppression window and nothing external can force that. Its earlier green run is exactly why this shipped. * fix(ssh): let agent session history recover once the relay is ready Reported against the adhoc build: a workspace whose editor was loading remote files perfectly still showed "SSH relay is not ready" and "0 shown · 0 recent" in the Agent Session History panel, permanently. That string is what the relay throws before it is ready, which is ordinary at startup and again for the window a reconnect leaves the session not-ready. The panel had three refresh triggers — mount, window refocus, and a newly seen agent session id — and none of them fire when the relay simply becomes ready. So a transient startup error became a stuck panel next to a workspace that plainly worked, which is why the report described it as broken while everything else was fine. The file explorer already recovers from exactly this, off exactly this signal, with the rationale written down at use-file-explorer-tree-load-effects.ts: it loads before SSH providers are registered, so it retries when sshConnectedGeneration bumps. This panel simply never did. Same idiom, same gate — only retries when there was a prior error, so a local workspace or one that already listed fine does not rescan every time some unrelated host connects. Two tests in the existing suite. The retry one fails on the unfixed code with "the panel never retried after SSH became ready"; the second pins the gate, since a retry that fires on every connection bump would turn one bug into a rescan storm. * fix(worktrees): name the create route when a raw filesystem error escapes A worktree create over SSH failed with a bare "ENOENT: no such file or directory, lstat '/home/neil/projects/orca-test1234'". That message names nothing. An lstat is Node's LOCAL filesystem, so hitting one against a path that lives on an SSH host means creation ran a local implementation for a remote repo — but the user cannot know that, and neither could I without re-deriving the routing by hand and then failing to reproduce it. worktrees:create picks between three implementations, and the order matters: isFolderRepo is consulted BEFORE connectionId, so a folder-kind repo on an SSH host never reaches the remote path at all. Which route ran, and what the repo looked like when it was chosen, is the entire diagnosis — and it is knowable exactly at the throw site, where the decision was just made. So it is stated there now: route, repo kind, connection id, path, and the original message. Deliberately additive and deliberately narrow. Only ENOENT/EACCES/EPERM are rewritten; a git failure, a relay-not-ready, or a validation error already says what went wrong and burying it under a worse message would be a regression. The original error is kept as `cause`, so anything matching on `code` or reading the stack is unaffected. This does NOT fix the reported failure — I could not reproduce it. On current code I created a worktree at that exact path, at a second path, with a leftover directory already present remotely (correctly suffixed -2), and with the SSH target disconnected (clean actionable error, no ENOENT). What it does is make the next occurrence identify itself in one screenshot instead of costing another investigation. * fix(ssh): recognise a missing path reported by the relay Creating a worktree over SSH failed with a raw "ENOENT: no such file or directory, lstat '/home/neil/projects/orca-test1234'". The path was the one about to be created, so its absence was correct. The caller asks exactly that question — remotePathExists returns false on ENOENT — and could not get an answer, so it rethrew at the user instead. The trace log settles where the error comes from, and it is not where I spent a long time looking. The stack starts at SshChannelMultiplexer.handleResponse: the lstat ran on the SSH HOST, and the failure travelled back as JSON-RPC. An lstat in an ENOENT message is normally Node's local filesystem, which sent me hunting for a local fs call on a remote path; there is none. handleResponse rebuilds the error as `new Error(msg.error.message)` and then sets `code` from `msg.error.code` — the TRANSPORT's numeric JSON-RPC code. Node's 'ENOENT' string code does not survive that, and isENOENT tested only for the string, so a remote missing path could never be recognised as missing. Every caller of that predicate asks the same question, so this was wrong for all of them, not just worktree create. The message is now consulted as well, matched on Node's full canonical phrase so a branch name or log line that merely contains the word cannot make an existing path look absent — that would silently skip a collision check rather than report one. Fixed on the client because it holds for every relay version, including ones already deployed; teaching the relay to send the original code would only help hosts redeployed afterwards. The two other copies of this predicate, in filesystem-rename-collision and git-discard-path-safety, are deliberately left alone: both run against a local filesystem — one inside the relay, one on the desktop — where the string code is intact and broadening would only add false positives. Seven tests, three of which fail on the unfixed code: the relay-rebuilt error, the same error through the IPC wrapper the renderer sees, and one carrying no code at all. * revert: drop the worktree-create error-context wrapper Written to make an unexplained ENOENT self-identifying when creating a worktree over SSH. The cause is now known and fixed — the error came back from the RELAY and isENOENT could not recognise it, because the multiplexer rebuilds a remote error with the transport's numeric code — so the wrapper is scaffolding for a solved problem. Worse, its central claim is false. It reported 'the remote (SSH) path failed on a local filesystem call', and the trace log shows the lstat ran on the SSH host, not locally. Keeping a message that asserts the wrong thing about the one failure it was built for is worse than not having it. 183 lines and a rewritten error at the IPC boundary, removed. * docs(ssh): drop a comment claim about older relays that is not true The requireReplay comment said the field is optional on the wire so an older relay ignores it. It cannot happen: the client deploys its own relay into a version-scoped directory and validateGrant rejects any grant whose serverBuildId differs, so client and relay are the same build by construction. The field IS optional, which is why the relay reads it as !== true — that part stands on its own and needs no story about versions. A comment asserting a compatibility property the code does not have is worse than no comment, because the next person plans around it. * fix(ssh): act on the host key review — three must-fixes and two hazards M1. A stale record of ours outranked known_hosts, so the remedy we print did not work. `ssh-keygen -R host` then reconnect leaves known_hosts holding the NEW key while our store still holds the old one, and the store was consulted first — the one state that cure produces was the one state we refused. Permanently, since nothing in the app clears the store. known_hosts now decides a match first, which concedes nothing: it is the artefact ssh itself obeys, so an attacker who can rewrite it has already won. Both directions of the precedence are pinned now; the rotation case fails without this change. That leaves one rejection known_hosts cannot cure — a host trusted only on first contact that later rotates its key. "Remove the saved key" named nothing a user could find, so it now names the store file. M2. A superseded attempt could put a passphrase prompt in front of a host we had just refused. The verifier deliberately does not record a rejection for an attempt nobody is waiting on, so nothing identified it and ssh2's generic handshake error walked the credential ladder. Guarded on the generation, which catches it whatever the error turned out to be. Deliberately NOT by rejecting with a cancellation: an existing test pins that connect() still reports the raw late-startup error, and that behaviour did not need to change to fix this. M3. Every unknown host was refused whenever HOME diverges from the passwd home — devcontainers, `su`, Nix shells, some corporate launchers — because `-F` makes ssh ignore /etc/ssh/ssh_config and being blind to a site policy was treated as reason to refuse. Being blind is only a reason to refuse if we cannot go and look, so it now asks ssh for the system config on its own and takes the stricter of the two. Only a probe that fails leaves the strict rule standing. Costs one `ssh -G` on the rare path that already needed -F. N1. A rejected key's fingerprint was still adopted, and the relay scopes install locks by it — locks keyed to a host we refused to talk to. N2. The fallback algorithm list re-introduced the throw its own comment describes. ssh2 prepends ssh-ed25519 only when a runtime probe succeeds, so on a build where that probe fails, proposing it makes generateAlgorithmList throw inside client.connect — and only for hosts we already know. Not reading ssh2's list is a reason to leave its defaults alone, not to guess: it returns null now and the caller skips reordering. 1555 tests pass in src/main/ssh. * docs(ssh): state the merge's real trade instead of claiming it has none The preserve comment said a genuinely closed tab is never in the local list, because closing removes it. True for a close on THIS client; false for one closed on another client sharing the host, where the tab is still local, still absent from the snapshot, and now kept. That is a deliberate trade, not an oversight — absence cannot distinguish 'never uploaded' from 'closed elsewhere', and the outcomes are not symmetric: keeping a tab a moment too long is recoverable by closing it, deleting a live one with a process in it is not. But the comment asserted the case could not arise, which is the kind of claim that gets planned around. Now stated, and pinned by a test so the next person can see it was chosen rather than missed. * fix(ssh): stop a newer host key store being silently downgraded The store writes a version and never read it back. A file from a future Orca would have had every record dropped by validateRecord — the shape would not match — and then been REWRITTEN as version 1, so a rollback silently discarded whatever that version knew. Trust records are user-owned state; losing them costs a first-contact prompt per host and, worse, re-establishes trust from nothing. v1 is the only place this can be made safe, because v2 cannot retrofit a v1 that already clobbers it. A newer file is now left alone: nothing is trusted from it, and trustHostKey declines to write rather than downgrade. The check sits inside the snapshot queue so it cannot be separated from the write by another writer, and declining is not an error the caller fails on — the key still verified, and the next connect re-derives the same decision from known_hosts. The test writes a version-99 file and asserts it is byte-identical afterwards; it fails on the unfixed code with the file rewritten as version 1. * perf(ssh): skip the reconnect snapshot probe the replay has already ruled out Every SSH reconnect paid up to the 750ms model-snapshot timeout, including the ones where the answer was discarded. The gate needs the snapshot's alternate-screen flag, so the probe looked unavoidable — but one of its two vetoes does not: if the replay shows the app LEFT the alternate screen, no snapshot can be used whatever it says. Asking that first costs a regex over the replay and removes the probe entirely for that case. It also shrinks the window that matters most: the await sits inside the structural replay coordinator with live PTY bytes deferred, and the payload can be superseded while it runs. Behaviour is unchanged — sshReconnectPaintsFromModel returns false for a null snapshot exactly as it did for a fetched one it then vetoed, and its tests still pin both vetoes. * test(ssh): cover the site host key policy probe It shipped untested. Three cases, and the third is the one that matters: a system config naming no policy answers 'ask', not null, because parseSshGOutput fills the OpenSSH default — and that distinction is exactly what the caller keys on. Null means 'we could not look', which is the only state that keeps refusing unknown hosts; a successful read that sets nothing clears the blindness without relaxing anything, since strictestHostKeyChecking leaves the user's value alone against 'ask'. I expected null there and was wrong about my own code; the test now records the behaviour rather than my assumption. Also pins that the probe passes the null device and terminates its args with -- so a host starting with '-' stays a host. * fix(ssh): three release blockers from the readiness review P1-1 was my own fix from the previous round, and it was wrong. I claimed `ssh -G -F /dev/null` reads the system config while excluding the user's. It does not: -F excludes /etc/ssh/ssh_config too, which sshGArgsForHost's own comment says and I quoted before contradicting. Confirmed live against OpenSSH 10.2p1 — plain `ssh -G` reports the sendenv lines from /etc/ssh/ssh_config, `ssh -F /dev/null -G` reports none. So the probe returned built-in defaults on every machine, the fail-closed guard never engaged, and a site-wide StrictHostKeyChecking yes was silently ignored while we accepted AND durably recorded a key the user's own ssh refuses. That is worse than the lockout it was meant to fix. There is no ssh-only way to ask this, so the file is read directly — and the question asked is deliberately weaker than "what is the policy". Anything ambiguous (unreadable, an Include that will not resolve, the directive present at all) answers yes and the caller stays fail-closed. Only a site config that demonstrably says nothing about host keys clears it, which is the common case that was being punished. Includes are followed, since macOS and most distros ship `Include /etc/ssh/ssh_config.d/*` and missing that would read as "no policy" on nearly every machine that has one. strictestHostKeyChecking goes with it: there is no separately-read site value left to merge. P1-2. `ssh -G` prints UserKnownHostsFile unquoted and space-separated even when the config quoted it — verified the same way. One path containing a space is therefore indistinguishable from two, and splitting shreds C:\Users\John Doe\.ssh\known_hosts into fragments that resolve to nothing. Every fragment misses with ENOENT, which reads as "absent" rather than "unreadable", so the user appears to know no hosts and a CHANGED key is accepted as first contact. The filesystem is the only thing that can disambiguate, so it decides: if no fragment exists but the rejoined path does, it was one path. A list where any fragment exists is a genuine multi-file config and is left alone. P1-3. oxlint is a PR gate and this diff failed it on two lines. Both fixed — including by splitting the replay on ESC rather than matching it, which is equivalent since every private-mode sequence begins right after one, and respects no-control-regex instead of suppressing it. That gate failure is on me twice over: I reported LINT clean repeatedly while filtering oxlint's output with a grep that could never match its `path:line:col: error` format. Verification is by exit code now. 5183 tests pass; each fix has a test that fails without it. * fix(ssh): the readiness review's P2s P2-1. activeRepoId and activeWorktreeId could describe different workspaces. The repo followed the host while the worktree came from local state, and it split in exactly the case the preservation exists for — "the host named no worktree" is precisely when it can still name a repo. All three active-* fields now derive from whichever worktree won, rather than each picking a source. The nested ternaries that hid it are gone. P2-2. The trust-source reads sit AHEAD of client.connect, and readyTimeout only covers the handshake — nothing wrapped attemptConnect. A home directory on a stalled NFS or SMB mount made readFile hang forever, leaving the connection wedged in `connecting` with no ladder entry and no recovery. Bounded at 5s, reusing the existing withTimeout helper. The fallback is the one an unreadable file already produces — evidence withheld, connect as ssh does but record nothing — not the far worse "no hosts known" that would let a changed key through as first contact. That helper absorbs rejections into its fallback, so the store's catch had to move INSIDE the timeout; wrapping the other way silently swallowed the warning that is the only signal the store is unwired rather than merely slow. P2-4. doSsh2Connect runs up to five times per attempt as the credential ladder advances, and each run re-read every known_hosts file, re-read the store, and re-scanned the system config. Nothing writes those while a handshake is in flight, so they are read once per attempt — which matters more now that each read can cost up to 5s. Keyed by connect generation rather than cleared, so a superseded attempt can never hand its sources to the live one. P2-3. forgetHostKey was exported, tested and referenced by nothing. The store-mismatch rejection now names the store file, so the case it was meant to cure has a cure without it; an exported API nothing can reach is unverified in production. Removed until D5 ships its UI, and the doc says so. P2-5 needed no change: the site-policy branch it called dead is reachable again now that the probe reads the real config. The design doc drifted from the code in the two places this review checks, and both are corrected: revocation now propagates for the ordinary rotation because a known_hosts match is decided first, and the -F blindness is resolved by reading the file rather than by refusing. * fix(ssh): rejoin a spaced known_hosts path even beside an ordinary one The whole-list check only fired when NOTHING in the reported list existed, so a config naming both a spaced path and an ordinary one kept the spaced one in fragments — the ordinary path existing was enough to leave it alone. The file the user actually verified their hosts in then never got read, which is the same failure the rejoin exists to prevent, just harder to notice. Longest run first now: the longest sequence of tokens that resolves to a real file is taken as one path and the scan continues after it, falling back to the single token when no run resolves. A genuinely absent path is still reported as-is rather than invented. The mixed case fails against the previous version. * test(ssh): pin the site config scanner's edge cases This control decides whether an unknown host is refused when we cannot see the site policy, and my first attempt at it was a security regression, so the cases that decide 'policy present' deserve to be written down rather than assumed. Seven, and each could have gone the wrong way. A commented-out directive must NOT read as a policy or the lockout returns for every distro shipping the line commented. A directive inside a Host or Match block MUST read as one, because no attempt is made to evaluate whether the block applies — guessing wrong in the permissive direction is the failure that matters. The equals form counts; StrictHostKeyCheckingExtended does not. A nested Include is followed, since a policy one level down is still a policy. An Include cycle terminates and answers false, which is knowledge rather than doubt: both files were read in full and neither mentions it. All seven passed as written, so this pins behaviour rather than fixing it. * test(ssh): assert tab survival, record the reattach gap rather than flake on it Running the two SSH e2e specs — which neither review executed — showed the tab-destruction spec failing on liveness three times out of three. The screenshot disproved the obvious reading: the marker was on screen, echoed by a live shell. getTerminalContent resolves the store's active tab id and returns '' when paneManagers has no entry under it, which is indistinguishable from 'the shell said nothing', and across a reconnect those two disagree. Scanning every mounted pane instead fixed the read, and then measured the real thing: three runs in four. The tab survives every time; the reattach behind it does not. So the merge fix is real and incomplete — the store keeps the tab, the tab bar renders it, and the pane sometimes never rebinds, which is the frozen-tab shape the original report described, one layer down from the deletion that used to cause it. Asserting that would put a one-in-four flake into the lane built to catch this class, and a lane nobody trusts is how the original silent-skip failure happened. So the spec asserts survival, which is deterministic at five runs in five, and the liveness gap is written down in docs/reference/ssh-reconnect-source-recovery.md with the first place to look. * fix(ssh): stop an unreadable host key store from wiping every pinned key Second readiness pass, checking each of the first pass's ten fixes rather than taking them on trust. Nine held. This is the one that did not, plus three fail-open shapes in the site-config scanner that a live OpenSSH disproved. P1 — the store. loadTrustedHostKeys returns [] for ANY read failure, and trustHostKey then wrote [...that empty list, newRecord]: one transient EMFILE followed by one first-contact accept replaced the file with a single record. Every other host re-TOFUs, and one whose key genuinely changed in between is accepted as first contact rather than refused — the exact outcome pinning exists to prevent. It also contradicted the doctrine this PR applies to known_hosts two files away, where a file that exists and refuses to open is evidence withheld. Fixed by classifying one read instead of guessing twice: readStore returns ok/absent/withheld, the read path flattens withheld to 'nothing trusted' so it still fails closed, and the write path declines. That subsumes the separate newer-version probe, so trustHostKey now reads the file once inside the queue rather than twice. The 'Trusted host key' log moved inside the branch that actually writes — it was already claiming success on the newer-version path. P2 — the site-config scanner documents 'doubt wins on every path' and had three where it did not, each the same shape: a path resolved WRONG still resolves to something, and a nonexistent Include reads as 'nothing there', which is indistinguishable from 'no policy'. Verified against OpenSSH 10.2p1: relative Includes resolve against a fixed dir, not the including file's, so a directive two deep was missed; ? and [...] are globs it honours; ~ and %-tokens expand before use. All three now answer doubt. P2 — credential prompts are gated on the attempt generation in one place rather than per rung. A superseded attempt is denied without a recorded decision, so isHostKeyVerificationError reads false and the ladder ran on to prompt for a passphrase nobody was waiting on. P2 — resolveKnownHostsFiles is async. Its rejoin existsSync-scans the very paths the 5s bound protects, and sat outside it as an eagerly-evaluated argument, so a stalled NFS/SMB mount blocked the whole main process. Tests fail against the pre-fix code: 2 for the store wipe, 3 for the scanner. Also: the 4 IME failures I previously reported as pre-existing main breakage were a stale node_modules — the xterm patch from #14758 was not applied here (402,643 bytes installed vs 403,181 expected). pnpm install applies it and all 4 pass. The OSC8 and SFTP failures were the same cause. * fix(ssh): make the merge non-duplicating, and close the last scanner hole Third readiness pass. Three P2s, all fixed. The merge one is the one I most wanted a verdict on, and it is real: hostUnknown filtered against ids the HOST knows and never against ids this same merge had already emitted, so a tab id local state holds under two worktrees was re-added under both. Two panes then share one terminalLayoutsByTabId entry and one remoteSessionIdsByTabId entry — one remote PTY — plus an activeTabId that never converges, which is the self-retriggering repair loop active-tab-owner-worktree .ts exists to mitigate (React #185). This PR does not create that state. It used to DESTROY it, by deleting every local tab under a replaced worktree, and keeping live panes cost that accidental cure. So the guarantee is made explicit rather than incidental: the merge now never emits one tab id twice, whatever it is handed. The active worktree is walked first so the surviving copy is the one the user is looking at, which is the owner resolveActiveTabOwnerWorktreeId already prefers — merge and repair now agree instead of each picking differently. Scanner: an Include path that is quoted AND contains a space was split before it was unquoted, so both halves missed and two absent paths read as 'no site policy'. OpenSSH honours that form -- 10.2p1 applies an Include of a quoted spaced path -- and it is likelier on Windows. Quote-aware splitting rather than 'any quote is doubt', because answering doubt for an ordinary quoted Include with no space would reinstate the lockout this scanner exists to avoid. An unclosed quote is doubt. Unquoted spaces still split, which is also what OpenSSH does. The reconnect paint gate took the replay and re-scanned it, having already been scanned by the caller that decides whether to fetch a snapshot at all — two full splits of up to 100KB per pane per reconnect. It now takes the transition. hasReplay is passed separately because it cannot be inferred: a replay with no mode change and no replay at all both give null. Tests fail against the pre-fix code for the merge and all four scanner shapes. Correcting my own evidence claim from last round: of the two store tests, only the wipe one fails pre-fix. The other guards the asymmetry the fix creates and passes either way — worth keeping, but I should not have counted it. * fix(ssh): honour every Include quoting form OpenSSH does Fourth readiness pass. Two findings; one fixed, one deliberately not, with the evidence for refusing it. The tokenizer modelled double quotes only. A live 10.2p1 honours single quotes and backslash-escaped spaces too, and both fell into the same silent fail-open the double-quote case was raised for: fragments that resolve to nothing, and 'nothing there' is indistinguishable from 'no site policy'. The escape is limited to a backslash before whitespace, NOT a general one. A general escape would be catastrophic on the platform this most needs to be right for: the Windows site config lives at C:\ProgramData\ssh\ssh_config, so it would eat every separator in an Include beneath it and resolve to nothing -- reintroducing the fail-open it was meant to close. The test for that is discriminating rather than incidental: it gives the file a literal backslash in its name, so a swallowed separator resolves elsewhere and fails, where a plain 'expect false' could not tell the two apart. Verified it catches the naive version, and that the other two catch the old tokenizer. NOT fixed: the non-duplication guarantee still stops at the worktrees the merge rewrites. A worktree that is neither replaced nor named by the host is never walked, so a duplicate straddling that boundary survives. Extending the guarantee to the assembly point was implemented and REVERTED. Any rule there has to pick a survivor, and the ones available are wrong during a worktree-id change -- which is the very thing that produces these duplicates. Preferring the active worktree keeps the OLD id's copy at the moment a rename lands, because the active worktree has not moved yet; the new worktree was left with no tabs and its groups were never created. remote-workspace-snapshot-duplicate-tab-repair.test.ts caught it, which is the only reason I know the stronger version was wrong rather than merely bolder. A surviving duplicate is mitigated by active-tab-owner-worktree.ts; deleting the tabs of the worktree the user is about to land in is not. The comment now claims only what holds, and says why it is not stronger. Also records the exit from the isENOENT message-matching trade in remote-wire-compatibility.md, where someone touching the relay error path will be standing. * fix(ssh): expand Windows OpenSSH's __PROGRAMDATA__ token in known_hosts paths Captured real 'ssh -G' output from a Windows host rather than reasoning about it, which is the one thing that could not be inferred from the POSIX format. Two things came back that the code did not handle correctly, and one of them is the security failure mode this work exists to prevent. Native Windows OpenSSH prints the system paths with its own token UNEXPANDED: globalknownhostsfile __PROGRAMDATA__\ssh/ssh_known_hosts __PROGRAMDATA__\ssh/ssh_known_hosts2 userknownhostsfile C:\Users\neil/.ssh/known_hosts C:\Users\neil/.ssh/known_hosts2 Passed through as a literal path, __PROGRAMDATA__\ssh/ssh_known_hosts misses with ENOENT -- and an absent file is deliberately treated as 'no host is known there' rather than 'evidence withheld', because that is the normal state. So a site-managed known_hosts on Windows was silently invisible: every host in it read as first contact, and one whose key an admin had rotated produced a TOFU accept where it should have produced a mismatch. Now expanded from process.env.ProgramData, and left literal when that is unset rather than guessed -- a wrong path reads as absent, which is the very failure being fixed. The second finding is reassurance rather than a bug: separators are MIXED within one path (C:\Users\neil/.ssh/...), which Node's fs accepts on Windows, and a spaced home prints unquoted exactly as it does on POSIX. So the space-rejoin design is confirmed against the real format rather than assumed -- its motivating example, C:\Users\John Doe, splits the way the rejoin expects. The captured output is pinned as a literal fixture. Parsing and the rejoin are pure string work, so this covers the input shape honestly off Windows; it does not pretend to cover the platform's path arithmetic. The expansion test fails without the fix. Also confirms C:\ProgramData\ssh is the right site-config directory -- it exists on the host, empty -- so the scanner is looking in the right place. * fix(ssh): branch Include backslash handling on platform, both halves measured Fifth readiness pass found that the previous narrowing traded one fail-open for another. Both rules are right, on different platforms: POSIX 10.2p1: Include conf\.d/x.conf resolves as conf.d/x.conf four backslashes needed to survive as one -- argv_split and glob() each consume a level Windows: Include C:\Users\...\x.conf resolves, separators intact So a backslash before an ordinary character ESCAPES on POSIX and SEPARATES on Windows, and either rule applied everywhere fails open on the other platform. Preserving on POSIX means looking for a path with a literal backslash, missing, and reading 'no site policy'. Answering doubt on Windows means every absolute Include is doubt, which is the lockout the scanner exists to avoid. Now branched. POSIX answers doubt rather than emulating two rounds of glob escaping for a question this coarse -- a backslash in a POSIX system config path is vanishingly rare, so fail-closed costs nothing there. The review offered the Windows half as a reasoned assumption and flagged it as such. It is now measured on a real Windows host instead: backslash separators resolve, AND an escaped space still escapes amid them (C:\Users\neil\sshprobe\sp\ ace\x.conf -> port 2802), which is exactly the rule implemented. Two other worries were checked and came back unfounded -- a backslash-space inside EITHER quote is consumed by ssh, and a single quote inside double quotes is an ordinary character, which the single quote-state variable already reproduced. The tokenizer takes the platform as a parameter, so both sides are pinned from one host. Every expectation in the new oracle came from running a real ssh and reading what it resolved to, not from reading source or shell convention -- the tokenizer's whole job is to agree with ssh about which file it would read. Also narrows an overclaiming comment: the dedupe set is consulted only by the host-unknown filter, so a duplicate in the HOST's own snapshot still propagates. Pre-existing and unchanged; the comment now says what the code actually does. * fix(ssh): only expand __PROGRAMDATA__ when it is a whole path segment Found by probing the expansion I had just written, rather than by reading it: a bare startsWith also matches a path that merely BEGINS with those characters, so __PROGRAMDATA__evil/known_hosts was rewritten to C:\ProgramData\evil\known_hosts -- a directory the user never named. Same prefix-collision class I checked the site-config scanner for and then did not check here. Low reachability, since the token only appears because Windows OpenSSH emitted it, and it emits it as a whole segment. Fixed because the expansion is one review pass old and sits in the security path: a rewritten known_hosts path resolves somewhere unintended, and a path that resolves to nothing reads as 'no host is known', which is the fail-open this whole line of work has been closing. Now requires the token to be the entire path or be followed by a separator -- both separators, since the path is Windows-shaped but may be parsed anywhere. The test fails without the check. * test(ssh): split the pty provider spawn tests into their own file CI's static analysis went red on the merge of main: ssh-pty-provider.test.ts reached 803 counted lines against a maximum of 800. Both sides contributed -- main grew the file and this branch added 7 lines to it -- so neither shows the violation alone, which is why local lint stayed green until main was merged in. AGENTS.md forbids disabling max-lines or bumping a per-file limit, and that rule is right here: the file was doing two jobs. Spawn owns the startup contract -- ingress version, env scrubbing, execution ownership, and the reconnect races -- and is 630 of the 922 lines. It reads as its own unit rather than as an overflow file, so it moves to ssh-pty-provider-spawn.test.ts and the shared relay stub moves beside it under a name that says what it is. Same tests, same count: 713 provider tests pass, and the line total is unchanged across the two files. * fix(ssh): remove the dead lint suppressions, and reach Terminal 1 in the restore spec Two CI failures, both surfaced by this branch rather than caused by it. Static analysis: the two no-require-imports suppressions on the ssh2 constants require() are now unused -- main's config no longer reports that rule there -- and the changed-code audit treats a dead directive as an error. Removed; the audit CI runs passes locally on the merge. E2E: ssh-cold-activation-restore failed on clicking Terminal 1. This PR is what routes that spec into the changed-e2e lane at all -- before, the Docker-SSH specs only ran when someone edited a spec file, which is the gap this branch set out to close -- so its first run in CI was here, and the failure is pre-existing rather than new. The trace shows the cause: six restored tabs overflow the strip at CI's window size and the restore pins it to the END, so Terminal 1 sits outside the scroll viewport. Playwright's own scroll-into-view loses that race against the sticky-to-end effect and times out on an element it can see but never reaches. The spec's intent is to activate the first tab and prove it remounted, not to exercise strip scrolling, so it now scrolls the strip to the start first. Not papering over a product bug: the strip is a native overflow container with working arrow controls, so a user can reach the tab -- it is Playwright that cannot drive a moving target. Six specs pass locally in CI's exact order and worker count. * test(ssh): press the restored first tab directly instead of waiting for it to hold still The previous attempt swapped a click for scrollIntoViewIfNeeded and hit the same 30s timeout, which identifies the real cause: not that Terminal 1 is out of view, but that it never holds STILL. Both APIs wait for the element to stop moving, and the strip keeps re-laying-out while the relay reconnects behind it -- so both time out on an element they can see and never settle on. Driving the pointer directly needs no element to be stable, only to be somewhere at the moment it is pressed, and the attempt is retried against the store rather than believed. Activation is deferred to pointerup and suppressed past a drag threshold, so it has to be a real down/up pair at one position -- a synthetic click event would not select the tab at all. Passes twice locally. The previous version also passed locally, so the honest statement is that the local runs prove the interaction still works, not that they reproduce CI's instability -- CI is the oracle for that.	2026-08-17 16:40:01 -07:00
Jinwoo Hong	fa9b20cb41	feat(skills): reland private bundle sharing safely (#14934)	2026-08-16 13:45:54 -07:00
Neil	9f3a912c1e	fix(terminal): type Option-composed ASCII instead of reporting it as a chord (#14743) ... * fix(terminal): preserve Option-composed ASCII input * fix(terminal): preserve Option keyboard protocol semantics * fix(terminal): complete Option keyboard event encoding * fix(terminal): harden Option input encoding * fix(terminal): close keyboard protocol fallback gaps * test(terminal): prove Option-composed ASCII reaches the pty end to end The Option-compose fix had unit coverage only. This drives a live Electron pane whose kitty flags are armed by the application's own CSI > 1 u and asserts the bytes at the pty boundary: composed `@` and Shift-layer `\` arrive as text, configured Option-as-Alt still reports the layout-resolved chord, and a non-ASCII glyph still reaches the app as its alt hotkey. Restoring the pre-fix policy fails exactly the two composed-text scenarios. Also records the ASCII rule's rationale where the rule lives, not only in a test comment. * refactor(terminal): drop the unread Option layers from the layout snapshot The native helper computed an Option and Option+Shift character for every key, shipped both over IPC, validated them in the parser and cached them in the renderer — but no production caller ever asked for them. Only the base and Shift layers are read, and Shift is the one the web layout map cannot supply, which is why the helper exists at all. Removing them halves the helper's UCKeyTranslate work per key and drops the option parameter that six signatures were threading through for nobody.	2026-08-16 12:49:02 -07:00
Jinjing	763b1febeb	Revert "feat(skills): add private bundle sharing (#14401)" (#14913) ... This reverts commit 757fae28d7.	2026-08-16 10:39:57 -07:00
Jinwoo HongandE2E Test	757fae28d7	feat(skills): add private bundle sharing (#14401) ... Co-authored-by: E2E Test <e2e@test.local>	2026-08-16 02:36:18 -07:00
Neil	eb22e497bb	Revert "fix(ssh): reapply the reattach-identity work and stop the fallback fence stranding moved panes" (#14395)	2026-08-13 18:11:33 -07:00
Neil	6a0c8fa541	fix(ssh): reapply the reattach-identity work and stop the fallback fence stranding moved panes (#14384) ... * Reapply #13326 and #13928 (un-revert #14361) Restores the SSH reattach-identity and daemon-occupancy fixes. Reverting them reintroduced their P0s, filed as STA-4224, STA-4225, STA-4227, STA-4230, STA-4232, STA-4233 and STA-4234 against #14361. The tab loss that motivated the revert is fixed in the commits that follow, so this reapplication is not a straight redo. * fix(relay): stop the fallback attach fence refusing a pane that moved tabs The primary fence was moved to the shell's own incarnation precisely because paneKey/tabId froze the pane's LOCATION at spawn and refused panes that had merely moved. The fallback that older clients fall into kept the old rule, so the correction never reached it — the same 'the rule exists, but this path does not ask it' leak this work has hit repeatedly. A refusal here is not recoverable: an identity mismatch never grounds a respawn, so the pane keeps a live shell it can no longer reach and renders blank. Narrowed to paneKey, which is the identity; the tab is a location. Restoring the tabId comparison reddens the new test.	2026-08-13 16:45:24 -07:00
Neil	11cd2b4310	revert(ssh): back out #13326 and #13928 — reconnect loses every tab (#14361) ... * Revert "fix(daemon): stop killing live coding agents when the daemon can't report its sessions (#13928)" This reverts commit 2e8cf589de. Reverted together with #13326: the 1.4.182-daily.202608131439 build carrying both loses every tab on an SSH disconnect/reconnect cycle. Reverting first so main stays releasable and the P0 fixes in the wild remain cherry-pickable, rather than fixing forward on a shipped regression. * Revert "fix(ssh): stop SSH reconnect from multiplying terminals and resuming agents twice (STA-3077)" (#13326) This reverts commit 3ab8b6a117. Reported on 1.4.182-daily.202608131439: connect to an SSH worktree, disconnect the host from the hosts popup, reconnect — every tab is gone. That is worse than the behaviour this PR set out to fix, where most tabs were retained. Reverting rather than fixing forward, so main stays releasable and the P0 fixes already out in the wild stay cherry-pickable. STA-3077 stays open.	2026-08-13 14:54:29 -07:00
Jinjing	70abf5cacc	test: add golden e2e tests for agent TUI launch and shell recovery (#14258) ... * test: add golden e2e tests for agent TUI launch and shell recovery Add test fixtures and E2E tests to verify agent TUI functionality: - Stub agent implementation supports cross-platform execution (Unix/Windows) - Test verifies multiline composer with Shift+Enter support in agent TUI - Test verifies clean shell resumes after agent exit without state leakage * test: add golden e2e tests for agent TUI launch and shell recovery Add agent TUI launch and shell-recovery tests to the golden (release-blocking) E2E suite, covering agent initialization and shell availability after agent exit. Improve escape sequence handling in the stub agent to prevent stray key reports from contaminating test output. Add terminal input readiness checks to ensure commands execute reliably before verification. * test: coerce golden stub stdin chunks for type-aware lint Node types the stdin data event as string | Buffer even after setEncoding('utf8'), so restrict-plus-operands failed CI. * test: fix golden stub agent Windows batch files and add Ctrl+C support - Store batch files with CRLF to avoid Windows 512-byte parser boundary bug - Handle Ctrl+C (0x03) in raw mode as alternative to Ctrl+D (0x04) - Update release notes documenting golden test skip behavior on older tags * Remove Windows batch file gitattributes workaround The -text whitespace=cr-at-eol rule preventing CRLF conversion for .cmd files is no longer needed. Allow batch files to use normalized line endings.	2026-08-13 10:31:08 -07:00
Jinjing	b8d6b21dfa	test(e2e): add golden E2E tests for workspace session management (#14304) ... * test(e2e): add golden E2E tests for workspace session management - Restore exact file and terminal state after quit/relaunch - Verify terminal file link activation and external edit detection - Test worktree creation and switching with isolated terminals - Isolate test repo paths between concurrent CI runs with UUIDs * Add platform-aware marker echo command utility - Create splitMarkerEchoCommand() to generate shell commands that safely echo test markers across Windows and Unix platforms - Split markers into prefix/suffix fragments so output assertions prove execution, not just shell echo-back - Consolidate SORTABLE_TAB export and improve tab bar locator logic - Refactor terminal link helpers to extract client point calculation	2026-08-13 10:26:20 -07:00
Jinjing	e84fb46eaf	test: add golden E2E tests for source control workflows (#14260) ... * test: add golden E2E tests for source control workflows - Tests core source control interactions: file edit/save, commit staging, and diff viewing - Integrated into CI/CD pipelines for Linux, macOS, and Windows - Includes helper utilities for test setup and worktree management * test(e2e): verify golden commit author and fix test flakiness - Configure git author name/email at worktree level during setup - Verify commits are made with correct author details in assertions - Add explicit timeouts to file visibility waits and git status polling - Fix test ordering to seed edits after source control is open - Simplify git status refresh logic to rely on automatic updates * Add rollback to createGoldenWorktree on setup failure Cleanup callbacks only register after setup succeeds. When a config command fails, the half-built worktree and branch leak into later test runs, causing flakiness. Now we roll back immediately and re-throw the setup error. * test(e2e): match explorer rows after the git status badge appears The golden file-save spec used an exact /^README.md$/ filter. After save, the explorer row text becomes "README.md M", so reopen clicked nothing. * test: strengthen golden worktree setup verification - Track working directory in git call inspection to verify correct execution context - Verify user.name/email config applies to worktree-specific settings, not repo - Add exhaustive setup call sequence assertions to catch setup/rollback leaks	2026-08-13 09:56:30 -07:00
NeilandOrca	2e8cf589de	fix(daemon): stop killing live coding agents when the daemon can't report its sessions (#13928) ... * fix(daemon): stop killing a wedged daemon that still owns live agent PTYs A daemon too busy to answer listSessions was indistinguishable from a dead one: getAliveDaemonSessionCount() returns null ("could not verify"), the preserve gate required `!== null && > 0`, so the run fell through to killStaleDaemon() and every running coding agent died with it. The sibling replace branches all preserve on null; this one alone collapsed "can't tell" into "empty", which src/main/daemon/AGENTS.md already forbids. Give the decision an out-of-band second opinion. inspectDaemonPtyOwnership() reads the OS process table — never the daemon socket, which is exactly what failed — and reports whether the daemon's own process still has live PTY descendants. Under preserveWhenOwningLivePtys, that evidence vetoes the signal and the launcher adopts the daemon in degraded mode instead. The veto is opt-in so it cannot make a daemon unkillable: only the failed_health_check path enables it. Manage Sessions -> Restart still kills. Only positive evidence preserves, so a wedged daemon with nothing to lose is still replaced (#8689). Also stop replacing silently: the verdict now prints on the post-kill truth, which stays quiet on a cold start because nothing was killed. Co-authored-by: Orca <help@stably.ai> * fix(daemon): survive preserving a daemon too wedged to be adopted Adversarial review found the veto's own success path could not complete against the daemon it exists to protect. Preserving routed through holdDaemonAdoptionLease(), which opens a hello — the exact operation a wedged daemon cannot answer — so it threw, aborted initDaemonPtyProvider, and left no spawner. restartDaemon() throws without one, so the user lost the documented Manage Sessions -> Restart remedy on top of having no daemon: strictly worse than the data loss being fixed. A still-listening endpoint means wedged, not gone, so keep a lease-free handle instead. The lease only cancels the adoption watchdog, which never fires on a daemon that owns sessions. Degraded mode likewise tolerates a lease and a session discovery it cannot complete. Three more from the same review: - The veto keyed on reason === 'failed_health_check', but a daemon that answered listSessions with 0 lands in that same branch and must stay replaceable. Key on liveSessionCount === null, which is what the option actually documents. - Zombies are not evidence of live work. A wedged daemon cannot reap, so its exited agents linger as <defunct> and would read as "still running" — a false positive correlated with the wedge itself. Enumerate through the process table's stat column and exclude them; sample twice so a resolver probe or health-check shell cannot masquerade as an agent. - Restore the "did anything answer?" log guard alongside the confirmed kill, so a daemon that self-retires before the kill is still announced. Co-authored-by: Orca <help@stably.ai> * test(daemon): kill the mutations that let the PTY veto ship as a no-op Mutation testing found four survivors — changes that break the fix while every test stays green: - Swapping the POSIX reader to the 500ms-cached one passed. It is not just a staleness hazard: inside the TTL both sampling attempts receive the same array, collapsing the two-sample confirmation to one. Pin the fresh reader. - Replacing killStaleDaemon's default inspector with one that never reports live PTYs — the veto disabled in production — passed, because every veto test injects the hook. Exercise the real seam. - Adding the veto to cleanupDaemonForProtocol passed, which is verbatim the failure its own doc warns about: a user-initiated restart of a daemon owning live PTYs would refuse, then throw. Pin that call's arity. - The ppid-cycle fixture put the cycle outside the daemon's subtree, so the walk never entered it and deleting the visited guard passed. Also bound the Windows enumeration, which had no budget of its own: two CIM queries with a wmic fallback can stall the launch path for tens of seconds. Blind is a safe answer there; hanging is not. Co-authored-by: Orca <help@stably.ai> * fix(daemon): require session-leader evidence and stop preserving daemons that can never be adopted Round-three review found the veto too eager in three ways, each of which traded the original data loss for a whole-session degrade or a permanently daemon-less app. Evidence was "any non-zombie descendant", justified by re-sampling to weed out transients. The two samples are taken back to back — one ps fork apart — so nothing transient is ever weeded out, and a hung helper (often the very reason the daemon is wedged) reads as an agent. Use the structural signal instead: a PTY child is a session leader, because forkpty calls setsid, and no helper the daemon forks ever is. Re-sampling now only retries blindness. A 'rejected' daemon answered and refused the handshake, so it can never be adopted; preserving it repeated the same failed adoption on every launch, forever. And the veto read the process table, not the socket, so it could fire on a daemon whose endpoint was already gone — adoption then threw, init aborted, and the app was left with no spawner and no working Restart. Gate on both: only preserve what could still be reached. Also: releasing the launcher's temporary lease after the permanent lease failed reopened the adoption gap that ordering exists to close, and the tolerance added to discoverDaemonSessions was dead code — nothing on that path rejects. Co-authored-by: Orca <help@stably.ai> * refactor(daemon): decide occupancy before the kill, not inside it Three review rounds each found a new failure state in the previous shape, which was the design telling us something. The safety rule — never destroy running work — was replicated across the launcher's branches instead of being decided once, and the last round added it to one more branch behind a boolean. Policy had been put inside a mechanism: killStaleDaemon grew an input flag to disable its new veto, an output back-channel to report it, and a caller-side re-derivation of the classification the flag had lost. One structural error, one symptom per layer it crossed. Name the question instead. resolveDaemonOccupancy answers occupied | empty | unknown, asking the daemon first (authoritative both ways) and falling back to the process table only to RAISE the answer to occupied. OS evidence can prove work exists; it can never prove absence, so it never licenses a kill. The launcher now decides before it destroys anything, so killStaleDaemon goes back to being only "make this pid go away" — no options, nothing for a future caller to forget to disable, and Manage Sessions -> Restart cannot be vetoed because there is no veto left to hit. Holding is a real outcome now. A daemon that owns live terminals but cannot answer a handshake gets mode 'held': no adoption attempt, no lease, no fork beside it. That deletes the lease-free-handle fallback, the try/catch around preserve, and the tolerated-lease branch in init that existed only because the correct outcome had no representation. Two defects this removes outright: - The endpoint check used a local boolean probe that returns false on timeout, so under load — and unconditionally on Windows named pipes, where a busy server answers ERROR_PIPE_BUSY — the guard disabled itself in exactly the conditions it was written for. Use the canonical three-valued probe, whose own docs say absence of proof is not proof of death. - A daemon that answered and refused the handshake was killed with its agents. It is now held like any other occupied daemon. Also folds the replacement verdict onto pendingReplacement, retiring a pair of mutable launcher locals whose only job was moving one warning past the kill. Co-authored-by: Orca <help@stably.ai> * fix(daemon): make the occupancy residual total The module's contract is that 'unknown' is where every unanswerable question lands, but a throwing dependency escaped instead — routing a failed observation into the launch path rather than onto the safe residual. Latent today because both real implementations swallow their own failures, which is exactly the kind of thing that stops being true during a refactor. Co-authored-by: Orca <help@stably.ai> * fix(daemon): stop counting the daemon's own probe PTYs as hosted work Round-four review found the evidence proving the wrong thing. The filter excluded the daemon's plain subprocesses on the grounds that only a PTY child is a session leader — but the daemon opens PTYs for its own health probe and conpty warmup, and forkpty makes those session leaders too. The comment's own premise refuted its exclusion list. A daemon hosting zero user terminals could be held on the strength of its stuck probe child, and since the held daemon also had no sessions, dropping our authenticated pair let it retire and take the very state we were protecting. Exclude them by exact command, on both platforms. Two more from the same review: - pty-spawn-unhealthy is only reachable after a successful hello, so that daemon is adoptable. It was routed to 'held' — which never adopts — purely because the count had come from the process table. Check it first; hold now requires an unreachable daemon. - The grace loop rescanned the process table every pass, though it is waiting for IPC and the table cannot change its answer in five seconds. Ask the daemon during the wait and read the table once, after. raiseOccupancy- WithProcessEvidence makes that split explicit, and can only ever raise. Bound the wait by wall clock too: the retry count alone never bounded it, and startup fails open at 60s by abandoning the daemon provider outright, which would trade a wedged daemon for no daemon and a Restart that throws. Co-authored-by: Orca <help@stably.ai> * fix(daemon): hold a hello-rejected daemon instead of adopting one that refused us Found while reviewing why a mutation looked equivalent. Gating the hold on health === 'unreachable' left 'rejected' — a daemon that answered and refused the handshake — falling through to preserveDaemon(), whose adoption opens the very hello it just refused. That throws, and the throw costs the app its daemon and its Restart remedy. Killing it instead is no better: it can still be hosting running agents. Neither of those daemons can complete a handshake, so neither may be adopted, and both must be held. Gate on that rather than on one of its two causes. Adds regression tests for the round-four fixes: the self-spawned probe exclusion is exact-match on both platforms, an adoptable pty-spawn-unhealthy daemon is never routed to a mode that cannot adopt, evidence can only raise a verdict, and the grace budget stays under the startup fail-open cap. Co-authored-by: Orca <help@stably.ai> * fix(daemon): decide adoptability from what the daemon can do now, in one place Round five found the same question — can this daemon complete a hello right now? — answered in three places with three different conclusions, because 'held' had been added as a fifth branch rather than as the classification the other branches route through. Two of those answers were wrong, and both ended in no daemon at all, which is the outcome 'held' exists to prevent. - A daemon whose adoption hello had just failed was handed back tagged 'degraded-new-pty-fallback'. Init skips the lease only for 'held', so it reopened the same connection, threw, and aborted startup — leaving the agents alive but unreachable and Manage Sessions -> Restart throwing. - The pty-spawn-unhealthy arm ran first and claimed a successful hello proved adoptability, but that reading is from before the grace window. A daemon that answered at t=0 and went silent through thirty seconds of retries took that arm and threw the same way. Ask whether it is answering now, first. The budget was a comment with a Date.now() beside it: one occupancy probe could cost 50s, because the client's default is a 5s hello per connection step plus a 30s request timeout. Bound the probe explicitly, start the clock before the first one, and size the window so the whole path — health check, pid verification, loop overshoot and process-table read — fits under the startup fail-open with room to spare. Also folds the four sibling branches onto the same occupancy resolution. getAliveDaemonSessionCount was byte-identical to countLiveSessionsOverIpc, so one concept had two implementations and only one of them had been fixed. The Windows probe exclusions could never match: the warmup spawns COMSPEC, an absolute path, against an exact-equality test on 'cmd.exe /c exit'. Compare the program by basename and keep the argv tail exact. Co-authored-by: Orca <help@stably.ai> * fix(daemon): stop the local fallback answering for sessions it does not own Closing a held daemon's pane reported success while the agent kept running. Unrouted ids resolve to the in-process fallback, whose shutdown returns silently for an id it has never heard of and whose write and resize are no-ops — and while a daemon is held nothing ever enumerates its sessions, so every one of them is unrouted. The pane vanished, the orphan outlived the app, and typing into a stuck terminal disappeared without a word. Only attach was fenced against that route. Extend the same rule to the operations that change or feed a session: route to the fallback only when it genuinely owns the pty, and otherwise say the session cannot be reached. The error type is load-bearing. pty:kill treats "Session not found" as proof the pty is already gone and synthesizes an exit, so reusing that error would have reproduced the lie one layer down. TerminalSessionOwnerUnverifiedError means "still there, we cannot reach its host", which is reported as a failed close and keeps ownership for a retry. Co-authored-by: Orca <help@stably.ai> * test(daemon): pin that a held session cannot be closed by a provider that never had it Covers the held-daemon routing fence, including the coupling that is invisible from the routing file: the thrown error must not match pty:kill's already-gone predicate, or the close is swallowed into a synthesized exit and the orphan is hidden again. A rename would otherwise reintroduce the bug silently. Co-authored-by: Orca <help@stably.ai> * fix(daemon): bound the POSIX evidence read and re-verify the pid it describes Round-six follow-ups, none destructive. The process-table read had a deadline on Windows but not on POSIX, where the shared reader's ps timeout does not cover queueing behind an in-flight scan — so the one step that runs after the grace window could still outlast it. The pid handed to that read was verified before the grace window, which is long enough for the daemon to die and its pid to be recycled onto a shell with children. Verify it where it is used instead, and only when there is still something to raise: the common case now skips the identity probe altogether, which also takes a few seconds off the worst-case launch. Two renderer call sites killed PTYs without handling rejection. That was harmless while an unreachable session was answered by a silent no-op; now that it honestly rejects, pane teardown and repo removal would log an unhandled rejection every time — exactly when the daemon is already sick. Deliberately not taken from that review: giving the endpoint-occupied catch the same held fallback as the failed-health path. That path arrives with occupancy unknown or empty, so holding there would swallow a real launch failure to protect nothing. Splits the repro script, which had grown past the line limit, into the sequence it proves and the two things it proves it with: process-table inspection, and the static assertions on the launcher's hold decision. Co-authored-by: Orca <help@stably.ai> * test(daemon): hold the classification budget to the whole path, not one term The previous assertion compared the grace window to the fail-open cap, which passed while the real path ran to roughly twice the cap — a single probe cost 50s against a 5s assumption, and the terms on either side of the loop were never counted at all. Sum the declared budgets instead: health check, grace window, the one probe that always runs past a ceiling tested at loop entry, and the evidence read on both platforms. Raising any of them now has to face this, and the spare time the kill ladder and fork still need afterwards is stated rather than assumed. Lives outside the launcher's own spec because that file mocks daemon-health, which would shadow the constants being held to account. Co-authored-by: Orca <help@stably.ai> * fix(daemon): do not read a stranded login wrapper as a hosted terminal Raised by a colleague's handoff on the same-day reports. macOS wraps every terminal in /usr/bin/login for TCC attribution, and #13764 shows the wrapper can outlive the shell it wrapped — leaving a session leader that hosts nothing. One affected host had accumulated enough of them to reach swap pressure. That is exactly the evidence this change treats as proof of live work, so a daemon whose sessions had all ended would have been held indefinitely on the strength of the corpses, on precisely the hosts where the problem is worst. Same class as the daemon's own probe PTYs: a session leader is necessary evidence, not sufficient. A wrapper still doing its job has the shell it exec'd beneath it. Co-authored-by: Orca <help@stably.ai> * test(daemon): pin the daemon's PTY spawn sites so the exclusion list cannot silently rot The ownership evidence discounts the PTYs the daemon opens for itself, and that list is only safe while it is complete — a self-spawned PTY nobody excluded reads as user work and holds a daemon that owns nothing. The list grew one reviewer at a time, which is the wrong mechanism for a correctness invariant. Pin the input rather than the list. The daemon has exactly three PTY spawn sites: the user's terminal, the spawn health probe, and the Windows conpty warmup. A fourth now fails this test until someone decides which side it belongs on. Co-authored-by: Orca <help@stably.ai> * fix(daemon): stop the evidence going blind on the host it exists to protect Readiness review, section 04. Every agent pane already drives the shared process-table reader on its own cadence, so the uncached read queues behind them — and the host with the most agents to lose is the one likeliest to blow the deadline on queueing alone. Both attempts return unknown and the daemon is killed anyway, which is the original bug wearing the fix as a costume. Fall back to the TTL-cached table, which on that host is always warm for exactly the reason the uncached read is always queued. A table a few hundred milliseconds old still answers whether this daemon has children, and the failure directions are not symmetric: over-holding costs one degraded launch that self-heals, under-counting ends running agents. The same review found the launch budget still overran the 60s startup fail-open — by ~7s on Windows — and that the test guarding it under-counted the path it was written to bound, for the second time. It omitted the identity probe before the evidence read and the endpoint check that ends the grace loop. Both are now summed, the headroom requirement covers the kill ladder and fork that follow a replace verdict, and the grace window and Windows probe deadline are sized to fit. Not taken from that review: reusing the verified pid inside killStaleDaemon to drop the duplicate probe. That second verification is what fences the signal to this incarnation, and a seconds-old result is exactly the pid-reuse hazard it exists to prevent. Co-authored-by: Orca <help@stably.ai> * fix(daemon): confirm emptiness before it authorizes a kill Readiness review, sections 02/03/05/06 — no P0 or P1 in any of them. These are the P2s worth taking. The important one: on macOS a terminal contributes exactly one session leader, the login wrapper, because the shell it forks is in the same session and shows S+ rather than Ss. I had assumed the shell counted too. It does not — so a wrapper that looks childless in a single snapshot makes its whole terminal invisible, and that snapshot cannot tell a wrapper whose shell has gone from one whose shell has not yet appeared. Emptiness is the answer that authorizes a kill, so it now costs a second read; 'owns-live-ptys' still needs none. The fixtures said Ss where a real shell says S+, which is why the tests never noticed. Also from that review: a fabricated row was cast to ProcessTableRow to reuse a command-only predicate, which is sound only while that predicate reads nothing else — narrowed to Pick<'command'> so the compiler keeps it honest. The pty:signal listener relied on its provider staying async to convert a routing refusal into a rejection; it is an ipcMain.on listener with nothing above it, so it now catches synchronously too. And the repro's teardown signalled remembered pids a minute after phase 1 waited for them to die — re-verify by tag first, since signalling a recycled pid is the mistake the script exists to study. Co-authored-by: Orca <help@stably.ai> * fix(daemon): stop guessing at Windows occupancy instead of guessing better The readiness review found the Windows branch reading a wedged daemon's orphaned conpty hosts as live terminals. ClosePseudoConsole only runs on the daemon's own JS thread, so a daemon too wedged to answer is also too wedged to reap them, and they accumulate exactly when this code runs. A wedged, empty Windows daemon would then be held forever — #8689 re-opened, and a regression from main rather than a missing protection. The tempting fix is another exclusion. That would be the sixth revision to what counts as a live PTY, each one added because a reviewer found something that looks like a session and is not, and each one trading safety for availability in a fix whose entire purpose is the opposite trade. The list is the problem. POSIX has a real signal: forkpty makes a hosted terminal a session leader, which nothing the daemon forks for itself ever is. Windows has no equivalent, so its branch could only ever count descendants and subtract guesses. Delete it and answer 'unknown' — Windows keeps exactly the behaviour it has on main, and the protection is claimed only where it can be justified. Also stops a blind confirming read from upgrading an unconfirmed emptiness into a verdict. Emptiness is what authorizes a kill; a read that saw nothing corroborates nothing. Co-authored-by: Orca <help@stably.ai> * refactor(daemon): clear the debris the Windows removal left behind Behaviour-preserving. Windows now abstains once at the entry point rather than twice inside a retry loop that had nothing to retry, which also retires the platform check further down that could no longer be false. The self-spawn matcher kept backslash splitting and .exe stripping for a branch that no longer exists, and the launcher's grace loop repeated its own IPC call and stacked two explanations above the wrong statement. Co-authored-by: Orca <help@stably.ai> * fix(daemon): stop the budget cut spending Windows' only protection Round seven found the one thing this PR must never do: kill a session that main would have kept. Main's grace loop probed with a non-shared 5s connect budget, so a wedged daemon got roughly a minute to come back. Bounding the probes and adding a wall clock cut that to about twelve seconds — a good trade on POSIX, where a daemon that outlasts the window is still protected by process-table evidence, and a bad one on Windows, which has no such evidence and now has nothing else. A Windows daemon wedged for half a minute while hosting agents was adopted by main and is killed by this branch. The fail-open cannot rescue it either: ensureRunning() is not abortable, so the launcher runs to completion. Size the window per platform instead, against what each actually spends: Windows pays no evidence read and no identity probe to feed one, so it can afford far more grace, and grace is worth more where it is the only thing there. Both numbers come from the budget test rather than taste. Three more from the same review: - The evidence read applied its deadline twice, once to the fresh table and again to the cached fallback, so an attempt could cost double what the launch budget was told. Share one deadline across both. - Two tests described protection the code no longer delivers: one asserted ~60s of grace the wall clock had already retired, the other passed only because its mocked probes are free and would fail against real ones. Say what the code actually promises, and freeze the clock where the point is retry depth. - The self-spawned PTY inventory promised more than it inspects. It sees direct node-pty calls in one directory; the macOS login-session probe reaches a PTY through expect(1) and is caught by the stranded-wrapper filter instead. Scope the claim, since that indirection is the shape the next escape will take. Co-authored-by: Orca <help@stably.ai> * refactor(daemon): spend the launch budget against a clock instead of a sum Round eight found the fourth term missing from the hand-written budget — the launcher's own adoption connect, which runs before the health check on the non-shared five-second path. The three before it were an identity probe, an endpoint probe, and an evidence deadline applied twice. Every one of them passed the test meant to catch exactly that, because the test could only check the terms someone had remembered to add. So stop summing. The classification now runs against a deadline and stops when it expires, and the test asserts only that the deadline leaves room for the kill ladder and the fork that follow it. A budget that has to be remembered is a budget that will be wrong; this one cannot be, because nothing has to be counted. That also retires the platform-split grace window, which existed to hand Windows more of a sum nobody could total correctly. The same review found the regression it was compensating for was never the window. main gave each probe up to fifty seconds — five per connection step, thirty for the request — where this branch gave eight for both together. A daemon whose handshake needs more than four seconds therefore answered none of the probes, however many it got, and on Windows nothing else can speak for it. Splitting the two budgets fixes the case the window never could: connecting stays tight, because a daemon that cannot handshake is wedged and worth re-asking cheaply, while a daemon that did handshake is demonstrably alive and its count is worth waiting for. Also stops a Date.now spy leaking out of a failed test and freezing the clock for the rest of the file. Co-authored-by: Orca <help@stably.ai> * fix(daemon): make the classification clock actually bound the work it names The clock introduced in the previous commit gated the probes but not the two steps after them. The identity re-check and the process-table read ran on their own deadlines, outside the ceiling, so the launcher could still spend its whole budget on probes and then take another ten seconds — the same overrun the sum used to produce, arrived at from the other end. Hold that time back from every probe instead. A probe is only started when the clock can still fund a handshake after the reserve, and its budget is what remains minus the reserve, so no probe can eat it however long the daemon takes to answer. Worst case is now the ceiling by construction rather than by addition. The reserve has a test asserting it is large enough for what it covers, which failed on its first run and caught that ten seconds was not. Co-authored-by: Orca <help@stably.ai> * fix(daemon): ask the wedged daemon a question it can actually answer Round nine found the re-verification was stricter than the check that triaged the daemon onto this path. The launcher gets here because a three-second health check — one socket, one hello — timed out. It then re-asked with two sockets and two hellos inside four shared seconds, and repeated that identical question up to twelve times. A daemon that consistently needs five seconds fails every one of them, so the retries could only ever agree with the check that sent it here. main re-asked with five seconds per connection step and thirty for the answer, and kept the sessions this branch destroyed. Retries and patience solve different problems. Keep the cheap probes, which catch a daemon that recovers on its own, then spend what is left of the clock on one tolerant ask — the only question that can disagree with the triage. It is skipped when the endpoint is provably gone, since a cold start arrives here too and has nothing to wait for. Two more from the same review. The clock claimed to cover the launcher's own adoption connect and started after it, so the fourth term that went missing from the sum was still uncounted; it now starts above that connect and bounds it. And Windows was holding back twelve seconds for an identity check and a process-table read it never performs — the reserve is zero where the steps it reserves for do not run. Retuned the ceiling to leave the kill ladder and fork real margin rather than half a second, with the packaged-Windows host copy named as what the margin is for. Co-authored-by: Orca <help@stably.ai> * fix(daemon): ask the tolerant question while the clock can still fund the answer The launcher asked the cheap question first and the patient one last. That is backwards. This path is only reached because a 3s health check timed out, so every 4s probe re-asks on a stricter budget than the one that triaged the daemon here — it can only ever agree. The one ask that could disagree ran last, by which point the clock could fund its handshake but not its answer, and a daemon that answered in 12s was read as dead and replaced along with its agents. Three changes, one idea: never make an ask you cannot afford to hear out. - The patient ask goes first, with every millisecond the answer does not need. - Cheap retries follow it, and stop once the clock cannot fund both halves. Funded to knock but not to listen is not an ask. - The adoption connect is capped. It is not a classification step — it acquires a lease preserveDaemon() re-establishes anyway — but on a daemon that accepts the socket and never completes hello it would spend the entire classification budget, leaving nothing for the probes that protect that daemon's sessions. The test double now forwards the connect budget instead of dropping it, so what the launcher was willing to wait for is observable at all. * fix(daemon): stop three follow-ups rotting where review already found them A truncated paste now says so. A routing throw partway through a paste was not a PtyWriteUnavailableError, so no pty:writeUnavailable reached the renderer and the pane never re-attached — the remaining chunks simply vanished with nothing to attribute the gap to. It stays deliberately distinct from SessionNotFoundError, which isPtyAlreadyGoneError matches and synthesizes into an exit the session never had; a test now pins both directions so neither drifts. The launch-budget spec no longer fails on Windows. The evidence reserve is zero there by design — neither guarded step runs without a session-leader signal — but the assertion demanded eleven seconds of it unconditionally, so `pnpm test` broke on any Windows dev machine. PR CI never saw it: only the WSL boundary spec runs on windows-2022. The identity ceiling it reserves against is imported now instead of being a 3_000 someone would have to remember to change. And the grace-retry comment described the design that preceded the clock: ~5s probes, ~60s of grace, a number worth raising. The clock binds first and usually permits far fewer, so raising it alone buys nothing. * fix(daemon): stop killing a daemon we merely failed to observe Ten review rounds each found a different band where this branch replaced a daemon that origin/main would have kept, and every fix bought a new one. The reason is arithmetic, not carelessness: matching the old tolerance for a single probe costs about 25s, the classification clock has 15s to give, and funding the difference puts startup past the 60s fail-open once the kill ladder and the fork are paid. No assignment of those numbers is safe. So the residual stops being lethal. daemon-occupancy.ts always said it — "'unknown' is the residual, and it is not permission" — while daemon-init.ts fell through from unknown to killStaleDaemon. That fall-through is what made every millisecond of budget a correctness parameter. Now an unclassifiable daemon is held in degraded mode: existing terminals keep working, fresh ones run locally, and being wrong costs a degraded session instead of somebody's agent. Two exclusions, both about never holding something unrecoverable. A proven-dead endpoint is a cold start or a corpse, and holding one would hand every first launch a provider pointed at no daemon. 'rejected' answered and refused, so it can never be adopted and its sessions can never be reattached. The cost is real and deliberate: a wedged-but-empty daemon is no longer replaced at launch, so #8689 degrades to "restart it from Manage Sessions". Which only works if the user knows — and degraded mode was computed, plumbed through preload, and read by nothing. It now renders where the Restart button already lives, and says what it actually costs: new terminals close when you quit, and restarting ends whatever the host is still holding. Rejected on the way here: a background reclassifier (a permanently wedged daemon never answers, and recovery is already handled by degraded-daemon-fresh-spawn- routing.ts), letting accumulated process-table reads license a kill (its errors are systematic, so more samples agree rather than converge), and sidelining the daemon onto a renamed socket (verified working at the syscall level, then abandoned: the daemon's own endpoint-ownership watch reads the moved entry as lost and retires itself, precisely when it recovers). * test(daemon): pin the hold that no longer depends on a clock The repro proved the launcher holds a daemon it can see is occupied. The protection that now matters most is the one for a daemon it cannot see at all, and nothing asserted it. Adds the unknown-hold to the static assertions: that it exists, that it excludes 'rejected' and a proven-dead endpoint, and that every killStaleDaemon call site in the file is downstream of it. Verified by mutation — dropping either exclusion fails the assertion. * fix(daemon): repair what round eleven found, including a fix that did nothing The patient ask was not patient. With twelve seconds reserved for the evidence read, `max(CONNECT, probeBudget - REQUEST)` resolved to exactly CONNECT — the tolerant ask got the cheap ask's four seconds, and the grace loop's gate needed 19s of a budget that only ever held 11s, so it never ran at all. Both shipped green because mocked probes consume no wall clock, so the budget never binds in a test. Two arithmetic tests now compute against realistic elapsed time, which is where the defect actually lived. The reservation was backwards anyway. Evidence can only raise 'unknown' to an uncounted 'occupied', and both now hold the daemon, so the read changes a log line and nothing else — while starving the one probe whose counted answer still reaches preserveDaemon() and full daemon mode. It is opportunistic now: if the probes spent the clock, it is skipped and the verdict stays 'unknown', which holds exactly as an evidence-raised 'occupied' would have. Recovery was a one-way flip on a two-way condition. Once a health check promoted fresh spawns back to the daemon, nothing ever demoted them, so a daemon that wedged again cost a hello timeout plus a full launcher re-classification for every new terminal, for the rest of the session. A failed spawn now routes back and re-arms the cooldown. The class had no tests at all; it has six. The notice was wrong twice. It claimed terminals already open keep working — in held mode discovery runs over the same IPC the daemon is failing, so its sessions are never routed and attach refuses rather than answering on its behalf. They are running, but unreachable. And it named half the cost of Restart: runRestartDaemon shuts down the local fallback sessions too, so the terminals it had just called safe die as well. Also fixed: the amber-on-amber body text failed AA at 3.94:1, the keys were in a namespace no sibling uses, and the scale did not match the notice it renders beside. The banner armed a destructive button with state that never refreshed. It now refetches on focus, like the sibling notice that solved this first. Also: the launch mode type in the test harness omitted 'held', so no test could describe the launch the hold produces; held mode's routing through the degraded provider was unpinned, and deleting it left every test green; and pty:signal kept a try/catch for a synchronous throw that async routing cannot produce. * fix(daemon): stop offering a remedy that cannot work, and say why two modules stay The degraded warning told the user to restart the daemon. When something other than an Orca daemon holds the endpoint, restarting clears nothing: killStaleDaemon only kills a process whose identity matches the pid record, and a foreign holder matches none, so the next launch is identical. The message now says the daemon is unreachable rather than asserting what it owns, and names the second remedy. The notice says "usually clears this" for the same reason. That case is also now written down as a known residual: an endpoint that accepts connections but never speaks the protocol reads as an incumbent on every launch, so it stays degraded with no auto-recovery, where before it was replaced. The rest is comments, because three separate deletion proposals landed on this code in one review cycle and each was a regression. The evidence read is not redundant with the unknown hold: the occupied branch has no proven-dead check and the unknown hold does, so it is the only thing between a kill and a daemon whose socket entry vanished while it still hosts agents. Its children scan is not redundant with pid verification either — a verified-live pid alone would also hold a childless daemon, which is the one #8689 case still safe to replace. And grace retries are worth more since 'unknown' stopped killing, not less: a counted 'occupied' reaches full adoption where the alternative is a degraded hold. Each now says which case dies if it is removed. Reviewers reaching for the delete key three times in a row is the code failing to explain itself, not excess. * docs(daemon): record what a budget raise would owe before it is safe The classification budget serves two verdicts with opposite time-costs. Reaching "don't kill" slowly is free — the daemon survives however long it took. Reaching 'empty' slowly is not, because the kill ladder and the fork still have to fit before the fail-open. At 34s that case cannot arise; at 44s it can, and an overrun there is the worst branch on offer: daemon killed, replacement forked then discarded, no provider installed, Restart broken. So the raise is not a number change, it is a number change plus a guard: hold rather than replace when the headroom left cannot fund the ladder and the fork. Safe precisely because that path has proven the daemon empty, so holding costs no agents. Written down next to the warning against tuning the budget, because the next person to want a bigger number will read that warning and need this one. Also recorded: the launcher closure has no access to the startup abort signal, so the cheap version of that guard is not available without threading it through the spawner. * fix(daemon): delete a retry loop that could never run, at any budget Round twelve proved the loop unreachable by algebra rather than by tracing: remaining = B - E - max(CONNECT, (B - E) - REQUEST) = REQUEST, whenever B - E > CONNECT + REQUEST The patient connect takes every millisecond the answer does not need, so what survives it is always exactly OCCUPANCY_REQUEST_BUDGET_MS — and the gate wanted CONNECT + REQUEST. That holds for every ceiling, which also settles the raise I had been holding open: at 44s the remainder is still exactly the request budget, so ten more seconds of worst-case startup would have funded zero retries. Funding one honestly needs ~71s against a 60s fail-open. So WEDGED_DAEMON_GRACE_RETRIES = 11 documented patience the launcher did not have, and no number could give it. Deleted, with the derivation left where the loop was so the next person does not re-derive it from scratch. Little is lost. A 4s retry cannot reach a daemon needing longer than 4s to answer, which is the entire wedge population, while the one patient ask waits ~12s. The only case retries caught and this does not is a daemon recovering within seconds of being asked — and DegradedDaemonFreshSpawnRouter.recover() already returns it to full daemon service on the next spawn, off the startup clock. The budget tests could not have caught any of this: they recompute the expression from imported constants and never execute the launcher, so collapsing the patient connect back to the cheap constant — the round-eleven defect exactly — left all 1475 green. There is now a test that watches the launcher spend it, verified by mutation, and the arithmetic ones say plainly that they are not the guard. Also corrected: the evidence-read comment claimed the read only affects a log line. It decides the verdict wherever the unknown hold declines to — it has neither the proven-dead check nor the rejected check — so it is what holds a daemon whose socket vanished, and what holds a hello-rejected daemon still hosting agents. * docs(daemon): cost the deferred guard honestly, and say why it is unreachable Two corrections to the note, both of which change what it tells the next person. The reason the guard's case cannot arise at 34s is structural, not a lucky margin: an `empty` verdict means the daemon answered, so it resolved fast by construction, and proven-dead means nothing is listening, so the probe and the ladder both short-circuit. The path that actually spends the budget is the wedge that never answers — and that one now ends in a hold, paying neither the ladder nor the fork. Long path and expensive tail are disjoint. Raising the budget is precisely what re-couples them, by extending how late an `empty` may arrive. And the guard was costed as a signature change through DaemonSpawner, which is wrong. createOutOfProcessLauncher is a factory called where `signal` is already in scope; a third parameter closed over there leaves the launcher's call signature untouched. Overstating the price invites skipping the guard rather than paying it. Also recorded: two terms this budget does not bound at all — the healthy branch, which never consults the clock and still ends in a cleanup and a fork, and the unbounded daemon-host copy on packaged Windows. * docs(daemon): correct an overstated claim about the deleted retry loop The deletion was justified as "the loop could never run, at any budget." That is true of three wedge shapes and false of a fourth: a connect that fails fast leaves the budget nearly whole, and while refused and missing endpoints are caught by the proven-dead guard, the EPERM/EMFILE class reads 'unknown' and would have passed the gate. The deletion still stands — retrying an fd-exhausted or permission-denied connect fails identically the second time, and recover() restores full daemon service on the next spawn once the condition clears — but a comment that overstates its own reach is how the next person concludes the reasoning was never checked. * test(daemon): restore two guards a range deletion swallowed Deleting the obsolete grace-loop test took out the two tests either side of it — the ones pinning that the hold declines a proven-dead endpoint and a rejected daemon. Both exclusions went unpinned in the same commit that removed the loop, and the suite stayed green, because nothing else covers either path. Found by mutation rather than by reading: removing `health !== 'rejected'` from the hold left all 1472 passing. The pre-existing rejected test does not cover it — its second client answers listSessions, so occupancy resolves to 'empty' and the replace path is reached without the exclusion ever being consulted. The restored test keeps the daemon unreachable so the verdict stays 'unknown', which is the only state where the exclusion decides anything. Also pins the evidence gate, the other survivor: the threshold must cover an identity ps plus two ownership probes, or a read started at the last moment the gate allows finishes past the ceiling the kill ladder and fork are sized against. Mutation results now: patient connect collapsed -> caught; evidence gate -> caught; hold removed -> caught; proven-dead exclusion -> caught; rejected exclusion -> caught; fresh-spawn revert -> caught. * fix(settings): make the degraded copy the copy users actually see Two user-facing fixes were no-ops. translate() resolves from en.json, and the catalog only ever gained the string it was first synced with — the sync script adds missing keys and never updates changed defaults, which the extraction gate reports as "inline defaults differ" and then passes anyway. So editing the inline default changed the source and nothing else. Caught by rendering the component and reading what came out, not by reading the diff. What was stale in the catalog, and is now corrected there: The notice promised the panes reconnect on their own once the host recovers. They do not. TerminalErrorToast already tells the user "Reopen this pane to retry", because nothing re-attaches a pane whose owner could not be verified — the session is left untouched, which is the point, but recovery is a user action. Third claim of mine in this PR that was stronger than the code. And "Restarting the host clears this" still overstated the foreign-endpoint case, where killStaleDaemon matches no pid record and clears nothing. Also removes the components.settings.DaemonDegradedNotice.* namespace, left behind when the keys were renamed to the auto.* convention every sibling uses. It was dead weight carrying the oldest copy of all three strings. * docs(daemon): 'held' no longer means what its type said it meant The mode was introduced for a daemon that demonstrably owns live terminals and cannot answer a handshake. It is now also what an unclassifiable daemon gets, where the whole point is that we could not establish what it owns. A type whose comment asserts the one fact the branch could not determine is the same overclaim this PR has been correcting elsewhere. Also un-exports ENDPOINT_PROBE_TIMEOUT_MS: it was widened for a test that no longer references it, and nothing outside the module reads it. * fix(daemon): stop a lost spawn reply from shadowing a live agent `!mapped` was standing in for "this is a fresh spawn," and it is not the same question. The mapping is only recorded after a reply arrives, so a spawn that names a session and then loses its reply — the daemon created it, the answer timed out — is indistinguishable from a genuinely new one. Demoting there sent the retry to the fallback, which answers with a fresh local shell under the same id while the agent keeps running on the daemon. The pane binds to the shell; the agent is orphaned. That is the symptom this PR exists to remove, arriving through a door the PR opened itself. Reachability today looks nil — the only sessionId-bearing spawn in ipc/pty.ts carries attachOnly, which routes elsewhere — but the guard was unsound rather than merely unused, and "no caller does that yet" is not a property anyone maintains. Now an identified session pins to the provider that may already own it, and only an anonymous spawn moves the shared route. Anonymous spawns are what demotion was for: nothing can shadow them, and they are the ones paying a hello timeout plus a full re-classification per terminal. Found by GPT-5.6-Sol reviewing this file in isolation. Two tests added; reverting to the old guard fails one. * docs(daemon): name the three paths that can still kill a daemon Adversarial review found all three; none is a regression against the pre-hold behaviour, and none should be closed by weakening the evidence rules. 'unknown' plus a proven-dead endpoint still kills when process evidence cannot answer. The probe proves the directory entry is gone, not the process — a socket entry can vanish while the daemon still hosts agents. Evidence covers that on POSIX because it runs for any 'unknown' rather than only a live endpoint, so the gap is the blind cases: clock spent, pid unverifiable, ps unreadable. It is not reachable on Windows at all, where a named pipe vanishes with its process, so a dead endpoint there implies no agents to lose. 'unknown' plus 'rejected' still kills, and the reviewer is right that inability to adopt is not inability to preserve — those agents keep running, unreachable. Killing stays the choice because a daemon that can never be adopted and is never replaced leaves the app permanently degraded with no route back, but that is a judgement, not a proof, and it is now written as one. And the verdict is not atomic with the kill: an 'empty' answer can go stale if another instance creates a session first. Pre-existing, and narrowed rather than widened here — the window now opens only after the daemon has reported zero sessions itself. * docs(daemon): record the TOCTOU fix that was built, tested and reverted shutdownIfIdle is the right instrument and the daemon already implements it atomically: sole authenticated client, nothing in flight, zero sessions, listener closed before the acknowledgement. Asking it immediately before the kill closes the window that a re-read of listSessions can only move. It is not landing here. Gating every empty-verdict replacement on a new round trip means every failure of that round trip has to mean hold, which trades a rare race for a common failure mode and makes #8689 worse whenever the call is merely slow. It also flipped two endpoint-identity tests from rejecting to resolving, and an unexplained behaviour change is not something to merge at commit forty-two of a change whose whole subject is unintended consequences. Written down with the mechanism intact so the next person starts from a working design rather than rediscovering it. * fix(repro): restore the 91 lines a bad deletion took out of the repro Removing readSourceConstant matched a docblock far earlier in the file and deleted everything between, taking the imports and three functions with it. The script still parsed, still linted, and still passed `node --check` — it failed only when run, with `existsSync is not defined`, which is why it went unnoticed for two commits. The only end-to-end proof in this PR had been dead that whole time. Restored from before the deletion and the intended edit re-applied by itself. Now runs green: phase 1 kills a wedged daemon with real agents attached and confirms they die; phase 2 puts the identical wedge through the decision and shows the daemon unsignalled, both agents alive, and everything back with sessions intact on SIGCONT; phase 3 asserts the launcher holds — now including the unknown-hold, which is the branch this PR turns on. Lesson worth keeping: a syntax check is not a test. Running it is. * fix(daemon): stop the emptiness confirmation reading the same snapshot twice The second sample exists because one snapshot cannot tell a login(1) wrapper whose shell has not appeared yet from a wrapper whose shell has gone. But when the fresh read misses its deadline — the busy host this evidence exists to protect — both attempts fell through to the same TTL-cached table. Two agreeing samples, one observation, and the window being excluded is shorter than the cache. The confirming read is now denied the cached fallback. If it cannot get a fresh table it answers 'unknown', which holds. The first sample keeps the fallback, because there the cache protects the answer worth protecting: a stale table still shows that a daemon has children, and going blind there is what got them killed. Also records three limits of this evidence that review surfaced and that no code change should paper over — a reparented orphan outside the descendant tree, the Windows abstention, and an argv match that cannot establish executable identity. Each only fails to raise a verdict, so each costs a hold not taken rather than a kill licensed. * fix(daemon): stop discarding Linux terminals to solve a macOS problem The stranded-login(1) exclusion ran on every POSIX host. Orca only wraps terminals in login(1) for TCC attribution on macOS, so off darwin the pattern can only match a user's own login — and one still prompting for credentials has no child yet, which is precisely the shape the exclusion throws away. A Linux daemon hosting that terminal read as childless, and a childless daemon is one nothing protects from the endpoint-dead path. Now scoped to darwin, where the problem it solves lives. And a count that is not a count is no longer read as emptiness. `counted > 0` maps NaN, -1 and 1.5 to 'empty', which is the single verdict that licenses a kill; the listSessions dep is injectable, so reaching it never required asking a daemon anything. Non-integers and negatives now resolve to 'unknown'. Both mutation-verified. Noting for whoever runs the next mutation pass: the first attempt at the login mutation silently failed to apply because the pattern had been reflowed by the formatter, and a mutation that does not apply looks exactly like a test suite that caught it. Assert the pattern matched. * docs(daemon): bound what the degraded owner check actually covers Review confirmed the five destructive operations are guarded and that the error taxonomy holds — TerminalSessionOwnerUnverifiedError cannot be reclassified as a gone session anywhere in production, so no fake exit is ever synthesized from it. It also found six methods that still route raw, and they are worth naming rather than leaving for the next reader to rediscover: flow control, background state, buffer clear, startup authority and the per-session queries. For an unresolved daemon id those reach the fallback silently. None can destroy a session, which is why they are not being changed at this point in this branch, but a buffer clear that reports success while the daemon's history survives is a real lie. Recorded with the reason not to fix them casually: acknowledgeDataEvent is invoked directly from an ipcMain.on listener and setPtyBackgrounded from a synchronous callback, so a throwing owner check added there without changing the call sites turns a silent misroute into an escaping exception. * fix(daemon): restore the demotion my shadow fix made unreachable The review is right. Gating demotion on the absence of a sessionId assumed fresh spawns are anonymous, and they are not: every production fresh spawn mints an id before reaching the provider (ipc/pty.ts assigns spawnOptions.sessionId on all three paths). So the branch only ever ran in tests, and a daemon that recovered and wedged again kept every later terminal pointed at itself — each paying a hello timeout plus a full launcher re-classification, each failing anyway. That is the cost the demotion existed to remove, reintroduced while fixing something else. The mistake was treating one condition as two questions. Pinning protects THIS id, which the daemon may already have created before losing the reply, so a retry must never be answered locally under the same name. Demoting protects the NEXT terminal, which is a different session and cannot be shadowed by this one. They are independent, and both now happen. `attachOnly` is the honest discriminator for the second: an attach that names a session never reaches this router, so anything arriving here without it is a fresh terminal whatever id it carries. Both halves mutation-verified separately — restoring the sessionId guard fails three tests, dropping the pin fails two — including a test shaped like what ipc/pty.ts actually sends, which is what the old test suite never had. * fix(repro): stop the script doing the exact thing it exists to warn about Both findings are right, and the first is pointed: this script demonstrates that signalling a pid you have not re-verified can kill someone else's work, and its own teardown did that twice. The staged daemon is killed on purpose in phase 1. Once Node reaps that child its pid is free for reuse, and teardown signalled the remembered number anyway; it now signals only while the child object still reports no exit. The markers were half-verified. Each proves its own identity by tag before being signalled, but its session leader was killed on a number remembered from staging a minute earlier — and the leader is the one pid here that can be recycled while its child lives on under a new parent. The leader is now re-read from the live marker and signalled only when the marker still claims it. Second finding: isRealUserDaemon matched a hardcoded macOS userData path, so on Linux a real daemon could never be recognised — the assertion that this run harmed nothing was inert on the platform where nobody would notice. Now matched per platform, with a loose fallback rather than a silent false. Repro re-run end to end: all three phases pass, pre-existing daemons still running, real userData daemon untouched. * fix(daemon): only demote and only pin when the failure earns it Both guards in the fresh-spawn catch were too broad, and narrowing them is the one thing worth keeping from the restart-ownership branch. Demotion fired on any spawn failure. A rejected cwd or a bad profile says nothing about whether the daemon is reachable, and costing the whole session its daemon persistence over one of those degrades terminals the daemon would have served fine. It now requires the failure to look like an unreachable daemon. Pinning fired on any failure too. The pin exists for a request that was sent and whose answer was lost — that is the only shape that can hide a session the daemon already created. A failure that never reached it created nothing, so pinning that id would strand later attempts on a host holding nothing of theirs. It now requires an error that could have been dispatched. The distinction is sharper than the code it replaces: a hello timeout demotes but does not pin, because a handshake that never completed cannot have created a session. The old code pinned it anyway. Test doubles now raise DaemonProtocolError rather than plain Errors, which is what the client actually produces and what these predicates are written against. Both narrowings mutation-verified. * test(daemon): prove the recovery the degraded notice promises The readiness review flagged one claim it could neither confirm nor refute: the notice tells the user "reopening a pane retries, and works once it does", and nothing pinned that. It mattered because held mode is exactly the case where no route was ever recorded — discovery ran over the same IPC the daemon was failing — so recovery cannot come from a cached route. It has to come from the next attach re-inventorying a provider whose failure cooldown has expired. It does. While wedged the resolver refuses rather than letting the fallback answer with a fresh shell, and once the daemon answers again the same attach reattaches the original session. Verified by mutation: with the daemon left wedged, the test fails. Fourth user-facing claim in this branch checked against the code rather than assumed. The previous three were wrong. --------- Co-authored-by: Orca <help@stably.ai>	2026-08-13 02:12:20 -07:00
NeilandOrca	3ab8b6a117	fix(ssh): stop SSH reconnect from multiplying terminals and resuming agents twice (STA-3077) (#13326) ... * fix(ssh): stop reconnect from grafting panes and stacking remote leases Reconnecting an SSH-backed workspace added terminal panes the user never opened, and the remote host accumulated shells nobody was using — one report went from 2 to 19 to 20 relay PTYs across three reconnects (STA-3077). Two root causes, both in the store. Reattach could create UI. `persistPtyBinding` has four creating branches — mint a tab, mint a root leaf, split the root and graft a leaf, mint a layout. All four are load-bearing for `pty:spawn`, which can beat the renderer's debounced layout writer, but none of them is appropriate on reattach, where the pane either already exists or is gone for good. Add `mayCreate`, defaulting true so the spawn path is untouched; every creating branch already sets `terminalMembershipChanged`, so refusing is a check rather than a new code path. Lease identity had no pane key. `upsertSshRemotePtyLease` matched on `(targetId, ptyId)` alone, so a pane that re-leased under a new relay id left its predecessor live with nothing to retire it, and the next reattach fanned out over both. One pane now keeps at most one live lease. Superseded leases are marked `expired` rather than terminated: losing a lease is not proof the shell died, so the remote process is deliberately left running. Tests assert observable behavior rather than mechanism, so they stay valid under any implementation that fixes this. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record the terminal session behavior contract Properties stated as observable behavior rather than mechanism, so an oracle written against them survives a change of implementation. Records the weaker, correct form of the timer rule — a timer may never be the sole cause of a destructive action — because recovery budgets and scratch-file age gates are correct code that an absolute ban would condemn. Also notes which mechanisms are deliberately not required, so each has to earn its place rather than arrive with an architecture. Co-authored-by: Orca <help@stably.ai> * fix(ssh): heal duplicate pane leases that predate pane-keyed supersession Pane-keyed supersession stops new duplicates, but it does nothing for installs that already carry the ones STA-3077 accumulated — the report behind this reached 20 live leases across a handful of panes, and every reconnect fanned out over all of them. Retire the stale duplicates once per reattach pass, keeping the newest lease for each pane under a total order so two hosts resolve a tie the same way. As with supersession, retired leases are marked `expired` rather than terminated: their remote shells are deliberately left running, because a lease we chose not to revive is not evidence the shell died. The relay-session store stubs gain the new method. Note the gap this leaves open: those shells keep running and are no longer reachable from the app, so the "accumulates unused shells" half of the report needs a visible recovery surface rather than a silent kill. Co-authored-by: Orca <help@stably.ai> * fix(terminal): stop respawning a shell that is still running A pane that failed to reattach spawned a fresh shell. Because the restored session id came along, the replacement resumed the same agent session, and two processes appended to one transcript — reported repeatedly, up to five concurrent resumes of a single session. Two defects fed it. The relay reported a source that merely needed re-establishing as `SSH_SESSION_EXPIRED`. The shell was still running; only its output source was gone. Give that outcome its own error so it stops reading as "the session no longer exists". The reattach failure handler then treated every error as proof of death. It checked for expiry and, in the else branch, took the identical action — so the check bought nothing and a transport fault, a timed-out call, or a wedged relay all respawned. Respawn now requires proof: an explicit host expiry or a not-found PTY. Anything else, including an error we have never seen before, is unresolved, leaves the shell running, and keeps the binding for a later reattach. Two existing tests asserted the old behavior. One threw a bare error as scaffolding to reach the spawn-adoption door; it now throws proof, which is what it meant. The other pinned the expiry mapping itself, and now asserts the outcome fails closed *without* being reported as expiry. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record what makes a retention bound safe Shortening a grace period is the wrong lever. Measuring process time and gating reclamation on an independent observation are what make one safe, and they are what deployed systems actually do. Also records that lifecycle belongs in the attach reply rather than a delivered event — that is what removes the need for a durable per-consumer cursor to guarantee an exit is never lost. Co-authored-by: Orca <help@stably.ai> * test(terminal): assert the empty-failure case without an empty Error A thrown empty value exercises the same property — a failure carrying no usable message is not proof the session is gone — and does not trip the empty-error-message lint. Co-authored-by: Orca <help@stably.ai> * fix(ssh): let the durable pane binding outrank recency when retiring leases Choosing the newest lease for a pane is wrong whenever a newer lease exists that no pane is bound to: it retires the lease the pane is actually attached to, detaching a live terminal instead of healing it. Two changes. Arbitration now prefers the lease matching the pane's durable binding, across both the SSH-target and local partitions, falling back to recency only when no binding names either candidate. And supersession at upsert time now defers rather than expiring a bound predecessor. When a lease arrives for a pane that is still bound to a different PTY, the binding has not caught up yet, so both stay live and reattach arbitrates once the binding is available. Co-authored-by: Orca <help@stably.ai> * fix(ssh): roll back a lease retirement whose durable write fails `flush()` logs and swallows write errors, so a failed write left these leases retired in memory while disk still called them attached — and the pane bindings scrubbed alongside them stayed scrubbed. Use `flushOrThrow` and restore both the lease states and the affected session partitions when it throws, reporting nothing retired. Co-authored-by: Orca <help@stably.ai> * test(ssh): prove pane and remote PTY cardinality across reconnects Counts the shells the relay actually hosts, on the container, rather than inferring them from app state — that is the census the report was based on. Asserts the PIDs are unchanged, not merely the count, so a kill-and-respawn cannot pass. Every pane streams before the transport is severed: an idle pane sends no recovery checkpoint, so only a live source comes back needing re-establishment, which is the outcome that used to read as expiry. Co-authored-by: Orca <help@stably.ai> * fix(ssh): actually pass mayCreate:false from the reattach binding write The `mayCreate` guard was correct and had no production caller, so the reattach path still went through the creating branches and grafted panes back. `restoreReattachedPtyRuntime` is that call site — RC3 in the original diagnosis — and it now refuses to create. Binding moves ahead of runtime registration, because registering first would surface a pane the user never opened before the refusal landed. A refusal leaves the remote shell running and reattachable; a *thrown* write stays unknown and still registers, so a failed disk write cannot detach a live pane. Adds an oracle over the call site itself. The store-level tests all passed while the fix was inert, because they called the store directly — only pinning the wiring catches that. Co-authored-by: Orca <help@stably.ai> * fix(terminal): apply the respawn-requires-proof rule to both reattach paths connectPanePty has two near-verbatim reattach blocks — one keyed on the deferred SSH session, one on the restored session — and only the second was fixed. The first still checked for expiry and then respawned unconditionally anyway, so a transport fault there resumed the same agent session a second time. Also keep the wire token out of the pane. The main-process bridge only special-cases expiry, so a source-restore failure crossed IPC as raw `SSH_SOURCE_RESTORE_REQUIRED: <id>` text and surfaced to the user. It correctly does not respawn; it just should not read like that. Co-authored-by: Orca <help@stably.ai> * test(ssh): state plainly that the reconnect spec is a forward guard It was run against an unfixed tree and passed, so it does not prove the STA-3077 fixes and should not be read as if it does. A clean severed transport does not reproduce the field conditions — accumulated duplicate leases, or a source returning needing re-establishment. It keeps its place as a forward guard: it counts the shells the relay actually hosts and pins their PIDs, so a later change that grafts a pane or respawns a shell fails here. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record that a guard must be pinned at its call site A refusal that exists and is never passed is indistinguishable from no refusal, and store-level tests cannot tell the difference — they call the store directly. Learned from `mayCreate`, which was correct and had no production caller for several commits. Co-authored-by: Orca <help@stably.ai> * fix(ssh): park one PTY's exhausted delivery recovery instead of dropping the channel A per-PTY recovery budget running out disposed the whole relay channel, so one PTY that could not re-prove its delivery aborted every in-flight filesystem and git request on that host and stalled every sibling pane. A retry count is not proof of anything, and it certainly is not proof about the other sessions sharing the channel. Exhaustion now parks that PTY's delivery. The remote shell keeps running, its lease stands, and the next relay open reattaches it with a fresh delivery generation — the parked state is cleared on teardown and the generation changes on reconnect, so a reconnect recovers it. The consecutive-attempt ceiling goes away entirely; the per-generation one is what bounds the retry cost, and the second ceiling only existed to reach the channel drop sooner. Tradeoff worth stating: the failing pane used to self-heal within seconds because the forced reconnect wiped all rejection state, and it now stays frozen until the next relay open. That is a worse outcome for that one pane and a much better one for every other session on the host, and reconnecting is user-reachable. Co-authored-by: Orca <help@stably.ai> * fix(pty): let liveness say unknown instead of forcing it to say dead `IPtyProvider.hasPty` returned a boolean, so a provider whose inventory was empty for reasons that have nothing to do with the session — socket down, cache never hydrated, provider generation just constructed — had no way to say so and answered "absent". Its own siblings already knew better: `probePtyLiveness` and the runtime's `PtyController.hasPty` were both already `boolean | null`, with consumers branching on null correctly. The lie was injected at exactly one interface. Now three-valued, and each provider answers unknown where it cannot prove absence: the daemon adapter off-socket, the SSH provider before a completed listing, the router when any adapter cannot answer, and the degraded provider rather than fabricating a verdict. `terminal_gone` requires unanimous proven absence. Also fixes a real cold-start bug this surfaced: `pty:hasPty` never awaited the daemon-swap startup promise, though the sibling `probePtyLiveness` bridge already did, so before the swap the local provider answered an authoritative false for every daemon-owned id. Net +27 production lines. The plan behind this predicted -92 on the strength of deleting the renderer's dead-session reconcile path; that code is live (`pty-connection.ts` imports it), so nothing was deleted. Expressing a third value where there were two costs lines, and a deletion that is not real is not worth manufacturing. Co-authored-by: Orca <help@stably.ai> * docs(terminal): track the terminal-session correctness handoff package The package was untracked under a gitignored `docs/**`, with the un-ignore rules living only in an uncommitted .gitignore edit — a single `git clean -xdf` would have destroyed the authoritative plan. The 814-path construction snapshot is now pushed as `nwparker/react185-authority-snapshot` too; it had no remote ref. Co-authored-by: Orca <help@stably.ai> * test(ssh): make the reconnect settle window actually wait The settle poll reused a matcher the assertion 15 lines above had already satisfied, and Playwright's poll engine probes immediately and returns as soon as the matcher passes — so it observed the same state twice and elapsed 0ms. A shell grafted a second or two after reattach reported ready slipped through into the next cycle. Reviewer was right on #13111. Test-only; no production change. Co-authored-by: Orca <help@stably.ai> * test(ssh): census both durable session partitions on reconnect Adds a second reconnect scenario and a helper that reads pane records from the local partition as well as the ssh host partition. That split matters: the reattach binding call passes no hostId, so a grafted pane lands in the LOCAL partition and an oracle reading only the host partition passes whether or not the guard is present. Both tests remain forward guards. The second one was reported as discriminating and did not reproduce: with `mayCreate: false` removed from the call site and the app rebuilt, both still passed. Its induction races `pty:kill` against a severed transport, so when the kill lands the lease is cleaned up and there is nothing left to graft. The handoff README is corrected to say so rather than claim a journey. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record the user decision relaxing G6 G6 becomes minimise-and-justify rather than strictly net-negative. The deletion budget the plan assumed does not exist: an entrypoint-rooted import graph found 51 of 53 candidate files reachable and instantiated on live paths, leaving 263 deletable LOC against roughly +1,021 to offset. Correctness may still not be traded for line count. Co-authored-by: Orca <help@stably.ai> * test(terminal): add discriminating oracles for restart, daemon, skew and namespaces Six parallel streams, each required to fail with its guard removed rather than merely pass. Local restart proves the OS process itself survives, by reading `ps -o lstart=` for the shell's own pid. That matters: with the quit path made destructive, the tab, leaf and pty ids all came back byte-identical while the shell underneath was a new process — every existing restart spec would have stayed green. Two separate guards were removed to redden it, and the second reddens only the stale-operation case. Daemon restart discriminates by reverting three-valued `hasPty`; version skew now covers publication semantics and confirms the new `SSH_SOURCE_RESTORE_REQUIRED` token mutates nothing on an old client; two-host isolation censuses both containers. Deletes `src/relay/pty-source-replay-index.ts` — 201 production lines with no importer outside its own test, verified against an entrypoint-rooted import graph rather than a name grep. Five namespace tests are skipped, not passing: they reproduce a defect still live on main where folder-workspace ids compare equal with the instance suffix stripped. PR #12474 fixes it; they are its oracle. Co-authored-by: Orca <help@stably.ai> * test(ssh): induce the reattach graft deterministically instead of racing a kill The previous induction closed a pane while the transport was severed and relied on `pty:kill` FAILING so the lease outlived the pane record. It does not fail: with the provider already torn down, `pty:kill` takes its tombstone branch and marks the lease terminated, and `reattachKnownPtys` filters terminated leases out of the fan-out — so the reconnect never visited the PTY the test was about. It passed on both trees. Seed the precondition instead. Spawn a real remote PTY on a leaf that never becomes a pane, then roll the host partition back to its pre-spawn snapshot, leaving a live lease and a live remote shell that no durable pane owns. No failure races a success. Adds a vacuity guard that is independent of the tree under test: the lease's own `lastAttachedAt` must advance, proving the fan-out actually visited this lease before the pane census is trusted. Verified on this machine under an isolated TMPDIR, since the e2e harness keys its seeded-repo pointer on a machine-global tmpdir path: guard present passes, guard removed fails with the phantom leaf grafted into the local partition, guard restored passes. Co-authored-by: Orca <help@stably.ai> * docs(terminal): propose one authoritative binding identity Every defect this program has touched is the same defect: identity compared with the wrong key, or not compared at all. Lease keyed without the pane, reattach using a creating write, folder-workspace ids compared with the instance suffix stripped, local mutating IPC carrying only an id, a live shell classified as expired, liveness unable to say unknown. Proposal: one branded binding type built from fields that already exist and are already persisted, constructible only from an authoritative source, carried by mutating operations, compared by one shared function. Makes a wrong-key comparison a type error rather than the next incident. Under adversarial review, including against the open issue corpus. Not accepted. Co-authored-by: Orca <help@stably.ai> * fix(pty): refuse mutating operations aimed at a superseded PTY `pty:write`, `pty:writeAccepted` and `pty:resize` accepted any id. The renderer queues input, so a keystroke buffered before a reattach landed on whatever PTY had since taken the pane — and a resize reshaped the successor's shell. Main already tracks `ptyPaneKey` and `paneKeyPtyId` in lock-step, so their disagreement is proof the caller's id was superseded. No wire change, no renderer change, nothing added to the input payload. An id with no recorded pane stays permitted: unowned and orphaned PTYs are unknown, not stale, and unknown never authorizes refusing an explicit operation. That is also what keeps orphan cleanup working — those ids have no pane by construction. The tests pin the CALL SITES, not the predicate. A capability that exists and is never called is indistinguishable from no capability, which is exactly how `mayCreate` sat inert here for several commits with every test green. Co-authored-by: Orca <help@stably.ai> * fix(pty): fence signals at a superseded PTY, and pin why kill is exempt A signal means "interrupt my pane", so delivering one to a PTY the pane has already replaced is a misdirected interrupt. Fence it with the same lock-step proof used for write and resize. `pty:kill` stays deliberately unfenced and a test now pins that: a superseded PTY is orphaned, and reclaiming it is exactly what the orphan-cleanup callers ask for. Refusing there would break the operation that reclaims leaked shells — the opposite of the intent. The fence sits at the IPC boundary, above `tryGetProviderForPty`, so it covers local, daemon and SSH rather than the local path alone. Co-authored-by: Orca <help@stably.ai> * test(terminal): poll the pane binding read so a slower host cannot flake it `readPaneBinding` took a single unpolled read of a DOM dataset attribute immediately after a renderer reload, while its sibling helper polls the same data for 15s. On a native Linux host both tests failed every run with 'No bound terminal pane is mounted' while the app was demonstrably healthy — the screenshot showed the terminal restored with a live prompt and the boot PID echoed. The assertion is unchanged; it is only awaited. Nothing is weakened. Found by running this spec on native Linux rather than assuming macOS behaviour generalises. Co-authored-by: Orca <help@stably.ai> * test(terminal): make the restart identity spec run on Windows too Both probes were POSIX-only and unconditional: `echo ...=\$\$` for the shell's own pid, and `ps -o lstart=` for its start time. Running the spec on a real Windows host proved it dies before reaching either guard, so Journey 1's Windows half was unprovable rather than merely unproven. PowerShell exposes the same two facts as `$PID` and `Get-Process` StartTime. The start time still matters on both platforms for the same reason: a PID alone cannot separate a survivor from a reused number. Still green on macOS. The Windows path is written from the host probe and has not itself been executed end to end — that is the next thing to run there, not a claim being made here. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record the fence's real gap and what peer designs taught Marks the client-constructed binding proposal as rejected with the three false claims that sank it, and records what shipped instead. States the shipped fence's actual limitation rather than leaving it implied: it compares a binding, not an incarnation, so a respawn under a reused ptyId passes. The obvious remedy is wrong here — the agent-create id is deterministic by design so a replayed create stays idempotent, and randomising it would trade this narrow gap for a duplicate-spawn bug. Also records the ranked lessons from four comparable agent IDEs, chiefly that a typed end-reason at end time is what stops a user quit from looking like a resume candidate. Co-authored-by: Orca <help@stably.ai> * docs(terminal): promote Journey 1 to proven on all three platforms The oracle now runs natively on macOS, Linux and Windows, and its discrimination was watched on each: a mutation reddens it, a restore greens it. On Linux and Windows both mutations were run, and the second reddens only the stale-operation test — so the journey's two clauses are proved independently rather than jointly. Windows is the new evidence. The PowerShell branches added blind at ebffb85a848 executed correctly on their first run: `$PID` expanded to real integers, which also proves the pane shell there is PowerShell-family rather than Git Bash, and `Get-Process StartTime` returned kernel start times 5.4s apart — so a recycled pid could not have passed as a survivor. First journey promoted in this program. The other twelve are unchanged, and the residual limit on "every stale exact operation" is recorded rather than glossed. Co-authored-by: Orca <help@stably.ai> * test(terminal): add discriminating oracles for the daemon, skew and multi-host journeys Daemon: replaces a spec that modelled only a client restart and never crossed the daemon boundary, whose successor generation owned nothing so "the live successor is neither killed nor replaced" was vacuous. The PTY leader is now a real login shell reporting `$$` back through the production write path, resolved to a kernel start time. Two mutations each redden exactly one of the three clauses, on macOS and Linux: reverting three-valued `hasPty` reddens only the unknown-not-dead clause; widening the sole-provider fallback reddens only the stale generation clause. Skew: reverting the restore-required publication to expiry reddens 4 of 5 new tests while the legacy control stays green — the regression this branch fixed is now caught if reintroduced. Multi-host: restoring `mux.dispose('connection_lost')` reddens sibling isolation on one host. It does NOT redden across hosts, and that is recorded rather than glossed: a mux belongs to one relay session per target, so its dispose cannot cross a host boundary. Journey 4's cross-host clause rests on isolation-by-construction, not on a mutation. No production code changes. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record journey evidence that falls short of promotion Four journeys now have discriminating oracles but none meets its full stated scope, and each shortfall is named rather than rounded up. Journey 2 is one WSL run from promotion. Journey 12's tests are in-process, so they do not close the live-skew gap the original ledger named. Journey 4's cross-host clause cannot be proven by mutation at all — a mux is per target, so its dispose cannot cross hosts, and the cross-host test stayed green under the mutation that reddens siblings. Journey 13 measured one dimension of ten, on lifted predicates rather than through real IPC. Co-authored-by: Orca <help@stably.ai> * docs(terminal): promote Journey 2 to proven on macOS, Linux and physical WSL The oracle runs on every environment the journey names, and is clause-selective on all three: reverting three-valued `hasPty` reddens only the unknown-not-dead clause, and widening the sole-provider fallback reddens only the stale-generation clause. Selectivity in WSL was established rather than assumed. The spec runs serially, so a red first test reports the others as "did not run" — they were re-run alone under the same mutation and stayed green. Also records that an Orca WSL-mode terminal now starts on that host at all, which it could not before: the distro had no provisioned default Unix user, so every interactive launch blocked on first-run setup. One diagnosis from the WSL run is corrected here rather than repeated: the unrelated `local-pty-shell-ready` failure was attributed to bash 5.3.9, but macOS runs the same bash version and passes 67/67. The trigger is environmental to that distro, and the underlying defect is that the spec pins an absolute count of OSC markers it does not own. Co-authored-by: Orca <help@stably.ai> * docs(terminal): correct the WSL provider-suite diagnosis The WSL run blamed bash 5.3.9 for the unrelated `local-pty-shell-ready` failure. macOS runs the same bash version and passes 67/67, so the version is not the cause — the trigger is environmental to that distro, and the underlying defect is that the spec asserts an absolute count of OSC markers it does not own. Co-authored-by: Orca <help@stably.ai> * test(runtime): unskip the workspace-namespace oracles now their fix has merged These five reproduced a defect that was live on main: folder-workspace ids were compared with the instance suffix stripped, so two workspaces sharing a directory read as the same namespace. They were committed skipped, pointing at the PR that fixes it. That PR is merged, and they pass. Verified they still bite: restoring the suffix-stripping comparison reddens exactly these five and leaves the other four green. An oracle written before its fix, held skipped, and confirmed against the fix after the merge — rather than deleted and rewritten from the answer. Co-authored-by: Orca <help@stably.ai> * test(ssh): add MaxSessions, lazy-discovery and paired-skew oracles Three journeys attempted; none promoted, and the reasons are recorded in the ledger rather than rounded up. MaxSessions=1 against real OpenSSH, with the cap read back from `sshd -T` rather than assumed, and remote pids read on the container two independent ways that must agree, each carrying its kernel start time. Two disjoint mutations discriminate — one reddens only the reconnect clause, the other only the two restart clauses. But the disconnect clause is a forward guard: four separate guard removals left it green, so nothing shipped is load-bearing for it. Lazy discovery samples sshd's own accept log and live session census across a 22s window with the in-use host as a positive control. No mutation reddens its third clause alone — the real cross-host lease scoping is load-bearing, but removing it breaks the sibling host during setup, so the failure carries no clause information. The paired-runtime skew spec pairs two real processes at different versions and refuses to run rather than degrade into a same-version pairing that would look green and prove nothing. No production code changes. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record why the duplicate-resume fix was not built I recommended adding a typed end-reason so a user quit stops looking like a resume candidate, then went to implement it and stopped. `SleepingAgentSessionRecord` already carries three fields that each exist to stop something resuming that should not have — `origin`, `restoreOnTabOpenOnly`, and `automaticResumeBlockedBy` — each traceable to its own incident, consulted at 22 non-test sites. A fourth predicate, however well typed, is the fifth containment cycle. The designs without this bug do not have a better flag; they resume only on an explicit action, into a new terminal id, and make two agents in one terminal unrepresentable in the schema. The first of those is a product decision about whether automatic resume stays a feature, so it is the user's call rather than mine. Co-authored-by: Orca <help@stably.ai> * docs(terminal): reconcile G6 with the recorded decision and assess its clauses G6's body still demanded strictly-negative production LOC after the user relaxed it to minimise-and-justify, so the gate had two conflicting pass conditions and no single truth value. Its body now points at that decision. Assessed the remaining clauses against the branch rather than assuming. Two fail structurally: more than one identity comparison and mutation admission path still exist, and `terminal-input-quarantine.ts` is still reachable from two production files. Records why the quarantine is not subsumed by the superseded-PTY fence, which I had assumed and checked. The fence refuses writes aimed at a stale ptyId; the quarantine guards the user's next keystrokes landing on the successor under its current, correct id — a case the fence never sees. Removing it needs the recovery path to surface a different shell as unresolved, not a deletion. Co-authored-by: Orca <help@stably.ai> * docs(terminal): the input quarantine is load-bearing, not superseded G6 lists "no superseded quarantine remains reachable" and this module was assumed to be one. Disabling its single call site reproduces the hazard it exists for — `cho hi; rm -rf x` reaching the shell — so deleting it without a replacement re-opens command execution. The replacement was costed by building it rather than estimated: +26 production LOC to thread the incarnation, ~+33 complete, and the cross-remount state it needs outlives the destroyed pane so it becomes a module about the size of the one deleted. Floor is roughly +140 to delete 88, and it would add a second identity comparison to a gate already failing for having more than one. The decisive part is that the route is not uniformly available: remote runtime results carry no incarnation, old hosts cannot be made to publish one, and mixed versions are the normal state. A paired client reads unknown, which this program's own rule says is not proof — so either every remote reattach surfaces unresolved, or a fallback is needed and the only correct fallback is this module. Whether to amend the clause or accept something weaker on remote hosts is a user decision, so the clause verdict is left as failing rather than quietly reclassified. Co-authored-by: Orca <help@stably.ai> * refactor(runtime): collapse duplicate identity comparisons G6 requires one identity comparison; five implementations existed across two concepts. Worktree-namespace identity had two: `runtimeWorktreeIdsEqual` and `runtimeWorktreeIdentityKey` independently re-derived repoId plus normalized path. Equality now derives from the key, so the comparison and the sleep / mutation-queue keying cannot drift into two different rules — which is exactly how the suffix-stripping bug reached production once. Pane identity had three byte-identical leaf-UUID comparisons, in orchestration `db.ts`, `lifecycle-reconciliation.ts`, and `orchestration-legacy-process-identity.ts`. One copy moved to `stable-pane-id.ts`, which already owns `PaneKey`, `parsePaneKey` and `makePaneKey` and which all three already imported. No new module, no branded type, no parallel comparison. Net -14 production lines. The namespace oracle still bites: restoring the filesystem parser inside the identity key reddens exactly its five cases. The raw counts are not the actionable set, and the classification is worth recording: of 409 non-test `worktreeId` comparisons, 71 are typeof guards and 81 are sentinel tag checks. Most of the remainder are renderer predicates over store rows where both operands are the same main-minted id, so normalizing there would widen equality rather than correct it. Co-authored-by: Orca <help@stably.ai> * refactor(terminal): finish a half-done fixture move and audit the rest `xterm-bypass-event-fixture.ts` and `__fixtures__/xterm-bypass-event.ts` were byte-identical apart from an import path. The `__fixtures__` copy had zero importers and the live copy compiled as production — someone started the move and left both. Dead copy deleted, live one moved, its three test importers updated. Audited the wider G6 clause by importer rather than filename: 32 test-only files, roughly 3,300 LOC, currently compile as production; 4 of the 36 candidates have real production importers and are correctly placed. The list is recorded in the goalposts. Those 32 are almost all older than this program and outside the terminal surface, so sweeping them belongs in its own change rather than inside a terminal PR. The clause stays failing, with the remaining files named. Co-authored-by: Orca <help@stably.ai> * docs(terminal): the fixture clause already holds where it matters Checked what the build emits rather than reasoning from file paths. None of the 32 test-only fixtures appears in `out/` — Rollup drops them because no production entrypoint reaches them. On "compiles into the shipped product", this clause holds today. On the other reading it cannot be closed by moving files at all: both production tsconfigs use bare `include` globs with no `exclude`, so a `__tests__/` directory matches exactly like any other path, as does every `*.test.ts` in the repo. Relocating 32 fixtures would remove nothing from typecheck scope. A sweep was started and stopped once this was verified, rather than landing 32 moves across areas this program does not own for no gain. If the intent is that typecheck scope should exclude test code, that is a repo-wide tsconfig change with a different owner. Co-authored-by: Orca <help@stably.ai> * docs(terminal): add plain-language design and test overviews Two reviewable documents with diagrams, written so someone with no prior context can follow what breaks, why, and what changed. The design overview explains the five things stacked behind one terminal rectangle, the 2 -> 19 -> 20 report, the three root causes, and the rule underneath all of them: unknown is not dead. The test overview explains why a green test proves nothing on its own, the four-step mutation proof we adopted, and — the part worth reviewing hardest — an honest account of what could not be proven and why, including the properties that are true by construction and therefore have no guard to remove. Co-authored-by: Orca <help@stably.ai> * docs(terminal): add a self-contained visual report of the design and its evidence Pre-renders every diagram to inline SVG in both themes so the report opens offline and stays sharp when zoomed. States the gate/journey score and the retractions alongside the fixes, so the unproven half is as visible as the proven half. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record the finalized two-plane architecture decision Adopts the data-plane proposal and adds the control-plane track it does not cover: re-key ownership by pane, split orphan inventory out, then delete the compensating code. Records that the host-authority alternative was refuted and that the shipped keystroke fence is inert on the reattach path. Co-authored-by: Orca <help@stably.ai> * docs(terminal): add the design brief the review counsel works from Separates verified code facts from unverified leads so reviewers attack the design rather than a reconstruction of it, and records which simpler alternatives were already refuted and why. Co-authored-by: Orca <help@stably.ai> * docs(terminal): report the design counsel's outcome and the live respawn bug it found Three review rounds across two models replaced the two-record split with one leaf-keyed record, deleted attach-time pane identity, and made orphans a connect-time projection. Records that a shipped gesture still turns a healthy remote shell into a duplicate agent resume, and that the renderer classifier in that chain treats an error-message shape as proof of death. Co-authored-by: Orca <help@stably.ai> * docs(terminal): correct the report — the respawn proof gate guards a minority path A final review traced every auto-respawn route. The primary one converts the reattach failure into a boolean before any classifier sees it, so the shipped proof gate never runs there. Records that two of the six shipped changes are narrower than claimed, and why their tests could not have caught it. Co-authored-by: Orca <help@stably.ai> * docs(terminal): explain the landed design on its own terms One leaf-keyed ownership record, orphans computed at connect, and replacement shells only on positive proof — with the shipping order and the one product trade the design asks the owner to accept. Co-authored-by: Orca <help@stably.ai> * docs(terminal): rewrite the design explainer in plain English The first version assumed the reader knew the codebase. Reframed around two bugs, two fixes and one decision, with the jargon replaced by pane / program / note / helper and a five-word glossary for what could not be avoided. Co-authored-by: Orca <help@stably.ai> * fix(ssh): stop reading an identity mismatch as a dead shell The relay reports a pane-identity mismatch by saying the pty was not found, but it found it — comparing identity is how it noticed. Publishing that as expiry made the renderer clear the binding and cold-restore with agent resume, so a live shell gained a second agent on one transcript. Reachable today by detaching a pane into a new tab, which changes the tab the relay froze at spawn. Mismatch now carries its own token and the classifier refuses it as proof. Genuine absence still expires, so a shell that really went away is not stranded. The three failure tokens move to src/shared: main published them and the renderer decided respawn on them, from two copies that had drifted apart. Co-authored-by: Orca <help@stably.ai> * fix(ssh): stop sending pane identity on reattach The relay froze pane identity at spawn, so moving a pane to another tab made it refuse a live shell — and refuse by saying 'not found'. The comparison is presence-guarded, so not sending the fields disarms it on every relay version including ones already installed on hosts: no wire change, no redeploy. Nothing is lost. It existed to catch a relay restart recycling pty-N for a new shell, and in exactly that case pane and tab both still match, so it accepted the wrong shell anyway. The incarnation the attach returns is what distinguishes those, and it already crosses the wire. Removes the whole client-side apparatus: the expected-identity type, its per-lease derivation, its map, and the parameter threaded through four layers. Co-authored-by: Orca <help@stably.ai> * docs(terminal): add tracked goalposts for the new design Each goalpost is a behaviour with an oracle and the mutation that must redden it, so 'proven' cannot be claimed from a green test. Records the anti-inert rule as a first-class goalpost, since three guards in this program passed their tests while sitting off the route production takes. Co-authored-by: Orca <help@stably.ai> * docs(terminal): record that the recovery grant is dead code, deleting a design step The lease stores a relay-native pty id and the caller passes the app form, with a raw equality comparison between them, so the 30s grant cannot fire for a real SSH pane. The death rule that existed to referee it is deleted rather than built, and the dead path itself becomes a removal. Co-authored-by: Orca <help@stably.ai> * docs(terminal): keep the full design detail in the repo It only existed in an ephemeral job directory, so the plain-English explainer had no durable source for its specifics — record shape, death rule, reattach algorithm, migration order and the 25 oracles. Co-authored-by: Orca <help@stably.ai> * docs(terminal): add a resume prompt for a clean session Points at the goalposts as the contract, names the three goalposts whose oracles are already written and red, and carries the process rules that were learned the expensive way — prove guards reachable, verify mutations land, commit per step, and never let a subagent write production files in a shared worktree. Co-authored-by: Orca <help@stably.ai> * test(ssh): add the failing oracles for goalposts S3, S4 and S5 Intentionally RED: 14 clauses that fail against current behaviour and go green under the changes named in new-design-goalposts.md. The branch is held unmerged, so red here means unimplemented, not broken. Each was verified to fail for the right reason and to flip green under the identified fix, which was then reverted. Each pins the producer as well as the consumer, so no clause can pass vacuously if its route is ever severed — the failure mode that let three earlier guards ship inert. Co-authored-by: Orca <help@stably.ai> * fix(ssh): stop fabricating an exit when a reattach fails A failed attach never proves the shell exited. The relay answers not-found for a pane-identity mismatch and for any id it merely cannot hand back, so treating it as death sent the pane a synthetic `pty:exit { code: -1 }`, cleared provider state, deleted ownership and expired the lease — four claims about a process we know nothing about, on a shell that is usually still running. Collapse every failure into the non-destructive branch that already existed a few lines above (`restoreRequired = 'reattachAttemptsExhausted'` + wakeRecovery). A branch collapse, not a new mechanism: goalpost S3. Two tests pinned the deleted premise and are INVERTED rather than patched, so the new intent stays covered: - ssh-relay-orphan-abandon-paths: "retires the lease without a kill when the relay proves the PTY is gone" -> "leaves the shell running when the relay only reports the PTY as not found". Its comment claimed attach verifies liveness before answering not-found; it does not. - ssh-relay-session: "invalidates and broadcasts remote PTYs that cannot reattach" -> "leaves an unreattachable remote PTY alone while its sibling reattaches". Also repairs two clauses left red by c51be8072b (step A), which dropped the expected-identity parameter and the expectedIdentityByPtyId map. Mutation proof: restoring the destructive block reddens 6 of the 8 oracle clauses in ssh-relay-reattach-exit-proof.test.ts; the 2 producer pins stay green. Verified the mutation landed before believing the result. Net production: -21 lines. Co-authored-by: Orca <help@stably.ai> * fix(ssh): give an SSH pane binding one home An SSH pane's durable binding lived in two persisted partitions. Main's spawn wrote `ssh:<target>`; the relay's reattach write passed no hostId and landed in `local`; the renderer has always published SSH pane membership to `local` on purpose. So `durablyBoundPtyIdForPane` hedged ssh-first-then-local, read a partition no live writer maintained, saw the arriving lease disagree with a stale pty id, and bailed — supersession silently no-opped and both leases stayed live. That is the STA-3077 2 -> 19 -> 20 mechanism. `local` wins: it is the only publisher of pane membership and where `mayCreate:false` is evaluated. Every reader and writer now names it. - resolvePersistedStablePaneOwner / retirePersistedStablePaneOwner drop their connectionId parameter and read the default partition. - the CAS write and both spawn upserts drop the hostId argument (each was an if/else that collapses to one call). - durablyBoundPtyIdForPane stops hedging. - a one-time load fold moves any legacy `ssh:<target>` ptyIdsByLeafId into `local`, preferring `local` on conflict, sequenced after the leaf remap so every folded binding keys on a UUID. Side effect worth naming: the renderer never hydrated the `ssh:*` partition (listKnownRuntimeHostIds filters to `runtime:*`), so the Issue #217 force-quit binding protection had never worked for SSH panes. It does now. Mutation proof, run as a 2x2 because the two edits can mask each other: - fold disabled, reader local-only -> 1 clause reddens (the fold is live) - fold disabled, hedge restored -> 3 more redden (the reader is live) - fold enabled, hedge restored -> ALL GREEN That last row is why this commit adds an eighth clause: with the fold shipping, the fold erases the divergent copy at boot, so the reader guard would have shipped unproven — the exact failure mode G5 exists to catch. The new clause rewrites `ssh:<target>` mid-session (orphan adoption still writes there) and reddens when the hedge is restored, pinning the reader on its own. Five clauses in ipc/pty.test.ts pinned the two-partition shape and are INVERTED to the single home, each keeping an explicit arity check so a re-added partition argument fails loudly rather than silently. Net production: +9 lines (the fold is new state repair; the call sites shrank). Co-authored-by: Orca <help@stably.ai> * fix(ssh): bind a pane through one producer so the fence is live on reattach The superseded-PTY fence refuses a keystroke queued for a shell whose pane has since bound a different one. It reads `ptyPaneKey` disagreeing with `paneKeyPtyId` — and only spawn ever wrote those maps. Reattach bound the pane through `runtime.registerPty` instead, so the maps never learned the successor, `isSupersededPtyId` returned false by construction, and the fence was inert on the one path it was built for. Goalpost S5; a defect in already-shipped work. Collapse to one `bindPaneShell` producer that writes the durable record and the fence maps together. All three binding paths call it: the relay reattach and both spawn handlers. Error policy stays at the call sites because it genuinely differs — a caller that just created a shell must clean it up on a failed durable write, a caller that merely reattached must not detach anything. The paneKey is composed from the tab that holds the leaf *now*, resolved from the live layout, not from the tabId frozen in the lease. Only the leaf half of a pane key is remint-stable; `detachTerminalPaneToTab` moves a live pane and its PTY into a new tab, so a stored tabId names the tab the pane left. Mutation proof, both sub-guards isolated: - drop the `rememberPaneKeyForPty` call -> 3 clauses redden - prefer `args.tabId` over the live layout -> 1 clause reddens The second clause is new in this commit. Every pre-existing clause in the fence oracle used one tabId on both sides, so a producer that simply forwarded `lease.tabId` would have gone green and shipped the tab bug unnoticed. Two source-text clauses are STRENGTHENED, not relaxed. They previously required the relay to hold a `persistPtyBinding` call of its own and merely forbade an ssh-partition argument on it. The relay now has none, so they assert ZERO direct binding writes there plus a `bindPaneShell` call — a second bind producer is exactly the defect this removes. Also repairs a latent false green: the "persistence fails" case in ssh-relay-session-reconnect-incarnation was passing because a missing mock made the call throw a TypeError that happened to emit the console.error it asserted. The failure is now injected at the producer, so it is a real oracle for "a thrown durable write must not detach the PTY". Net production: +60 lines. This is the one step in the program that grows; the shrink arrives with S8's deletion. Reported rather than smoothed over. Co-authored-by: Orca <help@stably.ai> * feat(terminal): show an unreachable pane as disconnected with two actions Ships with S3. Collapsing the fabricated exit removed a lie, but it left the pane frozen: `restoreRequired` never crosses to the renderer, so a relay-driven reattach failure had no user-visible signal at all, and the renderer's own reattach arms showed a raw error toast with no way to act. An unproven failure now renders the pane as disconnected with exactly two explicit actions — "Try again" (remount against the same shell via requestTerminalPaneRecovery) and "Start a new terminal" (retire the binding, then spawn fresh). Nothing infers death and nothing auto-spawns; the user decides, because at that point no one knows whether the shell is alive. The two actions are the same two things the code already did, moved behind a click: the retry is the existing pane-recovery request, and "start a new terminal" is the existing clearExitedPanePtyLayoutBinding + clearTabPtyId + startFreshColdRestoreAgentResume sequence that used to run automatically on a "proven gone" error. No new IPC channel: the silent-respawn decision was always renderer-local. Copy constraint, enforced by an oracle rather than a review note: the banner may never assert the shell exited. STYLEGUIDE.md:236 already forbids result verbs without result data, and a failed attach is not result data. A test asserts the rendered text matches no death verb and shows no wire token. `TerminalRemoteRuntimeReconnectBanner` is renamed `TerminalPaneDisconnectedBanner` — it now serves any transport, and per AGENTS.md the name must say what it holds. Existing i18n key strings are kept verbatim so no shipped translation breaks; the SSH copy is additive (4 new en.json keys). `describeReattachFailure` is deleted with its last caller. Its two cases were not dropped: "keeps the wire token out of the pane" is re-asserted against the new copy, which is a stronger place for it. Renderer production (excluding the pure rename): +28 lines. * refactor(terminal): delete the SSH pane recovery grant, which could not fire For a disconnected pane, `recoverTerminalPane` consulted a recently-expired SSH lease and, on a match, spawned a replacement shell. It could never match: leases store a relay-native pty id (`pty-7`, normalized on every write) while the runtime registers the app-form id (`ssh:<conn>@@pty-7`), and the comparison was a raw `===`. The branch was also unreachable for a local pane, which has no SSH lease. Goalposts S6 and S8. A characterisation oracle lands FIRST and proves it, rather than assuming it: ssh-pane-recovery-grant-reachability.test.ts mints BOTH id forms from the production helpers — never as two hand-typed literals — so it tracks the real namespace split instead of restating it, and seeds a lease that qualifies on every other predicate (state, worktree, tab, leaf, grace window). Anti-vacuity assertions pin that control actually reaches the gate rather than bailing early. Mutation proof, run before the deletion: normalizing the comparison at the `lease.ptyId === ptyId` site makes the grant fire and reddens the oracle. That is the exact "fix" someone would reach for, so the oracle is pinned to unreachability rather than to the throw. Deleted: the grant tail, the `terminalPaneRecoveryByIdentity` dedup map (whose only consumer was the grant), and the dead `ptyId` parameter. NOT deleted, and worth naming because over-deleting here would break users: `getRecentExpiredSshLease` itself, `hasRecentExpiredSshLeasePane` and `SSH_PANE_RECOVERY_GRACE_MS` all stay. Their other two callers pass `ptyId` undefined, which short-circuits the broken comparison — those are live today and feed headless-mobile terminal-tab visibility. Also NOT done: deleting only the gate while keeping the spawn. That would have granted a respawn to every disconnected pane — a behaviour change in the dangerous direction. The refusal is what stays. Four tests pinned the grant. All were seeded through a helper that stores the lease id as the same literal it registers as the runtime pty, with a null connectionId — a shape production cannot mint. Three are INVERTED, keeping their scenarios; the fourth is now tautological and carries a comment saying so rather than being left silently hollow. The oracle's own counterfactual control is inverted by this deletion too, which is recorded in the file: its flip from grant to refusal is what "inert" means here. Honest limit, stated in the oracle rather than smoothed over: unreachable BY CONSTRUCTION for SSH panes; for a local pane, unreachable only up to a random UUID collision. Net production: -32 lines. * docs(terminal): record S3, S4, S5 and S8 proven, and G1 missed All seven step goalposts are now proven. G1 (net-negative production) is NOT met at +83 and is reported as a miss with a per-step breakdown rather than reframed. Also records the near-miss G5 caught: S4's reader guard showed no mutation response because the load fold had already erased the divergent state at boot. It was correct and would have shipped unproven. An added clause pins it. * fix(terminal): a reattach not-found is not proof the shell is gone Closes the last live route to the reported duplicate agent resume (RC2), found by the E2E harness rather than by reading: when a relay is stalled and replaced, the fresh relay has no memory of `pty-1` while the old shells keep running under its predecessor. It answers not-found, and the renderer read that as proof. A not-found means the relay WE ASKED cannot hand that id back. That proves an exit only if the relay process that minted the pty is the one answering. The design says exactly this (D3 row 2), and gates the grant on `relayInstanceId` equality — a field step E-2 never built. `SSH_SESSION_EXPIRED` is not independent evidence either: its ONLY producer is that same not-found mapping in reattachSshPtySession, and the token's own doc comment claimed "the host proved the session is gone", which it never did. So `isProvenSshSessionGoneError` returns false. Both reattach arms now always take the non-proof path and surface the pane as disconnected, which is what the owner approved in D1 — and what makes that affordance load-bearing rather than near-unreachable, since it was previously only reached by errors that were already rare. The respawn tails are deliberately NOT deleted. The design preserves the grant as a conditional for E-2, so the decision point stays and a clause pins that nothing reaches it meanwhile. This is the one place in the program where an unreachable branch is kept on purpose, and it is labelled as such. Tests: three clauses asserted a not-found proves death and are INVERTED, with the reasoning recorded. The #12101 cold-restore case reached the spawn door by throwing a not-found; that door is now opened by the user's "Start a new terminal", so the test drives that instead and keeps all four of its original assertions verbatim — strictly better coverage, since it now pins that the automatic respawn stopped AND that the door still works. Mutation proof: restoring the old predicate makes the new no-respawn clause fail with "expected connect to be called 1 times, but got 2", confirming it reddens on the real production route rather than passing vacuously. * test(ssh): add E2E oracles for pane cardinality and duplicate resume Both reported failures now have end-to-end coverage against a real Docker OpenSSH relay, gated on ORCA_E2E_SSH_DOCKER like the rest of the suite. - ssh-reconnect-pane-cardinality-across-partitions: three real reconnect cycles; after each, pane ids unchanged, exactly one live lease per leaf, exactly one remote shell per pane key, and exactly one pty id bound per leaf ACROSS BOTH durable partitions. Two partitions agreeing is tolerated; two naming different shells is the S4 divergence and fails. PASSES. - ssh-reattach-does-not-resume-agent-twice: the host itself records one line per shell launch via a .bashrc hook keyed by ORCA_PANE_KEY, so a duplicate resume is counted at the source rather than inferred. Fault is SIGSTOP on the detached relay. PASSES. - ssh-disconnected-pane-affordance: written whole but held as test.fixme. The banner needs the target CONNECTED while a single pane's attach fails, and both host-side faults drove the target out of connected instead. Held rather than deleted so it runs the day a seam exists; the reason is measured, not assumed. New helpers: docker-ssh-relay-stall (SIGSTOP/SIGCONT, reads the stop back off /proc so a fault that did not land cannot make an oracle vacuous), and remote-pane-launch-transcript. Note for whoever picks these up: a stalled relay leaves two detached relay groups on the host, and readDockerSshRelayProcessSnapshot throws on more than one, so call it before the fault. Writing these is what surfaced RC2 surviving S3 — fixed in 7cd7fef927. * fix(ssh): fold the pane incarnation with the binding it fences Found by adversarial review. `persistPtyBinding` writes the binding and its incarnation into the SAME partition, and the incarnation is what its CAS compares. Step P's load fold moved only `ptyIdsByLeafId`, so after upgrade a pane whose incarnation had been written to `ssh:<target>` kept the guard in the partition nothing reads: `resolvePersistedStablePaneOwner` read `undefined` from `local`, the CAS then compared undefined against undefined, and the incarnation half of the fence passed for any value until the next write healed it. Not data loss and not a wrong-shell bind — the ptyId half still held — but a guard silently weakened by a migration is the exact shape this program keeps finding, so it is closed rather than noted. Mutation proof: disabling the incarnation half of the fold reddens the new clause; the other eight stay green. One clause in persistence.test.ts asserted the incarnation survives a reload in the SSH partition. Its subject is that the reconciled value is preserved, not which partition holds it, so the assertion follows the binding to its one home and additionally pins that the ssh partition no longer keeps a copy. * docs(terminal): record the two defects found after the goalposts were met RC2 survived S3 and was found by writing the E2E test, not by reading. The load fold left the incarnation half of the pane fence behind and was found by adversarial review. Both were invisible to unit oracles that had already gone green, which is the useful part of the record. * fix(terminal): close four defects found by adversarial review Four reviewers over the diff, every finding put to an independent skeptic. Nine of twelve agents died on prompt length, so most findings arrived UNREFUTED rather than refuted — I checked those myself instead of counting them clean. Four were real. 1. "Start a new terminal" resumed the agent instead of starting a new one. The action passed the cold-restore startup, which carries the agent's providerSession. That was correct for the automatic respawn it replaced, because that only ran on PROOF the shell was gone. Behind this button the shell is probably still alive, so it put a second agent process on one transcript — the exact defect this pane exists to prevent, reintroduced by the fix for it. Now starts a genuinely fresh shell, which is also what the button says. 2. The banner was never retracted. The app-SSH transport publishes no recovery states, so nothing cleared the card: it sat over a live shell with armed buttons. Both actions now clear it before acting. 3. The load fold destroyed bindings it could not move. When a tab existed only in the ssh partition there was no local layout to fold into, and the code cleared the source anyway — deleting the only record of that binding. It now leaves such a tab alone: with no second home there is nothing to disagree with and nothing to fold. 4. The relay registered the pty under the lease's frozen tabId while bindPaneShell bound and fenced it under the live one, splitting a moved pane across two tabs and ensuring a mobile surface for the tab it left. bindPaneShell now returns the resolved tabId so both use one coordinate. Also repairs a reliability-gate manifest entry the banner rename broke. That would have been caught by the pre-commit lint gate, which I had been skipping with --no-verify; the full-repo sweep caught it instead. Mutation proofs, each verified to land before being believed: - restoring the resume reddens on `registerAgentLaunchConfig` and, with that clause disabled, on the spawned command being "codex '--dangerously-bypass-approvals-and-sandbox' 'resume' 'codex-session-1'" - disabling the fold's move reddens the ssh-only-tab clause - registering under lease.tabId reddens the moved-tab clause The first clause was VACUOUS on its first attempt and is recorded as such: the fixture had no resumable agent, and it asserted a field name the spawn path does not use. It now pins the fixture itself, so it fails loudly rather than going quiet again if `codex` stops being resumable. * fix(terminal): drop the remote-host assumption from the disconnected copy The banner said the shell 'may still be running on the host'. The reattach arm that publishes it is not SSH-only — a local or folder-workspace pane reaches it too, and there is no host to speak of there. The claim that matters is that the shell may still be running, which holds either way. * fix(terminal): close round-2 review findings, including one regression Round 2 ran narrow per-area scopes so agents stopped dying on context: 7 of 7 reported, versus 3 of 12 in round 1. Two findings survived refutation and both were real. 1. REGRESSION I INTRODUCED. `bindPaneShell` resolved the tab from the live layout for EVERY caller. That is right on reattach, where the lease's tabId is the frozen side — but backwards on spawn, where the caller's tabId is fresh truth and the persisted layout is the stale side inside the renderer's publish debounce. Breaking a pane out into a new tab and spawning into it in that window resolved back to the tab the pane had just left, writing the durable binding and the fence under one tab while the lease and the runtime registration used the other — the split-coordinate defect step F exists to remove, reintroduced on the spawn path. Live-layout resolution is now opt-in via `tabIdMayBeStale`, set only by the reattach bind. A clause pins that no spawn-side call sets it. 2. The fold moved every incarnation even for a binding it had deliberately left in place, splitting a pane's binding from the incarnation that fences it — the same defect 994733d8b1 closed, in the other direction. Incarnations now move only with the binding they belong to. The reload clause that had been inverted for the fold is restored to its original assertion, because an ssh-only pane now correctly keeps both halves together. Also closes a live route to the reported duplicate resume that my earlier fix missed. `isProvenSshSessionGoneError` covered the rejected-promise arms, but a reattach can also report expiry through the transport's error callback and then resolve falsy; those two branches still cleared ownership and cold-restore resumed the agent. A skeptic refuted this as pre-existing rather than caused by this branch, and that is correct on causation — but it is a live second route to the exact defect this work exists to remove, so leaving it would make the claim that duplicate resume is fixed false. Both branches now surface the disconnected pane. Five tests pinned that callback respawn. Two are INVERTED to the disconnected outcome; two keep their real subject (stale-callback fencing, delayed parked snapshot) and now reach a replacement shell through the banner's "Start a new terminal", which is the new production route; one — the cold-restore resume after expiry — is inverted to assert no resume command and no agent launch config, with a fixture pin so "no resume" cannot pass vacuously. * fix(terminal): close round-3 review findings on tab resolution and the fold Round 3, narrow scopes again: 9 of 9 agents reported. Two findings confirmed. 1. A thrown durable write lost the resolved live tab. `bindPaneShell` resolved the tab internally, so when `persistPtyBinding` threw, the relay's `bind` stayed null and it registered the pane in the runtime graph under the frozen lease tab — splitting the graph from the durable record it had just moved. Resolution is now an explicit `resolvePaneShellTabId` the relay calls BEFORE the write, so a throw cannot lose the answer. This also deletes the `tabIdMayBeStale` flag added a commit ago: the reattach resolves its own tab and passes a live one, and spawn callers simply pass theirs. The distinction is now carried by which caller resolves, not by a flag they must remember. 2. The fold could pair a binding with an incarnation that was never written alongside it. Where both partitions named a leaf, local won the binding but the incarnation was copied across independently — so local's pty could end up fenced by the superseded partition's incarnation. `persistPtyBinding`'s CAS compares both, so that pane's next legitimate update would be refused. An incarnation now moves only when the pty it belongs to is the one that ends up bound. My first attempt at this over-corrected and skipped the case where both partitions name the SAME pty — where the incarnation does belong with it. The existing clause caught that immediately, which is the fixture doing its job. Also hardens `findTerminalTabIdForLeaf`: it now requires the tab to still exist in `tabsByWorktree`. A layout entry outlives the tab it described, and binding a live shell to a deleted tab registers a pane under a ghost and can resurface it. The fence oracle's fixture gained the live tab it was missing, so that clause cannot pass by resolving nothing. New clause covers the divergent-pty case the reviewer named — the two partitions naming DIFFERENT ptys for one leaf, which is the divergence being migrated and was previously untested. * fix(terminal): check tab liveness without depending on a worktreeId match A reviewer asked, correctly, whether lease.worktreeId always matches the tabsByWorktree key exactly — including for a folder workspace, whose worktreeId carries a `::workspace:<uuid>` suffix and is matched by full-string equality. Rather than assert that invariant, this removes the dependency on it. Tab liveness is now checked across every worktree instead of under one key. A leaf id is a UUID, so there is nothing to disambiguate by worktree, and the resolver no longer has an answer that depends on two strings agreeing — which is exactly the class of full-string comparison that produced issue #12474 in this area. Had they diverged, resolution would have silently returned undefined and fallen back to the stale lease tab, quietly restoring the moved-pane bug for folder workspaces only. Failing open like that is worse than the check itself. * style(terminal): keep the membership authority under the max-lines limit My previous comment pushed the file to 301 lines. AGENTS.md forbids a max-lines disable or a per-file bump, so the comment is trimmed to the repo's concise standard and the liveness check folded into the existing condition. * fix(ssh): resolve every incarnation in the pass that clears its binding Round 4 confirmed one defect, in my own round-3 fix. The filter that stopped an incarnation following a LOSING binding also stopped it being deleted — while the binding itself was still cleared. So a conflicted leaf left the superseded incarnation behind with nothing to fence: durable fence state in a partition holding no binding, which is the one-home invariant this step exists to establish, broken by the code establishing it. The reviewer also named the test gap exactly: the clause I added asserted only that the value was not copied into local, never that it was gone from the partition it lost in. Both are asserted now. Incarnations are resolved in the same loop that clears the bindings, so no binding can be cleared without its fence being resolved. Three outcomes, by which pty ends up bound: - this binding moves (local had none) -> its incarnation moves and OVERWRITES any local value, because a local incarnation with no local binding is a leftover rather than a fence. That case previously synthesized a pair. - both name the same pty -> keep whichever fence local holds. - local wins with a different pty -> drop this incarnation with the binding it belonged to. The second and third outcomes were flagged by the same reviewer as real but attributable to my earlier commit rather than that one. They are the same defect class, so they are fixed here rather than filed. Two new clauses: the superseded incarnation is deleted, not merely uncopied; and a moving binding overwrites an orphaned local incarnation. * fix(ssh): never pair a moving binding with a fence that was not written for it Round 5 ran a mechanical ten-case matrix over the fold twice, independently. Both passes landed on the same primary defect, and it is one my previous fix created. Case 7: the ssh partition holds a binding with NO incarnation, and local holds a stale incarnation with no binding. The binding moves into local and inherits that leftover, producing (arriving pty, unrelated incarnation) — a pair no writer ever produced. persistPtyBinding's CAS compares both halves, so the pane's next legitimate update is refused. The previous fix only replaced local's leftover when the ssh side had an incarnation to replace it WITH; absent one, the leftover survived. A moving binding now takes the ssh fence whatever it is, including absent, in which case local's is deleted. Also fixes the bookkeeping both passes flagged: the function defaulted `workspaceSession` at the top, so a profile with no local session could be mutated on a path that then returns false — a mutation with no save scheduled. It now returns early instead: with no local session there is nothing to fold into, which is also the honest reading. Two findings are deliberately NOT fixed, recorded rather than silently dropped: - An ssh incarnation whose binding was already missing BEFORE the fold survives, because iteration is binding-driven. It is a pre-existing orphan isolated in a partition no reader consults for pane bindings, and reinterpreting it is not this migration's business. The comment claiming an incarnation never outlives its binding overclaimed and is corrected to say what the code does. - Two ssh partitions carrying the SAME tab and leaf resolve by object-key order. A tab belongs to one worktree on one host, so this is not a shape production writes; making it deterministic would mean inventing a precedence rule for a state that should not exist. New clause covers case 7 directly. The matrix cases both reviewers named as uncovered are now covered except the two above. * refactor(ssh): delete the pane-binding fold; its premise was false The migration moved legacy `ssh:<target>` pane bindings into `local` and cleared them, on the theory that the ssh partition was a stale spill of the desktop plane's state. Investigation of both hypotheses the team raised disproved that: - NOT cross-version compat. The introducing commit says it is for CONCURRENT multi-host. Nothing about the partition crosses the wire (zero references under src/main/runtime/rpc/), and the payload that does cross the SSH boundary — RemoteWorkspaceSnapshot — is projected from `local`. The only downgrade-compat comment protects `local`, the other direction. - NOT multi-client. PersistedState is one file on one machine; phones and CLI are RPC clients into that same process. Orca's real per-client state is `mobileClientTabSelectionsByDeviceId`, 13 lines above in the same struct, and it carries selections only — never a ptyId. What it actually is: the headless/CLI/mobile plane's OWN home, written and read deliberately across several tickets (STA-3463, STA-3465), with tests that assert that partition by name. So the fold was not tidying a spill — it was erasing another plane's live state. Measured symptom: a split SSH tab would disappear from mobile while its shell kept running. The desktop plane's fix never needed it. Supersession multiplied panes because `durablyBoundPtyIdForPane` hedged into the other plane's copy; reading `local` alone is the fix, and it stands without any migration. Deleting rather than redesigning, because the redesign had no target: five review rounds each found a defect in that function, three of them inside the previous round's fix, and every one was a cell of a merge matrix that only existed to serve a premise that was false. The `boundPtyIdsAcrossPartitions` clause is INVERTED, not dropped. It required the two partitions to AGREE after load — which encoded the false premise, and is what made a migration look necessary. It now asserts the narrower, stronger property: what the desktop plane resolves follows `local` alone, whatever the other plane holds. Also proven, and the reason unification was NOT attempted: worktreeId is `<repoId>::<path>` where repoId is a randomUUID minted client-side at repo add (orca-runtime.ts:18722), so two servers cannot collide on one. Host scoping was not protecting against that here — but the two planes' opposite choices are each deliberate and each test-pinned, so choosing a winner is an architecture call, not a cleanup. Net production: -75 lines. * fix(ssh): arbitrate on the pane, not the tab its lease was written in Correctness review round 1 on #13326: 5 raised, 2 confirmed, both real. 1. Arbitration looked the durable binding up under the lease's FROZEN tabId. `detachTerminalPaneToTab` moves a live pane and its PTY, and nothing re-keys a lease, so after a break-out the binding lives under the new tab and the lookup found nothing. The bound shell then lost to recency and supersession expired the pane's OWN lease; the follow-on scrub could not clean up either, because it matches lease.tabId against the layout's tabId. Reconnect skipped the expired-but-bound PTY and reattached the stale winner onto the pane. The leaf is the stable half of pane identity, so the lookup now prefers the named tab and falls back to wherever the leaf actually is. 2. Arbitration read the desktop plane only while the scrub reached into `ssh:<target>`, so a headless-plane pane was invisible to the ranking and then lost its live binding to it. Fixed at the reader, not the scrub: local FIRST, headless plane only as a fallback. That is NOT the STA-3077 hedge — that bug was preferring `ssh:<target>`, letting a copy no live writer maintains outvote the real binding. A fallback consulted only when local is silent gives a headless-owned pane a vote without ever outranking a live desktop binding. Proven by mutation: swapping the two back to ssh-first reddens 4 clauses, including the ten-reconnect cardinality one. Also closes two fulfilled-result routes to the duplicate agent resume that the earlier RC2 fix missed — `handleReattachResult` respawned on a result flagged `sessionExpired` and on a result carrying no pty id. A skeptic refuted both as pre-existing rather than PR-caused, which is correct on causation, but they are live routes to the defect this PR claims to fix. Scoped to SSH panes only. The first attempt diverted every pane and broke three daemon tests — correctly: a local provider is authoritative about its own ptys, so "cannot reattach" there is not the ambiguous evidence it is for a relay that may have been replaced. New clause covers both routes; disabling the diversion reddens it. 43,253 pass; the 7 failures are pre-existing on clean main in this environment. * fix(ssh): supersede on the leaf, so a moved pane retires its own predecessor Correctness round 2. This is the reported cardinality growth in its surviving form, and it is the sharpest finding of the review so far. Supersession matched sibling leases on `(worktreeId, tabId, leafId)` and bucketed duplicates under the same key. A lease freezes its tabId when written, and `detachTerminalPaneToTab` moves a live pane — so after a break-out the pane's next lease carries the NEW tab and its predecessor carries the old one. The two never match, the predecessor is never superseded, and the live count grows on every reconnect. Exactly the reported 2 -> 19 -> 20, for any pane that has been moved between tabs. Round 1 fixed the same frozen-tabId mistake at the binding LOOKUP. It did not fix it here, at the sibling match and the bucket key, which is why the bug survived a round. Both are now keyed on the leaf — the stable half of pane identity, per stable-pane-id.ts: the tab half changes on break-out. Two clauses cover it: a predecessor whose lease names the tab the pane left is superseded, and the live count stays flat across ten reconnects that each land in a new tab. Restoring `tabId` to either the match or the key reddens both. E2E re-run against a real Docker relay after the change: 2 passed. Full suite 43,255 pass; the 7 failures are pre-existing on clean main in this environment. * fix(ssh): a supersession decided from one plane only mutates that plane Correctness round 2 confirmed finding. Arbitration ranks leases using the desktop plane's binding, then handed its losers to a scrub that walked BOTH planes — so the headless/CLI/mobile plane's binding was deleted for a lease it never got to vote on. Its owner then has no durable record to reattach that shell by, and can fall back to recency or orphan a shell that is still running. `clearSshRemotePtyBindingsForLeases` now takes `arbitratedFrom`. A decision reached by reading one plane may only mutate that plane. An explicit expiry or termination is plane-agnostic — the pty is gone for everyone — so those callers pass nothing and still scrub both, which is what the existing `markSshRemotePtyLease` oracle pins. I initially assessed this as not-a-defect, reasoning that local winning IS the STA-3077 fix. That was about RANKING and did not justify DELETING the other plane's record; the round-2 verdict was right and I was wrong. It did also catch a comment of mine that had gone stale — a clause claimed the other plane was "deliberately left alone" while the code cleared it. The comment now says what the code does and why. Mutation: letting arbitration scrub both planes again reddens the new clause. 43,256 pass; the 7 failures are pre-existing on clean main in this environment. * fix(terminal): put the unreachable-pane guards in one place Correctness round 3. The leaf-keying from round 2 came back clean, twice and independently. But the renderer produced findings for a third consecutive round, and they were all one shape: `publishUnreachablePane` is called from seven sites, each needing the same guards, and a different one was missing at each. So this stops patching sites and moves the guards into the publisher: - `disposed` — a late rejection republished a card for a numeric pane id that had already been reused, giving a fresh pane a phantom card whose actions closed over a dead session. - `connectionId` — the deferred catch is not SSH-only. A local/daemon pane could be shown an SSH ambiguity card it can never clear, and would loop: retry remounts, reattach rejects, card returns. Its provider is authoritative about its own ptys, which is exactly why the two branches in handleReattachResult already had this guard — and why the catch needed it too. Two more real defects in the banner's own actions: - "Start a new terminal" passed `null` to suppress the saved agent startup, but connect FALLS BACK to the startup its transport was constructed with whenever a per-call field is absent (pty-transport.ts). So the "fresh" shell could resume the same provider session — the duplicate transcript this pane exists to prevent, for the third time in this button. `suppressSavedStartup` makes the suppression explicit; `??` means passing null could never have worked. - It also cleared both durable bindings BEFORE the spawn, and discarded the promise. A spawn that resolves null left the pane blank, unbound, and with no way back to a shell that may still be running. Bindings are now cleared only once a replacement actually starts, and the card returns if it does not. - "Try again" voided its boolean; a declined remount left no card and no shell, strictly worse than the toast it replaced. It now republishes. The strengthened clause is the point: the old one asserted the ABSENCE of per-call startup fields on a mocked transport, which passes whether or not the production fallback fires. It now asserts the explicit suppression, and reddens when the flag is dropped. Four fixtures were under-specified — they drive SSH reattach scenarios but never seeded an SSH repo, so `connectionId` was null and they had been passing without the pane being SSH at all. Seeded, not weakened. 43,256 pass; the 7 failures are pre-existing on clean main in this environment. * fix(terminal): suppress the whole saved startup set, not field by field Round 4 self-check on my own round-3 fix. `suppressSavedStartup` guarded four of the six values `connect` falls back to — `launchAgent` and `startupCommandDelivery` still inherited from the transport's constructor. Adding the guard per field is precisely how those two were missed, and the guarded expressions had become unreadable. The saved values are now one object that `suppressSavedStartup` drops wholesale. A field added later is covered by construction rather than by remembering. Found by asking the question the review lens was given rather than waiting for its answer: does the suppression cover EVERY channel, or only the ones I noticed? It did not. * fix(terminal): stop stranding a local pane whose restore fails The unreachable-pane card is SSH-only: a local, daemon or runtime-host pane has no connection to be unreachable ON. Consolidating that guard into the publisher made it silent, and four callers paired the now-conditional publish with an unconditional `return` — so on the deferred-reattach path, which unlike the direct-SSH one is not nested under `connectionId`, a local pane got no card, no error and no replacement. Frozen, with a stale binding. The diversion now reports whether it took ownership of the failure, so a caller can only stop when something actually handled it. A pane that cannot show the card falls through to the replace-in-place it had before, which is correct: its provider is authoritative about its own ptys. The two direct-SSH sites are inside `if (connectionId)`, so they are unchanged in behaviour; the return value simply makes the pairing impossible to get wrong at the next call site. * docs(terminal): put two comments back on the thing they describe The lease-healing docblock had drifted onto durablyBoundPtyIdForPane, which neither retires leases nor returns a count, leaving the real healing entry point undocumented and its neighbour carrying two contradictory descriptions. The suppression comment claimed to cover "every startup value this transport was constructed with"; env/envToDelete are constructor values and deliberately stay outside the set. Nothing behavioural changes here — but a comment that overstates a boundary is how the next maintainer picks the wrong one. * docs(terminal): do not claim a remote runtime is authoritative about its ptys A remote runtime reaches its pty over a connection that can fail, so a failed reattach proves no more there than it does over SSH. It keeps replacing in place only because the card is SSH-scoped, not because its provider is authoritative. Say that, so the limitation is deliberate rather than implied. * perf(ssh): stop fsyncing the whole store from the main thread on reconnect supersedeDuplicatePaneLeases runs at the top of every reattach pass, and when it retires anything it flushed synchronously. flushOrThrow fsyncs a multi-MB file from the Electron main thread — this file already documents (see flushAsync) that on a stalled network profile mount that syscall is uninterruptible, so the app stops repainting and no deadline can bound it, because the deadline's own timer is stuck behind the same block. The population that hits this is exactly the one the heal exists for: an upgraded install carrying accumulated duplicates. It now awaits the async durable twin its neighbours on this path already use. Still "OrThrow", because a retirement that is not durable must not be believed — the rollback is unchanged. * fix(ssh): make a parked PTY delivery expire instead of going dark for good Exhausting the per-generation recovery budget parks one PTY's delivery rather than dropping the shared relay channel — right, because the channel is shared and a retry count proves nothing. But the only escape it named was "the next relay open", and a channel that stays healthy never gives it one. That leaves a pane with no output and no way back, which is the exact state this change exists to prevent; before this branch, exhaustion dropped the channel and the reconnect ladder recovered the pane (loudly, at every sibling's expense). The park is now a cooldown rather than a verdict: the next rejected frame after it starts a fresh budget. Recovery is rate-limited, never abandoned, and the containment that made parking right in the first place is untouched. Elapsed time, not a timer, so there is nothing to cancel on teardown and no late fire after dispose. * fix(ssh): let a due park past the retired-delivery filter, and prove it The cooldown added in 124e00e8a8 was reactive: it needed a later rejected frame to reach recovery. But retirement is ours, not the host's — a stalled source keeps publishing the very token we retired, and acceptPtyData drops those frames before classification. So the wake-up could never fire in the case that actually happens, and the pane stayed dark exactly as before. A parked PTY past its cooldown is now let through that filter. It costs nothing: the frame is re-classified as rejected and re-retired, so no output reaches the terminal — it only regains the ability to ask for recovery. The test shipped with that commit could not have caught this: it woke recovery with a fabricated NEW delivery token. Retirement holds one key per relay PTY, so that frame overwrote the key and un-retired the original — the assertion passed with the wake-up path fully broken. It now reuses the original token throughout, and reverting the guard above reddens it. * refactor(terminal): one i18n namespace per component, and two notes worth keeping The disconnected banner was renamed but kept reading five keys under the old component's namespace while its new strings sat under the new one — a component translating from two namespaces at once. Keys moved across all five locales; values and behaviour unchanged. Two comments earn their place. durablyBoundPtyIdForPane deliberately does NOT require the tab to still exist, unlike findTerminalTabIdForLeaf which must — adding the "missing" check there would make arbitration retire shells more eagerly, which is the opposite of what this change is for. And the respawn after the proof check in the direct-SSH catch is unreachable today by construction; saying so stops it reading as forgotten code. * fix(ssh): unknown PTY liveness is not proof of death hasPty is three-state and says so: null means the provider has not listed the host yet — ignorance, not death. The retry gate tested it with `!`, which reads null and false alike, so it ended recovery on ignorance. That state is not exotic: a reconnect builds a fresh provider with an empty set, which is exactly the moment rejected frames arrive. The attempt was deleted and no retry scheduled, and because the delivery token was already retired, no later frame could revive it — the pane stayed dark. It also short-circuited the park cooldown, since parkedAt was never set on an entry that no longer existed. Only an explicit false stops us now. The proven-exit clause still pins that. * fix(terminal): do not unbind a live shell the new-terminal spawn adopted While the card is up the pane keeps its durable binding on purpose, so a failed replacement can put the card back. But main resolves a stable pane's owner from that same binding: if the shell answers again between the failed reattach and the click, the spawn adopts it and returns its id. Nothing was replaced, and clearing the binding then unbound a shell that is live and attached to this very pane — leaving it running with no durable record of what it owns. Detected by identity: an id equal to the one we were replacing means adoption, not replacement. Suppressing adoption outright would need a new spawn option plumbed renderer -> transport -> IPC; the user-visible oddity that remains is getting the old shell back rather than a new one, which is benign next to orphaning it. * feat(ssh): record the host-attested shell identity on the lease A lease names a shell by ptyId, and ptyId alone cannot identify one: a replaced relay restarts its ids at pty-1, so the same id can name somebody else's shell. This adds the missing primitive — the incarnation the HOST attested — so a later change can tell "my shell" from "a different shell wearing its id". No behaviour changes yet; nothing reads the field. Only host-attested values are stored. The provider synthesizes a stand-in when a host reports none; that stand-in is first-write-wins and is dropped when provider state resets, so the same live shell can present a different one after a reconnect. Recording that would later read as a different shell and strand a live pane, so it is refused, and the synthesizer now shares the prefix constant with the predicate that rejects it. Leases are rebuilt field by field on load, so the normalizer had to learn the field too — adding it to the type alone drops it on every boot, which is how a fence ships silently permitting everything. The oracle reddens on exactly that. * fix(ssh): fence a recycled relay PTY id on the shell's own identity A reset relay restarts its ids at pty-1, so an id alone can name somebody else's shell: a pane still bound to pty-1 could attach to a shell another pane was already driving, and the two would share keystrokes and output. The guard that used to catch this compared the paneKey and tabId frozen at spawn. It was removed for good reason — a pane moved to another tab was refused its own live shell, and refused as "not found", which read as death and resumed the agent a second time. So it traded a cross-attach for a double resume. The incarnation is the shell's OWN identity, so it discriminates a recycled id without caring where the pane lives: both failures close at once. The relay refuses a mismatch and is deliberately not worded "not found" — that phrasing is what the client maps to an expired session, and expiry authorizes a respawn onto a shell this branch just proved is alive. Only a host-attested expectation is sent. The locally synthesized stand-in is not stable across reconnects and would refuse a pane its own shell. An older relay ignores the field and an older client sends none, so both stay permissive. The tab-keyed comparator is deleted rather than left dormant, and its suite is inverted onto the new identity: a recycled id is still refused, and a pane that moved tabs now attaches instead of being told its shell is gone. * fix(ssh): only an exit the relay watched may authorize a replacement A bare not-found became SSH_SESSION_EXPIRED, and expiry authorizes a respawn. But "the relay I asked cannot hand that id back" proves an exit only if that relay is the one that minted it — a replaced relay answers exactly this for shells still running under its predecessor. So after a relay restart, live orphaned shells were read as dead: ownership cleared, lease expired, and the agent resumed a second time onto a transcript its first process was still writing to. The relay now keeps what it actually observed. On a real exit, and on the liveness probe that finds a pid gone, it remembers {code, incarnation} in a bounded map and answers a later attach with SSH_PTY_EXITED instead of throwing that knowledge away. That is first-hand, same-process evidence, and it is the only answer that now maps to expiry. A remembered exit for a DIFFERENT incarnation is not an answer about the caller's shell, so a recycled id cannot report a stranger's death as its own. A crash loses the map, which correctly reads as no knowledge rather than as death. The carrier is the message text: the relay's error transport keeps only a message and a numeric code, so a structured payload would not survive. It is deliberately worded to avoid "not found", which older clients map to expiry. Cost, stated plainly: against a relay too old to remember exits, a genuinely dead shell is now unproven, so the pane offers the disconnected card instead of replacing itself. That is the affordance's purpose, and it is the safe direction. * fix(ssh): a remembered exit answers only the shell that asked for it Review found three ways the new proof could be believed too easily. A caller that names no shell was still handed a remembered exit. That is the same double resume in a new costume: relay A is killed leaving pty-1 alive and orphaned, relay B mints its own pty-1 and THAT one exits, and a pane carrying no recorded identity would be told its shell is gone — then replace a process still running. The expectation must now be present AND match. Panes with nothing to compare get the disconnected card, which is the direction that cannot lose work. The proof is also gated on the client declaring it understands it. What the host answers reaches clients that predate the reply, and one of those reads an unrecognised attach error as neither death nor recovery — a stranded pane. Older clients keep the wording they already act on; nothing is lost, because they could not have used the proof anyway. And the match is anchored on the whole grammar rather than the token, with the id and incarnation percent-encoded. A substring test would let any text that merely quotes the token stand in for the relay's own observation. Two callers that key on "already gone" now also accept a proven exit, so the liveness-probe reap does not burn a retry before reaching the same conclusion. The oracle for the first of these was itself vacuous: `toThrow` with a negated asymmetric matcher passes whenever anything throws at all. It now reads the thrown message, and reverting the guard reddens it. * fix(ssh): the liveness reap proves nothing to a caller who named another shell The remembered-exit route was fixed to require a present, matching expectation. The liveness probe is the other route to the same claim, and it still answered anyone: it fires when a pty EXISTS but its pid is gone, and under a given id a replacement relay may hold a shell that is not the caller's at all. Its death is then no evidence about a pane whose own shell may be running orphaned under the relay this one replaced — and the reply authorizes replacing it. Both routes now demand the same thing. The reap still happens either way, because a dead shell should be cleared whoever asked; only the answer depends on whose it was, and a caller who named a different shell is told exactly that. Found by asking whether the guard ordering was right, after the first fix closed only the half that had been reported. * fix(ssh): the client checks whose exit the proof is about Enforcement lived only on the host. But the host is the party whose answer is in question, and mixed versions are the normal state — a host that applies the rule loosely, or not at all, could hand back an exit for a shell the pane never owned and the client would replace a process that is still running. The incarnation travels in the proof precisely so the asking side can check it. A proof that cannot be tied to the shell this pane asked about is not proof, and falls through to the disconnected pane. A pane that knows no incarnation cannot verify anything, so it does not get to act on one either. Both halves now apply the same rule independently, which is what makes it hold across versions rather than only when both ends agree. * fix(ssh): fence the reconnect path too, not just the pane-driven restore There are two client attach routes and only one was fenced. The pane-driven restore goes through reattachSshPtySession, which was sending the shell identity; the relay session's own reattach — the one that reconnects EVERY known pty when a relay comes back — goes through attachForReconnect, which sent nothing. That is the wrong one to leave open. A relay coming back is exactly when ids have been reissued from pty-1, so the main reconnect was the likeliest place to attach somebody else's shell, and it was attaching by id alone. It now sends the identity the lease recorded, which is what the lease field added earlier was for; the two halves finally meet. Pane identity is still not sent — only the shell's own — so a pane that moved tabs is unaffected. It also declares exit-proof support, so a proven exit can reach the path that reattaches after a host restart. Callers with nothing extra to say keep the older call shape, so this does not churn every reconnect assertion in the suite over trailing undefineds. * fix(ssh): actually write the shell identity the reconnect fence reads The lease field was declared, preserved on load, and read on reconnect — and never written. Both spawn writers omitted it, so every lease carried only "pty-N", the reconnect always took the no-expectation path, and the fence added for it could not fire. The main reconnect went on attaching by id alone, which is the replaced-relay case the fence exists for. Worse than inert: a successful unfenced attach durably binds the pane to whatever answered, so the wrong identity would be recorded and carried forward. The host attests the identity at spawn and it was already in scope one line above both writers. The oracle for this had to pin the WRITE. Every other clause — the type, the loader, the reader, the reconnect forwarding — was green throughout, because each was correct in isolation; only nothing joined them. The test that covers the spawn now seeds a host incarnation and requires it on the persisted lease, and removing either writer reddens it. * refactor(ssh): one home for the exit-proof rule, and comments the house style allows AGENTS.md asks for brief non-obvious comments, one line where possible. Several of mine ran to five and eight lines of narrative on the relay's attach path, which is the one place a reviewer most needs to scan the branching quickly. They now say the same thing shorter. Both gone-paths in attach() had independently spelled out the rule that proof must name the caller's own shell. That duplication is what let the earlier fix close one and miss the other, so the condition is now a single predicate both ask — a change to the rule cannot reach one path and skip the other. The renderer kept its own copy of SSH_SESSION_EXPIRED while this branch created a shared home for exactly that token, whose whole reason for existing is that the two copies once disagreed about an identity mismatch and the renderer respawned a live shell. It imports the shared one now. Not changed, after checking: the per-generation recovery budget still does not reset on a successful reattach. Resetting it looks obviously right and is wrong — a flapping PTY alternates failure and success, and a covering test drives exactly that for forty rounds. The park cooldown already bounds the harm. * fix(ssh): keep the pane fence for clients that cannot name a shell Deleting the relay's pane-identity comparison disarmed the recycled-id guard for every client that has not upgraded. The relay is shared and host-side: one person updating a host would leave their colleagues attaching by id alone, with nothing checking it in either direction. It is back as a FALLBACK, used only when the caller sends no incarnation. A client that can name the shell is still fenced on that and still attaches after moving tabs; a client that cannot gets the older, coarser check it was already living with rather than none at all. The two clauses inverted when it was deleted are restored, because they send pane identity with no incarnation — the old-client shape, which should be refused. The moved-pane property they used to contradict is pinned separately by the clause that sends an incarnation, and reverting the override reddens it. * fix(ssh): a bare not-found must not retire a pane's owner Retiring a stable pane's owner authorizes a replacement that carries the pane's agent resume payload. Until this branch, an SSH reattach failure reached that decision as SSH_SESSION_EXPIRED, which the gone-check did not match, so it never fired for SSH. Retiring the not-found mapping changed that: the raw `PTY "<id>" not found` now matches, so a replaced relay answering for a shell its predecessor is still running would retire the owner, fabricate an exit, and respawn with the resume payload — the double resume, reintroduced by the commit meant to prevent it. For an SSH pane the two proving answers are the relay's own observed exit and the expiry the reattach mints only after verifying that proof names this shell. A bare not-found is neither, and now propagates instead: the pane keeps its owner and surfaces as disconnected. Local and daemon ptys are unchanged — their provider owns its ptys, so absence really is proof. The shutdown paths that also use the gone-check are untouched: there, "not found" is the outcome being asked for. The covering test drove the dangerous shape directly — bare not-found, retire, respawn with `codex resume …`. It now drives the proof, and the bare not-found case is pinned beside it. * fix(ssh): retire a lease the relay proved dead Reattach failure left every record untouched, including the one answer that settles it. A shell the relay watched exit kept a live lease, so every later reconnect fanned out an attach for it — two attempts and a ten-second deadline each — and the set only grew, in a file written to disk. A proven exit now retires the record. `terminated`, not `expired`: expiry is the state the recovery grant reads, and retiring a record must not also authorise a replacement. Everything else is unchanged and still leaves the pane detached and recoverable, which is the point — a not-found is also what a replaced relay answers for shells its predecessor is still running. * fix(ipc): one import of the incarnation module, not two CI's code-quality plugins deny a second import of a module already imported in the same file; the pre-commit hook runs a different oxlint config and did not see it. Both failing checks were this: `verify` is a gate that only reported static analysis, with typecheck, tests and both package jobs already green. * fix(ssh): harden PTY reattach reliability * fix(persistence): fence duplicate lease rollback * test(pty): pin incarnation write fence * fix(ui): center narrow terminal recovery actions * fix(ssh): make the unreachable-pane state reachable, and its actions work The decisive cases for this affordance have sat at `fixme` because the state was not inducible: the card needs the SSH target CONNECTED while exactly one pane's attach fails without proving the shell gone, and every host-side fault takes the whole connection down instead. So the behaviour was only ever argued from reading, which is how several oracles here ended up green for the wrong reason. It is inducible now, using the fence this branch added for another purpose: the relay refuses an attach whose expected incarnation names a different shell, which is per-pty and leaves the connection healthy. Rewriting a pane's recorded identity while the app is closed reproduces it deterministically. Running it immediately found two defects that reading had not: The error toast painted over the card. It renders at z-50 in the same bottom strip and was suppressed only for the connection overlay, not for the pane's own card — so in the one state this affordance exists for, BOTH its actions were unclickable. "Start a new terminal" then did nothing at all: no shell, no host change, card straight back. It routes through the path that resolves the pane's owner and attaches it, and the owner is the very shell we cannot reach — so the attach fails and nothing is created. The action now refuses adoption, which is what makes it a creation. Nothing is killed; the old shell stays alive and unbound. Honest status: the gate is NOT green. The card now clears and the action runs, but shell creation is not yet observed reliably across runs. Committing so the oracle and both fixes are not lost; the remaining failure is the next work. * fix(ssh): a session id is the instruction to attach, so a refused adoption drops it Skipping stable-pane owner resolution in main was not enough: the action still sent the pane's recorded sessionId, and the provider reattaches on that before any owner logic runs. So "Start a new terminal" kept attaching the very shell it could not reach, and created nothing. The id is now dropped at the last gate before the IPC, where it cannot be reintroduced by a caller that forgets. Also records what running the gate has established so far, including the one defect still open: with both fixes in, the click still produces no spawn at all (visible=true launches=1 shells=1), while the main log over the same window shows only the pane's own restore retries. The evidence points at the action closure belonging to a superseded connection, not at the spawn path — so the next step is to instrument the handler rather than add a third spawn-path guard. * docs(ssh): locate the remaining defect — main re-derives the session id Instrumented the handler, the transport and main in one correlated run. The closure hypothesis was wrong: the handler runs, the connection is live, and the renderer half is correct — it sends no session id and asks for adoption to be refused. Main re-derives the id anyway, attaches the unreachable shell, and the spawn rejects, so the action resolves null and the card returns. That narrows it from "a renderer race" to one gate in main: createFreshShellForUnreachablePane covers only the early owner resolution, while a second site downstream still passes sessionId: owner.ptyId to the provider. Recorded with the evidence and the shortlist of call sites, plus the instruction to gate where the owner is CONSUMED rather than adding a third condition at a third producer — this is the same rule leaking at a third site, which is the signature this branch keeps producing. * fix(ssh): refuse adoption where the owner is consumed, not where it is derived The unreachable pane's "start a new terminal" still attached the shell it could not reach. The renderer was already correct — instrumenting handler, transport and main together showed it sending no session id and asking for adoption to be refused, while main re-derived the id anyway. The rule had been applied at the two places an owner is PRODUCED and missed at the one place it is CONSUMED: spawnForStablePane turns an owner into `sessionId` for the provider, which is what makes an attach an attach. Gating there closes it for every producer at once. The decisive E2E now passes: with the target connected and one pane unreachable, the action creates exactly one shell, leaves the unproven old shell running and unbound, and clears the card. Reverting the single condition reddens it. This rule leaked at three sites in a row and each fix was necessary while none was sufficient. The one that held was placed where the value is used. * refactor(terminal): the same-id guard now protects a new shell, not an adoption Refusing adoption removed the case this guard was written for. What remains is the opposite: a reset relay can reissue the old id to a genuinely NEW shell, and main has already bound the pane to it — so clearing by that id would unbind the shell just created. Same code, and it is still needed; the comment said the wrong reason, which is how the next reader deletes it. This also closes the planned "tell the user we recovered your terminal" work as obsolete: there is no silent recovery left to announce, because the action now always creates. --------- Co-authored-by: Orca <help@stably.ai>	2026-08-13 01:36:01 -07:00
Jinjing	7c93aed6dc	Fix fsync of read-only files on POSIX (#14235) ... * fix(files): fsync read-only files on POSIX * test(e2e): add golden E2E tests for POSIX profile index fsync Validates that profile index files are properly persisted on POSIX systems, including with restrictive umask settings. These are release-blocking golden tests for Linux and macOS. * test(terminal): wait for fish child ownership before stdin write Fish 4.8 withdraws DECSET 2031 before spawning the child, so the shell-contracts harness could send hello into an intermediate prompt and hang waiting for CHILD-READ. Wait for the child's CHILD-READY marker and answer split DA1/CPR/OSC queries across chunk boundaries. * test(e2e): verify profile index persists to disk with restrictive umask Strengthen the POSIX fsync test to verify the rebuilt index is actually written to disk and has correct permissions under a restrictive umask, not just cached in memory.	2026-08-13 00:58:55 -07:00