feat(web-shell): restore remote workspace add flow - #12085

Superseded verification note

The previous report targeted 676964111b43 and described the removed Local/Remote chooser. It does not apply to the current PR head.

Current-head UI evidence for 1b5c3d647c is recorded in the updated UI verification comment: #12085 (comment)

Real-daemon browser verification

Verified 67337b7faf90 plus the two fixes below, in Chromium, against two real qwen serve
daemons: the Web Shell built from this branch served on 127.0.0.1:4190 with a local workspace,
and a second daemon on 127.0.0.1:4191 behind a bearer token with --allow-origin for the first,
its workspace set one level above a directory that exists nowhere else so the two suggestion lists
cannot be confused. The page never left the first origin: ?daemon=http://127.0.0.1:4191 switched
the API target while location.origin stayed 127.0.0.1:4190, which is what lets the tab-scoped
return URL survive the navigation.

Driven and observed:

1. Add workspace on the standalone shell opens a dialog titled Add Workspace with a Workspace location choice. With an empty catalog, Remote reads "Connect a computer in Daemon Status first." and Local is preselected.
2. Local → Next opens the browser at /private/tmp/ (the parent of the local daemon's workspaceCwd) with a 50-entry list from a live suggest call, plus Parent folder, Browse…, Change computer, Cancel and Add this folder. Parent folder moved it to /private/. Cancel closed the dialog, left the shell where it was, and the local daemon's registration list stayed empty.
3. Opening ?daemon=http://127.0.0.1:4191 for an origin this browser had never used showed the unfamiliar-target gate with the address prefilled and "Connect only if you trust it." Entering that daemon's token connected the shell: the sidebar switched to the remote workspace, the URL kept no token, and the browser-local catalog became exactly ["http://127.0.0.1:4191"].
4. Add workspace → Remote then lists 127.0.0.1:4191 as a connected computer and changes the hint to "Use a folder on a connected server." Next resumed on the remote daemon, where the browser opened at that daemon's own directory — alpha/ beta/ reports/ — and the hint named it: "Folder on http://127.0.0.1:4191."
5. Entering reports/ and clicking Add this folder closed the dialog, kept the shell on the remote daemon, cleared the tab-scoped return marker, and added the workspace to the sidebar. The remote daemon reports the new registration (/private/tmp/pr-remote-ws/reports, active, persisted) while the local daemon's registration list is still empty — the add landed on the selected daemon only.
6. Remote workspace rows carry the globe badge (2 rows on the remote target, aria-label "Remote"); the same shell on its own daemon shows none.
7. Change computer from the remote browser returned to the source shell with the location step reopened; Cancel returned to the source shell with the dialog closed. Daemon Status lists the verified computer under Connected computers.

A screenshot was captured at every step (location choice, both browsers, the gate, the empty-directory state, the added workspace, the badge control, Change computer, Cancel, Daemon Status) and the run is reproducible from the two daemon commands above; the observations quoted here are the rendered UI text, not a reading of the source.

Not covered: macOS Chromium only, loopback ports standing in for two hosts (no real SSH tunnel or LAN path, so TLS and mixed-content are untested), a single saved computer, and no long-lived remote session or re-auth after a daemon restart.

Review follow-ups

Six suggestions came back from triage, none blocking. Two are fixed here, and the rest are answered against the current head.

1. Local announced as remote — fixed. The two shells that stand in while capabilities load (or when the daemon cannot register workspaces) were titled with the remote wording even though a Local add resumes into them; they now use the neutral title, and the gate's cancel button no longer offers to cancel a remote add. The sidebar entry itself was already neutral.
2. Autocomplete blanking during the debounce — fixed. The suggestion list is now cleared only in browse mode, where the list is the primary control, so the pre-existing typed-path autocomplete keeps its previous results until the next answer arrives instead of flashing empty on every keystroke. This was a regression against main, not just a remote-path concern.
3. Design docs — already updated for the Local option in both languages at this head; both describe the this-computer/connected-computer choice and its acceptance criterion.
4. "Standalone only" pinned negatively — already covered by the existing two-entry-points case, which sets the registration capability and, with the embedded default, requires the plain dialog to open. Inverting the branch fails that test.
5. Escape/close removed while submitting — left as written. The workspace mutation goes through the daemon client, which has its own request timeouts, and the dialog is the only writer of that state; I would rather not widen the diff for a hypothetical hang.
6. typeof window guard — declining, with the reasoning that web-shell mounts through ReactDOM.createRoot and needs no server-render path; the sibling module the suggestion compares against reads location unguarded on its own entry points, so the proposed invariant does not actually hold there either.

The E2E specs cited in the body are still not part of the diff, so they cannot be re-run by a reviewer; the run above is the record that a real daemon drives the whole flow.

Fixes for the copy and autocomplete findings are pushed in 11d6bac, and the real-daemon browser run is recorded above. @qwen-code /triage

web-shell E2E Smoke failed on 11d6bac — cause and fix

The job failed all three attempts (original + 2 retries) in the extension-manager smoke test, not in anything the copy fixes touched:

Error: strict mode violation: getByRole('button', { name: 'Add' }) resolved to 2 elements:
  1) <button title="Add workspace" aria-label="Add workspace" class="_projectsHeaderAction_jzzo8_322">
  2) <button data-slot="button" …> aka getByTestId('inline-panel').getByRole('button', { name: 'Add' })

