Catalog session rows (sidebar context menu + click), the built-in viewer
header, and a new "Open Codex/Claude sessions in" preference can launch the
native CLI (codex resume / claude --resume) in the operator terminal on the
machine that owns the session.
- Gateway-local sessions spawn through the existing terminal launch policy
(sandbox/enabled gates preserved) with the resume command in the session cwd.
- Paired-node sessions run through a new seq-ordered node PTY relay: a
duplex node-host command streams PTY output via node.invoke.progress and
receives keystrokes/resize via a new node.invoke.input event, behind the
unchanged terminal.* client protocol (TerminalSessionManager gains a backend
abstraction; node relay reuses the streaming-invoke controller).
- Owner boundary: each plugin owns its resume command and builds argv from a
validated thread id; the gateway routes node opens through the node command
allowlist and plugin invoke policy (no advertisement-only trust), and nodes
re-verify session eligibility before spawning.
- UI setting catalogOpenTarget + canOpenTerminal capability gate every entry
point; capability requires the owning host to actually have the CLI.
Node PATH is normalized before command-availability probes, Windows .cmd/.bat
shims spawn via ComSpec, and catalog terminal opens reattach persisted tabs
before opening the new tab.
* fix(wizard): defer config commit until after migration apply succeeds
Onboarding migration import commits the config file to disk before the
migration provider's apply() runs. If apply() legitimately reports an
error on any item, runSetupMigrationImport() throws, but the config is
already committed with wizard metadata stamped on it. On the very next
onboarding attempt, the freshness gate sees that stamped config and
refuses to run the import, telling the user a fresh setup is required.
Move the commitConfigFile call to after assertApplySucceeded(), so a
failed apply never leaves wizard metadata on disk that blocks the next
retry behind the fresh-setup gate.
The in-memory config still has wizard metadata applied before the apply
context is constructed (so the apply function can reference a concrete
target), but the disk write only happens after apply succeeds.
Fixes#103262
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* fix(lint): remove useless assignment in migration config commit
The `targetConfig = await params.commitConfigFile(targetConfig)` line
assigns to `targetConfig` but the value is never read afterwards.
Remove the assignment, keeping the side-effect call.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* fix(wizard): preserve config patches from provider apply after commit
Restore the targetConfig assignment from commitConfigFile so that config
patches written by the provider during apply (e.g. auth profile
selections) are carried forward. Without this, the pre-apply snapshot
silently replaces the post-apply config, losing provider-authored
patches.
Fixes#103262
* fix: remove useless assignment to satisfy lint
commitConfigFile persists the config to disk; the returned config with
patches is already on disk, making the in-memory assignment unnecessary.
* fix(wizard): make Hermes import retries recoverable
* chore: keep release notes release-owned
* fix(wizard): keep retry identity stable across acknowledgement
* fix(wizard): satisfy Hermes retry quality gates
* test(wizard): use managed migration temp dirs
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* refactor: delete dead infra and config exports
* refactor: preserve live infra and config contracts
* refactor(config): remove obsolete file-store lifecycle APIs
* refactor(infra): finish current-main dead export cleanup
