2 Commits

Include renames

Author	SHA1	Message	Date
3 people	6494f2a4f0	fix(native-chat): resume a structured chat from Agent Session History (#18933) ... * fix(native-chat): resume a structured chat from Agent Session History Clicking Resume on a chat-UI row could only reveal an already-open tab. If the chat had been closed, or this process had never published it, the click re-read an inventory that did not contain it and toasted "Retry in a moment" — advice that could never come true, because nothing republishes an unpublished tab. The legacy `claude --resume` fallback is deliberately refused for structured-owned rows, so the row had no way back at all. `close` already keeps the record and the journal on disk so a session can be attached again, and the hold path already resurrects one in full. What was missing was the tab: `restoreReadableSessions` is latched to run once, at startup, so nothing could ask for a single session later. Adds `agentSession.reveal`. The host looks up its own record, restores the session readable, and republishes the tab through the same call `agentSession.create` uses. Deliberately narrow: - It takes no hold. A provider child exists because a surface asked, and the chat pane asks when it binds. - A journal it cannot read is not a refusal. A chat whose journal predates the SQLite store restores to nothing here, but attach still recovers it, so the tab is published and the pane's hold finishes the job. - Workspace and provider come from the record, never the client, so a session id alone cannot aim the publication at another workspace. Claude and Codex both, by construction: eligibility is `adapterSupportsRecord`, which the router answers from the record's own provider. Gated on a new advertised capability rather than probing for method_not_found, matching agent-session.structured.hold.v1 — absence is visible during negotiation instead of by calling. * fix(native-chat): negotiate reveal against the host that owns the workspace The capability gate read the LOCAL runtime's advertised capabilities while the call went to the host that owns the workspace, which for a paired workspace is a different build. On desktop the renderer and its local host are always the same build, so the gate passed unconditionally and proved nothing about the host being called: an older paired host still received the unknown method and its method_not_found was reported to the user as 'this chat is no longer on this host'. The cache it read also starts empty and resets to empty when status.get fails, so 'not fetched yet' and 'unsupported' were the same value. Gate on the environment that will answer, the way agentSession.close already does, and skip the round trip entirely for a local host. Reveal now reports four outcomes instead of a boolean, so a host that is merely too old is not reported as a chat that is gone, and a host we could not reach keeps the retryable message. Also syncs the localization catalog: the 'gone' key shipped without an en.json entry, which reddens static analysis and verify while typecheck stays green. * fix(native-chat): tell a refused reveal apart from a missing chat The host raises two refusals here and they mean opposite things to a user: it holds no such record, or it holds one no adapter of its own can open. The client collapsed both into 'this chat is no longer on this host', which is a eulogy for a chat still sitting on disk. Read the refusal code, and fold the host-side case in with the too-old host under one honest message, since the remedy for both is the same. Adds the coverage the readiness pass found missing: the host's reveal answer itself (workspace and provider from the record, both refusals, an unreadable journal, a live session), and the activation branches for a host that cannot open the chat and for one that never answered. * fix(native-chat): read a host version block as the host's age, not a lost link The capability probe reaches assertRuntimeStatusCompatible, which throws a runtime_compat_block error. Treating that as unreachable told a user with an out-of-date host to retry, which is the one thing that cannot help. Branch on isRuntimeCompatBlockError the way remote-agent-session-launch already does for the same probe. Also adds the refusal-code case a previous commit claimed and did not deliver: nothing drove a structured_agent_session_unsupported reply through the reveal client, which is the branch that commit existed to add. Corrects a doc comment that reveal made wrong: attach is no longer the only call that builds the host. * fix(native-chat): let a dragged history row reach the same reveal as a click Dropping an Agent Session History row onto a pane activated the tab by id and, on a miss, raised the very toast this PR exists to remove — so the same row answered a click and a drop differently, and the drop kept the advice that can never come true. The structured branch never used the drop pane, so routing it through the shared activation loses nothing and gains the reveal. The helper only ever read one field, so its parameter narrows to that field and the drag payload satisfies it directly. A source ratchet holds both entry points to the reveal-capable path, since a mounted drag harness does not exist for this layer and what regresses is a call site, not a rendering. * fix(native-chat): stop an advisory refresh ending the click, and one click per row Manual QA found the reveal never ran: the inventory refresh that precedes it is an optimization, but its failure returned early with 'not available yet, retry in a moment' — reinstating the dead end this PR removes, one step earlier. A failed refresh now falls through to the reveal, which is the repair and does not need the refresh to have worked. The click can chain a refresh, a capability probe, a reveal and a second refresh, each with its own timeout, while nothing on the row says it is working. A per-session in-flight guard keeps an impatient second click from running the whole sequence again and landing its own toast. Also drops an unreachable owner scope: the snapshot apply discards any worktree whose execution host is not local before it reads one, so naming a remote scope there described a synchronisation that cannot happen. * fix(native-chat): bound the capability probe and stop naming the wrong machine The in-flight guard releases when the activation settles, so an await that never settles holds the row for the life of the process. The capability probe was the one call in the chain not raced against a deadline: on a cache hit it awaits a promise an earlier probe created, which may carry no deadline of its own. Race it like the two calls around it. A version block can name either side — evaluateRuntimeCompat reports client-too-old as well as host-too-old — so a message that blamed the host pointed half of those at the wrong machine. Name the remedy instead of the machine, which is true for every case that reaches it. * chore: remove a scratch repro file committed by mistake It was swept into the previous commit by a broad `git add` while a diagnostic ran in this worktree. It asserts the current renderer-sync defect as expected behaviour, so it would fail the moment that defect is fixed. * fix(native-chat): stop a reveal's own inventory refresh discarding its republished tab Manual QA: the host answered reveal with ok:true and republished the tab, and the chat still did not reopen — only a renderer reload brought it back. The renderer publishes under one epoch string for its whole lifetime, and a frame recorded under a different lineage retires that epoch permanently with nothing to un-retire it. The Resume click asks for an inventory first, and a worktree the host holds no entry for answers with the none/v0 sentinel; the structured path recorded it, retiring the renderer's own epoch, so the tab the reveal published a moment later was dropped. A reload minted a new epoch, which is why reloading appeared to fix it. A frame that carries no publication is not a later publication to fence against. Treat the sentinel and a removal frame as a cursor reset, the way the mainstream session-tabs path already clears its tracking — its comment names this exact hazard: recording that sentinel would retire the host epoch and reject the next live frame. Pre-existing, and it swallows an ordinary new-tab launch on an empty worktree too; the reveal is what turned a silent invisibility into a visible failure. * fix(native-chat): let a retraction prune its rows without retiring the epoch Correcting the previous commit. Skipping a retraction frame outright stopped it pruning the mirrored rows, so a worktree the host no longer publishes would have kept a chat on screen with nothing behind it. Apply the frame as before and clear its cursors instead of recording them, which is what the mainstream session-tabs path does. The unpublished sentinel keeps its cursor now too: it is skipped rather than cleared, so a stale frame arriving late is still fenced. Adds the case the earlier version would have broken. * fix(native-chat): keep the retraction's fences, and fence the reveal's refresh Correcting the retraction handling again. Clearing its cursors was more than the bug needed and cost a guard: the host mints a fresh epoch when it rebuilds a pruned entry, so a republication is never gated by the retained cursor, while dropping it left an inventory response issued before the close free to land afterwards and strand a chat row for a worktree the host no longer publishes. Skip only the recording. The mainstream path keeps its epoch history for the same reason, as a tombstone fence. The test that justified the stronger clearing asserted a host behaviour that does not exist — a rebuilt entry republishing under the renderer's epoch with a restarted counter. It now uses what publishStructuredAgentSessionTab actually mints for a pruned entry, and a new case covers the frame that would strand. Also fences the reveal's inventory refresh on the sync generation, which every other caller that applies an inventory already does: structured chat can be switched off mid-flight, and the answer would otherwise re-seed a row into a renderer that just discarded them. * fix(native-chat): drop the retraction's epoch history, keep its version cursor Third and final shape for this branch, and the only one of the three that holds. Keeping both maps re-poisons the epoch one cycle later: the consumer here is also the publisher, so the history's current is the renderer's own lifetime epoch, and recording the reveal's fresh epoch retires it. The next chat the renderer publishes is then dropped — this bug again, one close later. Deleting both loses the guard that stops a frame issued before the close landing after it and stranding a row nothing republishes. So: clear the history, keep the cursor. The mainstream path keeps its history as a tombstone because there the epochs belong to a remote publisher; that reasoning does not carry to a path that publishes under its own. Each of the three variants now fails a different test. * fix(native-chat): a retraction forgets what is current, not the tombstones The delete lost a fence the cursor cannot replace: the version cursor only compares within a lineage, so a delayed frame from an already-superseded epoch had nothing left to stop it putting a chat row back for a worktree the host no longer publishes. Keeping the record intact had the opposite fault — the renderer's own epoch is the history's current, so the next frame under any other epoch retired it. Clearing only current does neither: noteRetiredValue retires nothing when there is nothing current, and the tombstones stay. Each of the four shapes now fails a different test. * fix(native-chat): narrow the retraction frame through its own type Typecheck caught what the tests could not: `removed` is not on RuntimeMobileSessionTabsResult. The repo already names the shape — RuntimeMobileSessionTabsRemovedResult — so this reads it through a guard rather than the inline cast the mainstream path uses. --------- Co-authored-by: Orca Worker <orca-worker@localhost> Co-authored-by: Merge Sim <sim@local>	2026-09-06 00:50:20 -07:00
OrcaWinandOrca Worker	cff202c16a	fix(windows): drop EDR-flagged -ExecutionPolicy Bypass from encoded PowerShell (#17880) ... * fix(windows): drop EDR-flagged -ExecutionPolicy Bypass from encoded PowerShell MDE flags `-ExecutionPolicy Bypass` paired with base64 `-EncodedCommand` as a behavioural signal. Measured on Windows 11: neither `-Command` nor `-EncodedCommand` is execution-policy gated (both run under an explicit `-ExecutionPolicy Restricted` and `AllSigned`; only `-File` fails), so the switch was a pure no-op on every one of these command lines. Removes the switch from all four sites that spelled it, and de-encodes the one site whose payload never passes through a re-parsing shell: - ssh-remote-powershell: one chokepoint for ~40 remote-Windows call sites. Base64 kept — the remote sshd DefaultShell re-parses this string. - setup-agent-sequencing / windows-cmd-runner-delayed-launch: base64 kept — these strings are typed into a terminal pane. - windows-interactive-login-spawn: base64 kept — `cmd.exe /c start` re-parses, and the cmd-safe-token guard rejects the `&` and `"` in the raw relay script. - windows-mobile-firewall local runner: `-EncodedCommand` -> `-Command`, since execFile reaches CreateProcess with no shell in between. The setup startup gate keeps execution-policy relief in-payload (process scope), because it evals a user-authored startup command that may invoke a `.ps1`, and a `.ps1` IS gated. Caught by the real-process suite; mirrors the agent-hooks launcher's trade. The elevated firewall child deliberately stays encoded: `Start-Process -ArgumentList` joins its array into one ShellExecuteEx string without quoting and PowerShell re-splits on whitespace, measured to collapse `C:\My App\...` to `C:\My App\...` — a firewall rule for the wrong program. * test(ssh): enforce the no-script-file invariant remote payloads rely on Dropping `-ExecutionPolicy Bypass` from `powerShellCommand` is a no-op only while no remote payload loads a PowerShell script file — execution policy has never gated anything else. That invariant held by inspection and was guarded by nothing, so a future payload that dot-sourced, used `-File`, or imported a `.psm1` would break only on a remote host with a Restricted/AllSigned LocalMachine policy and no GPO: a failure on someone else's machine. States the invariant at the wrapper, and adds a ratchet that scans every module importing it for `.ps1`/`.psm1`, `Import-Module`, `-File`, and dot-sourcing. The scan discovers importers itself (13 today) so new ones are covered, and asserts it found some, so an emptied list cannot pass vacuously. Mutation-checked: injecting each construct into a real importer fails the matching case and names the file. The first dot-source pattern passed a `;`-prefixed sample but missed `powerShellCommand(". '$x'")` — the likelier shape — so the pattern now accepts a string-literal start and the self-test samples carry their surrounding quotes. * test(ssh): close two blind spots in the remote-payload ratchet Both found by independent mutation testing of the ratchet itself, and both let a real violation pass while the guard reported green. `-File` was matched case-sensitively, so `-file $scriptVar` slipped through — PowerShell switches are case-insensitive, and with a variable path the `.ps1` pattern does not cover for it, so that shape escaped both nets. The naive fix is wrong: bare /-File\b/i matches `--credential-file`, `--log-file` and `--body-file`, which occur in three of these importers. Anchoring to a token boundary catches the lowercase, odd-spacing and argv-element forms with zero offenders across all 14. Comment stripping paired a `/*` appearing inside a string (a glob such as 'src/*.ts') with any later comment close and deleted everything between, hiding violations in the gap. Anchoring the block strip to line start, as the `//` strip already was, fixes it — verified by injecting an `Import-Module` after a glob string: the unanchored form misses it, the anchored form catches it. Extends the same case-insensitivity to `.ps1`/`.psm1` and `Import-Module`, which had the identical flaw (`import-module`, `DEPLOY.PS1` are legitimate spellings); measured to add no false positive. Each construct now carries the fixtures it must catch AND the near-misses it must not, so a future tightening cannot quietly trade one for the other — the negative fixtures are what would have caught the naive `-File` fix. Non-vacuity bound tightened to >10 against 14 importers. * docs(ssh): state what the remote-payload ratchet cannot see The scan matches source text, so a script file reached only through a variable (`& $scriptPath`) never appears in source and no pattern can catch it. The ratchet narrows the hole; the invariant note on `powerShellCommand` covers the remainder. Recorded because a guard that reads as complete coverage when it is not is worse than one that states its edge: the next author trusts it further than it deserves, and should learn this limit from the test rather than an incident. * test(ssh): scan remote payloads with the shared source walk The ratchet had its own tree walk and comment stripper. The walk skipped neither node_modules/dist/.git nor dot-directories and excluded tests by `.test.ts` alone, so its importer count -- the guard's own goalpost -- could be wrong about what it scanned. The stripper was anchored to line start to dodge a `/*` inside a glob string, which silently skipped trailing comments; `stripComments` tracks quote state and handles both. Importer set re-derived against the shared walk: 15, floor unchanged at 10. * fix(setup): report a failed execution-policy relief instead of swallowing it The in-payload Set-ExecutionPolicy carried -ErrorAction SilentlyContinue and an empty catch, so any failure vanished. A Windows PowerShell 5.1 install with duplicate extended type data fails every cmdlet in Microsoft.PowerShell.Security -- autoload, not policy -- and the user then saw only their own .ps1 being refused, with no trace that the relief had been attempted or why. -ErrorAction Stop is what routes a non-terminating failure into the catch at all; the catch reports the FullyQualifiedErrorId to stderr and deliberately does not rethrow, so a broken policy cmdlet cannot take down the startup this gate exists to run. Success path is unchanged and stays stderr-clean. Verified by execution on a clean child environment: success -> policy=Bypass, stderr empty; shadowed failing cmdlet -> diagnostic on stderr and the gate still continues; the old empty catch -> silent. --------- Co-authored-by: Orca Worker <orca-worker@localhost>	2026-09-05 21:12:40 -07:00