An accessible name matches by substring, so the sidebar's Add workspace action also matches Add. That action renders only when the shell passes the add-workspace handler, and this PR made that condition standalone || dynamic_workspace_registration instead of the capability alone. The e2e fake daemon advertises neither the registration capability nor a locked workspace, and the dev entry mounts standalone — so before this PR the button could not appear in that spec, and now it always can. That is the same behaviour widening as the earlier note about standalone shells offering the entry on daemons that cannot register workspaces, and this is its concrete cost: an unrelated, previously green test became ambiguous.

b910bfb matches the dialog's button exactly, the disambiguation the rest of the suite already uses. Verified against this branch on a free port: the spec fails without the change and passes with it, and the whole @smoke set is 84/84 green locally. Nothing else in the suite collides — the other 83 tests passed on CI with the button already present.

If reviewers would rather keep the entry gated on the daemon's capability, that decision supersedes this test fix, and the test should then be left as it was.

Reproduction note for anyone running these specs locally: the config sets reuseExistingServer outside CI, so a dev server left on the default port by another checkout is silently reused and the run tests that code instead. Pin PLAYWRIGHT_PORT to a free port.

Extension-manager smoke fix pushed in b910bfb. @qwen-code /triage

E2E test report — remote workspace add flow

The behavioural claim in this PR now has a committed test instead of a throwaway config: packages/web-shell/client/e2e/web-shell.remote-workspace-add.spec.ts, four @smoke scenarios in the repository's own suite.

cd packages/web-shell
npx playwright test --config playwright.config.ts client/e2e/web-shell.remote-workspace-add.spec.ts --project=chromium

4 passed (16.5s)

Chromium on macOS. If a dev server from another checkout already owns the default port, pass a free one (PLAYWRIGHT_PORT=5274 …): outside CI reuseExistingServer is enabled, so the run will otherwise exercise that other tree's code.

Two mock daemons are installed on one page — the page's own origin with a local workspace at /srv/local-project, and http://127.0.0.1:5199 with a remote workspace at /srv/remote-project — and each host lists one folder that does not exist on the other, so a suggestion list identifies which daemon answered.

1. the resumed browser lists the chosen computer directories — the Remote choice navigates the tab to the chosen computer and the resume marker survives it; the resumed dialog lists shared-checkout and never local-checkout; the source daemon receives no suggestion request at all; picking the folder registers /srv/shared-checkout/ on the chosen computer, and the source daemon receives no registration either.
2. cancelling returns to the exact source tab — toHaveURL(sourceUrl) with an empty query string, the dialog gone, the sidebar entry back, and no registration on either host.
3. changing the computer reopens the chooser on the source tab — the shell is not behind the unfamiliar-target gate, the chooser is open with Local selected, and the origin is unchanged.
4. the local choice browses folders on the page origin — the local folder is listed, the origin never changes, the continuation marker is already cleared from the URL, exactly one reload happened (two load events including the initial navigation), and the suggestion request went to the page's own daemon.

Test infrastructure added for this (client/e2e/utils/mockDaemon.ts): GET /workspace-path-suggestions and POST /workspaces, plus a pathSuggestions scenario field. Both are additive — nothing in the SDK or the Web Shell client calls GET /workspaces, so no other spec's routing changes — and the responses were matched to the real contracts (DaemonWorkspacePathSuggestions, DaemonAddWorkspaceResult) rather than guessed, including updating the capability snapshot so the post-add refresh sees the new workspace.

Scope ledger: the earliest reviewed head (3ccc4e8) was 17 files / 1,246 changed lines. The current PR diff at 0696655 is 31 files / 2,756 changed lines against base 2bd62fb. All current implementation files map to the verified-connections catalog, folder-source workspace flow, remote-host indicator, or the bounded F1 abandoned-hand-over fix. This is substantive round 4; scope-correction mode remains active, and N1/N4 stay outside this PR.

Round 2 — findings disposition at b045a7de

Two commits on top of b910bfb4: 74fb08e fix(web-shell): guard the resumed add step outside a document and b045a7de test(web-shell): cover the remote workspace add flow end to end.

Why the new tests are load-bearing rather than decorative

Each one was checked by breaking the code under it, not only by watching it pass:

• Forcing remoteWorkspaceAddActiveRef to false fails all four E2E scenarios; forcing the resumed dialog's initialPath to undefined fails the first one — the dialog appears but never lists the chosen computer's folders.
• The embedded-shell assertion fails when the sidebar entry is passed unconditionally.
• The typeof window unit test fails with the guard removed.

The mock daemon's two new routes were matched to the real contracts instead of guessed: GET /workspace-path-suggestions answers DaemonWorkspacePathSuggestions (kind/dir/sep/suggestions[]/truncated, client/daemon/workspace/types.ts:400), which is exactly what AddWorkspaceDialog reads, and POST /workspaces answers DaemonAddWorkspaceResult (types.ts:351) while updating the capability snapshot so the post-add refresh sees the new workspace. An OPTIONS preflight branch I wrote first was deleted after a request log proved Playwright's route interception never issues one for these calls — dead code.

Gates at b045a7de

• Changed-file ESLint, prettier --check, tsc --noEmit, and npm run build: clean.
• Web Shell unit suite: 8443 passed (the run needs dist/, so build first for build-artifact.test.ts). One earlier run on this same head failed a focus assertion in components/composer/AddMenu.test.tsx; it passes in isolation and a full re-run of the same head is green, so it is a load-sensitive flake rather than something this diff reaches.
• Web Shell E2E, full suite on a free port: 158 passed, 4 failed — all four in web-shell.live-state-poll-interval.spec.ts. They fail identically with my changes reverted, so they are pre-existing and local to this machine; the same specs are green in CI.

One red check, and it comes from the base

Lint & Static failed on b045a7de inside Check lint gate freshness, before any linter ran. That step fails when main changes a gate-defining file after the branch last incorporated it, and it names eslint.config.js and eslint.legacy-core-barrel-imports.mjs from 6c962b3719c6 (#11163, merged today). The same lane was green on b910bfb4 about an hour earlier, so this is main moving, not the two new commits. Neither change touches this diff: one adds the generated web-shell confusables table to the ignore list, the other drops a packages/cli/src/serve/routes/ entry from the barrel-import allowlist, and the branch touches no packages/cli file and neither path. The lane's own remedy is to merge or rebase main into the branch, and main merges cleanly into it, so that stays a deliberate separate step rather than a side effect of this round.

Recorded but not acted on

• The three JSX branches keyed on remoteWorkspaceAddActiveRef.current and the two near-duplicate DialogShell blocks. I agree this is the least pleasant part of the change, and collapsing it would also remove the pairing requirement between the ref write and the state write. It is a refactor of code this PR just introduced, so it would widen the diff again; recording it here rather than doing it inside a verification commit.
• The design questions from the first stage (navigateToDaemon's third parameter, whether the "no cross-host continuation" constraint is formally retired on feat(serve): supported remote folders — connect clients to a remote daemon and manage its workspaces/sessions #11475, and whether the two ways of adding a workspace eventually merge). These are issue-thread decisions rather than defects in the diff, and none blocks merge.
• The widened sidebar entry. On a standalone shell whose daemon lacks dynamic_workspace_registration, the action is now visible and the Local branch reaches the "This server does not support adding workspaces." state where main hid the entry entirely. That is the deliberate trade-off for offering the Local option; the embedded-shell behaviour stays pinned by the new App.test.tsx case, and the ambiguous smoke locator this widening caused is fixed in b910bfb4.

@qwen-code /triage

Merged the latest main in 2cde1e4, which clears the stale lint-gate failure. 1773d987 is a subtractive follow-up: it removes the redundant completion ref and collapses the duplicate loading/unsupported shells without changing the flow contract.

Verified with Web Shell typecheck, changed-file ESLint, Prettier, the focused App test, and the four remote workspace-add Playwright scenarios. A fresh correctness/security review and a focused post-cleanup correctness pass found no actionable issues.

@qwen-code /triage

Verification at 2364d150

2364d150 records that it left build, typecheck and tests to CI. CI is green on it (Lint & Static, Test (ubuntu-latest), web-shell E2E Smoke, Capture web-shell visuals, both Desktop Shell lanes, Integration Tests (no-AK); review-pr still running), and here is an independent local pass on top of that, on the actual head:

• Focused unit tests over the surface this commit touches — App.test.tsx, both workspace dialogs, remote-workspace-add, the sidebar workspace-removal test: 1187 passed.
• The remote-workspace-add Playwright scenarios: 5 passed (16 s), including the new "with no connected computer the folder browser opens directly" and the updated single-load assertion for the local choice.
• Changed-file ESLint (no errors; the two CSS files are outside the lint config's scope) and Prettier check: clean.

Two notes, neither of them a finding against this diff:

• The full Web Shell unit suite (8658 tests) came back with one failure, components/composer/AddMenu.test.tsx > returns keyboard focus to the trigger after Escape. It is intermittent and load-sensitive: on this same head it passed twice and failed once when run alone, and the DOM in the failure contains the hidden file input that #12084 added in the merge. The branch touches no composer code, so this is a flake in that test rather than a regression here — but it can redden the suite for anyone, so a re-run is the right response when it appears.
• If you reproduce locally from a linked worktree that shares the main checkout's node_modules, a Web Shell typecheck after merging main reports seven errors in BranchPickerPopover.tsx and AuthMessage.tsx about missing SDK members. Those are stale build artifacts resolved out of the main checkout, not this branch; building inside the worktree does not change it because the root node_modules is a symlink.

Current-head UI evidence at 1b5c3d647c

The earlier evidence was captured from 676964111b43, before the interaction was changed, so it has been superseded.

This capture uses the current PR head with the Web Shell dev server and two local mock daemon endpoints. No local lint, tests, or npm ci were run for this evidence refresh.

1. Add and manage the remote computer in Connections

Adding 127.0.0.1:5199 verifies the target through the connection gate and returns to Settings > Connections. The address field is empty for the next connection, and the verified computer is listed separately.

2. Add workspace opens the directory browser directly

Clicking Add workspace opens this directory browser immediately. There is no Local/Remote chooser. Folder source selects the connected computer inside the same browser, and the remote daemon supplies shared-checkout/.

The sidebar also shows the remote host chip and the remote workspace folder with its blue globe badge. This capture uses mock daemon endpoints rather than a physical second machine.

@qwen-code /review

Qwen Code review request accepted. Review is queued for an available runner; follow the workflow run for progress. A command-triggered review is not listed under the checks of this PR; the result is posted here as a review when it finishes.

Maintainer verification — two real qwen serve daemons, production Web Shell bundle

Verified 1b5c3d647c on macOS against real daemons, not mocked endpoints. The shell under test is the built packages/web-shell/dist served by qwen serve itself (the production static path and its CSP), and the "connected computer" is a second qwen serve behind a real bearer token with --require-auth and --allow-origin. Chromium drove the real UI: 70 scripted assertions, 66 green; the 4 red ones are all one defect (F1 below).

Rig

Reviewer Test Plan — 9/9 reproduced

Because the shell is served by the daemon, the production CSP is in play rather than the dev server's: GET / answers connect-src 'self', and GET /?daemon=http://127.0.0.1:4191 answers connect-src 'self' http://127.0.0.1:4191 ws://127.0.0.1:4191 — the cross-origin calls above really are made under that policy.

Extra probes beyond the plan: an unreachable connected computer degrades to the retrying gate and Cancel still restores the source page; an origin that is not in the catalog still faces the unfamiliar-target gate (the security control is intact).

Repo gates run locally at this head

packages/web-shell vitest            338 files / 8868 tests passed
web-shell.remote-workspace-add.spec  6 passed (chromium)
tsc -p tsconfig.json --noEmit        clean
eslint packages/web-shell            clean

Evidence

Settings > Connections after verifying the second computer

Folder source selector — one list, no separate Local/Remote step

The same browser, resumed on the connected computer (real directories from daemon B)

Remote marking — host chip on the Projects header, globe badge on the folder icons

Authentication failure stays inside the flow

390 × 844

F1 — an abandoned hand-over leaves its return location behind (minor, reproducible 100%)

The continuation is one-shot and tab-scoped, but it is only cleared on completion or cancellation. A reload — or the browser Back button — abandons the flow without clearing it, because the URL marker is stripped by App's effect while qwen-remote-workspace-return stays in sessionStorage. The next Cancel in any Add-workspace dialog then consumes that stale location.

Repro on the rig above:

1. On :4190, Add workspace → Folder source → 127.0.0.1:4191 (tab hands over).
2. Press F5. The dialog is gone (flow abandoned), but sessionStorage['qwen-remote-workspace-return'] === "http://127.0.0.1:4190/" survives.
3. Open Add workspace again — a brand-new, purely local add on :4191 — and press Cancel.
4. The whole shell navigates away from :4191 back to :4190. Measured settled state: url = http://127.0.0.1:4190/, 0 globe badges, sidebar back to workA.

The Back-button variant is milder but reachable with no refresh at all: after Back, cancelling an ordinary local add triggers a full page navigation (load event fired) instead of just closing the dialog.

Candidate fix — tested on the rig (head red → patched green → head red again), with remote-workspace-add.spec 6/6, client/config + App.test.tsx 1085/1085 and every happy-path probe still green:

// client/config/remote-workspace-add.ts
export function discardAbandonedRemoteWorkspaceAdd(): void {
  try {
    window.sessionStorage.removeItem(RETURN_URL_KEY);
  } catch {
    // Nothing to discard when storage is unavailable.
  }
}

// client/App.tsx
useEffect(() => {
  if (initialRemoteWorkspaceAddStep) clearRemoteWorkspaceAddStep();
  else if (standalone) discardAbandonedRemoteWorkspaceAdd();
}, [initialRemoteWorkspaceAddStep, standalone]);

Safe because the return key is only ever written by startRemoteWorkspaceAdd/selectRemoteWorkspaceLocation immediately before a navigation that carries the marker — a marker-less boot in standalone mode means the flow is over.

Notes (not blockers)

• N1 — the catalog is written on every successful gate probe. StandaloneAuth calls rememberRemoteConnection(baseUrl) outside the connection-add branch, so confirming a one-off ?daemon= link once permanently adds that origin to qwen-remote-connections, which main.tsx now treats as a confirmed target for every future tab (the confirmation used to be sessionStorage, i.e. per tab). Measured: fresh tab, empty catalog, one ?daemon=… + token at the gate → ["http://127.0.0.1:4191"] persisted and the origin offered as a Folder source. Defensible ("the operator verified it", and it is removable in Settings), but worth a line in the PR description or scoping the write to the add flow.
• N2 — mutation check on the new tests. 10 mutants across remote-connections.ts, remote-workspace-add.ts, daemon.ts, App.tsx, AddWorkspaceDialog.tsx, each run against client/config, the three dialog suites, App.test.tsx, main.test.tsx and the new e2e spec. 3 are killed (catalog validation, forget-clears-token, remember-on-complete). I traced each of the 7 survivors: token stripping on both return legs is dead code (the URL is already stripped when it is written), the same-origin guard on both return legs guards a state sessionStorage cannot produce, showList's browseDirectories || is redundant once the first fetch sets listOpen, and the same-target reload marker is not reachable from the selector (it short-circuits on the current source). The one survivor that guards real behaviour is hasRemoteWorkspaceLocation — nothing pins the "entry enabled because a remote exists" case, which is also N4 below. Everything else is equivalent-by-construction, so no meaningful test hole.
• N3 — zh copy. workspaceHost.thisComputer is 这台计算机 but workspaceHost.folderOnThisComputer is 这台电脑上的目录. One word, two spellings.
• N4 — dead end on a daemon without dynamic_workspace_registration. The unsupported/ loading status dialog has no Folder source selector, so a user whose local daemon lacks the feature (the entry is enabled because a remote exists) can only Cancel. Unreachable with today's qwen serve (dynamicWorkspaceRegistrationAvailable is hard-coded true), so it only matters for an older or third-party daemon.

Not covered

Windows; a real second machine / non-loopback network; HTTPS or a TLS-terminating proxy; a daemon that does not advertise dynamic workspace registration; behaviour of a long-running session across the full-page hand-over.

Verdict

The workflow does what the description claims, on real daemons, including the parts a mock cannot prove: real CORS + bearer auth on the cross-origin suggestion calls, the registration actually landing (and persisting) on the selected daemon, and the credential never touching the URL. F1 is the only defect I found, and the fix is contained (one helper plus one line in an existing effect). From my side this is fine to merge; I'd land F1 either in this PR or as an immediate follow-up.

packages/web-shell vitest            338 个文件 / 8868 条用例通过
web-shell.remote-workspace-add.spec  6 passed（chromium）
tsc -p tsconfig.json --noEmit        干净
eslint packages/web-shell            干净

// client/config/remote-workspace-add.ts
export function discardAbandonedRemoteWorkspaceAdd(): void {
  try {
    window.sessionStorage.removeItem(RETURN_URL_KEY);
  } catch {
    // Nothing to discard when storage is unavailable.
  }
}

// client/App.tsx
useEffect(() => {
  if (initialRemoteWorkspaceAddStep) clearRemoteWorkspaceAddStep();
  else if (standalone) discardAbandonedRemoteWorkspaceAdd();
}, [initialRemoteWorkspaceAddStep, standalone]);

Landed F1 (the abandoned hand-over leaving its return location behind) at 06966553aa, plus the N3 copy fix. cc @wenshao

F1 — what changed (one helper plus one line, as you proposed):

• client/config/remote-workspace-add.ts: new discardAbandonedRemoteWorkspaceAdd(), which removes RETURN_URL_KEY (qwen-remote-workspace-return) and tolerates unavailable storage.
• client/App.tsx: the existing marker-stripping effect gains else if (standalone) discardAbandonedRemoteWorkspaceAdd();, deps now [initialRemoteWorkspaceAddStep, standalone].

I re-checked your safety precondition against the tree instead of taking it on trust, and it holds. The key has exactly one writer, startRemoteWorkspaceAdd (remote-workspace-add.ts:40), and it is removed again at :52 when navigateToDaemon returns false. Both navigateToDaemon success paths carry the marker: the target-change path assigns nextUrl, which sets addRemoteWorkspace=browse at daemon.ts:335-337, and the same-target path replaceStates the marker into the current URL (daemon.ts:365-368) before window.location.reload() at :375. So a marker-less standalone boot can only mean the hand-over is over, and the discard cannot destroy a live continuation. selectRemoteWorkspaceLocation delegates to the same writer, so it adds no path of its own.

The consumption side of the bug is confirmed too: handleOpenExistingWorkspace (App.tsx:13340) sets workspaceBrowseActiveRef.current = standalone for any add in standalone mode, so closeAddWorkspaceDialog (App.tsx:13197) reaches leaveRemoteWorkspaceAdd() and its window.location.assign even for a purely local add.

Tests (jsdom):

• App.test.tsx: discards a return location an abandoned hand-over left behind (the witness) and keeps the return location of a standalone boot that resumes the hand-over (guard against an over-broad discard).
• config/remote-workspace-add.test.ts: drops a return location an abandoned hand-over left behind, which also pins the consequence — the stale location can no longer drive a Cancel (leaveRemoteWorkspaceAdd() returns false, location.assign not called).

Non-tautology, measured rather than assumed: reverting the App.tsx effect line reddens exactly the witness (expected 'http://localhost:3000/session/original' to be null) while the resume case stays green; making the helper a no-op reddens the config test and leaves its other 6 green.

Local run: client/config + App.test.tsx + i18n.test.ts = 1089/1089 passed (7 files). eslint clean on all five changed files, prettier --check clean.

Browser-level evidence is inherited from your rig, not re-captured here. I did not stand up the two-daemon + Playwright rig and did not re-run remote-workspace-add.spec; the matched before/after evidence for this exact patch is your measurement (head red → patched green → head red again, remote-workspace-add.spec 6/6, client/config + App.test.tsx 1085/1085).

N3: workspaceHost.folderOnThisComputer is now 这台计算机上的目录, matching workspaceHost.thisComputer = 这台计算机.

N1, N2 and N4 are deliberately untouched — you labelled them non-blockers and this diff is already large, so I kept the change to this one defect.

中文小结：F1 已按你的方案落地（一个 helper + 一行 effect），并在代码里复核了「写 key 必然紧跟一次带 marker 的跳转」这个前提，两条 navigateToDaemon 成功路径都带 marker，所以无 marker 的 standalone 启动只可能是流程已废弃。jsdom 单测 1089/1089 通过，回退修复后对应 witness 变红。浏览器级证据沿用你双 daemon 环境的实测，我没有重跑 e2e rig。N3 一并统一为「这台计算机」。N1/N2/N4 未处理。

Round 2 — re-verified on 06966553aa against the same two real daemons

Rebuilt this head in the same rig (built packages/web-shell/dist served by qwen serve itself, second qwen serve behind --require-auth --token --allow-origin) and re-ran everything, plus new probes aimed at the fix itself. 78 assertions, 76 green; the 2 reds are my F1 bug-characterisation probe, which asserted the teleport and is therefore red by design now (details below).

F1 is closed on the real rig

Same probes, same rig, only the commit changed:

After the abandoning reload, sessionStorage['qwen-remote-workspace-return'] is gone, and the next Cancel now closes the dialog without navigating: the tab stays on ?daemon=http://127.0.0.1:4191, sidebar still workB + beta-remote-checkout with globe badges. The Back-button variant fires no load event at all any more.

One thing to read correctly: my third probe (probeF1d) exists only to pin the defect's symptom — "after the stale-return cancel the tab is on the source daemon URL, 0 globe badges". On this head it reports 2 failures. That is the expected post-fix polarity, not a regression; the settled state it now measures is url = …?daemon=http://127.0.0.1:4191, badges = 2.

The fix cannot eat a live continuation — measured, not assumed

The risk in "discard on a marker-less standalone boot" is an App mount that happens inside a live flow. I looked for one:

• Traced the remount paths. StandaloneAuth sets accepted exactly once (setAccepted has a single call site) and never re-gates, and both <App> mount sites render it without a changing key, so App cannot remount mid-flow within one document.
• Exercised the latest possible mount — the gate path. Hand-over to the remote with no stored token → gate → correct token → App mounts only then, after the marker-bearing URL. The return location survived (qwen-remote-workspace-return === http://127.0.0.1:4190/) and Cancel still returned to the exact source page.
• Exercised a mid-flow outage. Killed daemon B while the folder browser was open on it: the continuation survived, and Cancel after the outage still restored the source page.

7/7 green on those.

No regressions — the whole Reviewer Test Plan re-run

All nine steps re-measured on this head: 61/61 green (Connections add/verify/return/forget, direct folder browser, hand-over with token out of the URL, cross-origin suggestions with the bearer header, POST /workspaces only on the selected daemon plus its on-disk persistence, Cancel to the byte-exact source URL, the gate paths, ordinary daemon switches, unreachable target, desktop + 390×844).

Repo gates on this head (local)

packages/web-shell vitest            338 files / 8871 tests passed   (8868 → 8871: the 3 new tests)
web-shell.remote-workspace-add.spec  6 passed (chromium)
tsc -p tsconfig.json --noEmit        clean
eslint packages/web-shell            clean

Your test claims, re-measured here

N3

Verified in the shipped bundle, not just the diff: 这台计算机上的目录 appears once in dist/assets/index-*.js and 这台电脑上的目录 is gone. zh UI shows 目录来源 = 这台计算机.

Verdict

F1 is genuinely closed at browser level on real daemons, the guard against an over-broad discard is real, and nothing in the plan regressed. N1/N2/N4 stay as agreed non-blockers. LGTM to merge from my side.

packages/web-shell vitest            338 个文件 / 8871 条用例通过（8868 → 8871，即新增的 3 条）
web-shell.remote-workspace-add.spec  6 passed（chromium）
tsc -p tsconfig.json --noEmit        干净
eslint packages/web-shell            干净