fix(web-shell): Select worktree mode without extra confirmation - #13607

E2E verification report

Verified on macOS with Node.js 22.22.2 and Chromium. Mode-selection screenshots in the PR body come from actual browser runs with mocked daemon requests. The additional first-message initialization screenshot uses the changed local Web Shell with a real isolated Qwen Code 0.25.0 daemon.

Browser command, from packages/web-shell:

PLAYWRIGHT_PORT=5190 npx playwright test client/e2e/web-shell.git-mode.spec.ts --project=chromium --workers=1

The original six-scenario browser suite verifies UI state and the outgoing request contract. An additional real-daemon initialization test now verifies actual Git worktree creation and session ownership. Model execution was not tested. Root build, typecheck, and bundle did not pass because the existing installation is missing email/A2A dependencies and contains stale bridge build output. No new CLI bundle was produced.

The PR body includes the real Before/After screenshots hosted on wenshao/qwen-code under assets/web-shell-automatic-worktree-session-20261007.

Pre-commit review: two consecutive open-ended/adversarial audit rounds found zero Critical and zero Suggestion issues. Four additional adversarial browser cases passed: keyboard selection with prefilled text does not submit early, both branch/Worktree transitions clear the other mode, and escaping an invalid unconfirmed branch preserves the selected intent correctly. Each case rechecked exactly one session creation request after the prompt request.

Additional first-message initialization evidence

Real initialization screenshot is embedded at the start of the PR description’s English and Chinese evidence sections. The test passed 1/1 in 8.2 seconds: while the real creation request was still pending, the first input remained visible and the send button showed Loading and was disabled. There was no artificial response delay. The daemon then returned HTTP 200 with persisted ownership; the actual directory, Git registration and branch, owner marker, and daemon session association all matched. Zero prompt/generate/recap requests were sent. The isolated daemon was stopped afterward.

Review follow-up verification

Review follow-up adds two real-component tests to the existing PR unit-test gate and links the superseded confirmation behavior in both design languages. Both requested mutations were rejected by the new tests: the old pending-only click fails the intent callback assertion, and resetting the selection on reopen fails the checked-state assertion. Unchanged controls passed 18/18 before and after. Two further pre-commit audits (round 3 open-ended and round 4 adversarial) were clean; the adversarial rerun also passed 18/18 with unhandled-error ignoring explicitly disabled.

Only tests and the bilingual design documentation changed in this follow-up; the browser and real-daemon screenshot evidence above remains from the unchanged product implementation. Web Shell build/typecheck, changed-file ESLint/Prettier and whitespace checks passed again. Root build/typecheck remain blocked by the existing dependency/build-output problems described above.

⏳ Approval still deferred — 1 PR CI workflow run(s) still in progress for 8b2d319; the finalize job approves automatically once every run lands green. finalize run

⏳ 审批仍在延迟中 —— 8b2d319 还有 1 个 PR CI workflow 在运行，全部通过后 finalize 任务会自动提交审批。查看 finalize 运行

Thanks for the PR!

Template looks good ✓ — every required section filled in, both languages, before/after evidence attached.

Problem: real, and confirmable from the code rather than taking the description's word for it. handleConfirmWorktree did nothing but call onIntentChange({ mode: 'worktree' }) and close the popover — no checkout, no request. The worktree is actually created later by the pre-existing first-prompt path: App.tsx reads the intent when the first message is sent and passes worktree: { slug } into session creation, which lands as worktree: {} on POST /session. So the second click bought nothing, and the button's label ("Create worktree") actively misdescribed what it did. That is an observed defect, not theoretical hardening.

Direction: aligned. One click is already the norm on this surface — the Worktrees manager path creates a new session with a worktree intent directly and no confirmation, and the "Current branch" option in this same popover commits immediately. Worktree was the odd one out, and it was odd in the direction of extra friction. No direct reference in the upstream Claude Code CHANGELOG to a git-mode selector confirmation; worktree isolation is a heavily worked area there, so the surface itself is clearly relevant.

Size: not applicable — no core paths are touched (all six files are Web Shell client or docs/design/). For context: +165/−84 across 6 files, roughly 38 production lines (component, its CSS module, i18n copy), 111 test lines, 100 documentation lines. Well under any advisory threshold.

Approach: close to the minimal edit, which is what I'd have written from the title alone — drop the button, drop its now-orphaned styles and the two translation keys, rename the handler to say what it does, and fix the description copy so it states when the copy is created. Turning the clear-button test into a two-mode loop is assertion-preserving: every branch assertion survives, and the worktree path gains coverage plus a "no session request before send" check. No drive-by refactors or unrelated churn ride along. Design doc is present in both languages with matching sections and reciprocal links.

Risk: no elevated risk signals — none of the changed files match the revert-correlated high-risk paths. The component has exactly one consumer (the composer), and it only renders while the workspace is git-eligible and no session is loaded, so the blast radius is the empty-session composer.

Moving on to code review. 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 8b2d319a5ab6b665958ddb02ce57f2df3b683412 · re-run with @qwen-code /triage}

Code review

No Critical blockers and no AGENTS.md violations. This is a removal, so most of the review is proving nothing was left behind and nothing else depended on what went away — I could settle both statically.

The premise checks out in the code, not just in the description. The deleted handler only recorded { mode: 'worktree' } and closed the popover; creation is done by the pre-existing first-prompt path, which reads the intent ref and passes worktree: { slug } into session creation (arriving as worktree: {} on POST /session). Nothing about that path changes here.

The removal is complete. A repo-wide search for the deleted translation key, the git-mode-confirm-worktree test id, and the .confirmWorktree rule turns up nothing outside the files this PR touches. Messages is Record<string, MessageValue>, so there is no key-list type for a dropped key to desynchronize, and EN and ZH dropped it together. The selected-state styling the worktree radio still relies on (.checkWorktree) is untouched — only the confirm-button rules went.

selectedMode can't go stale. The click no longer calls setSelectedMode('worktree'), but the open handler re-syncs it from intent.mode every time the popover opens, so reopening with a worktree intent still shows the checked radio, the ✓, and the git worktree add footer line. There's no reachable state where selectedMode says worktree while the intent doesn't.

Reversibility is real, and now tested. The ✕ reset renders for both branch and worktree intents, unchanged, and the rewritten spec drives it for worktree.

Consumers, named. The composer is the only renderer of this component, and App only wires the intent props while the workspace is git-eligible and no session is loaded; the intent is reset on session start and workspace switch and read exactly once, at first-prompt session creation. Nothing else reads the removed key or test id.

The tests come out stronger, not weaker. The worktree test trades a "the confirm button stayed visible for 300 ms" guard for assertions on the thing that actually matters: the chip reads Worktree, no POST /session was sent by selecting it, and after sending there is exactly one creation request carrying worktree: {} and no branch. That pins "deferred, and not duplicated" far better than the old guard did. The dropped focus-steal guard is genuinely moot for this option — the popover is supposed to close on click now — and a regression of that dismissal would fail the new chip assertion instead of passing silently. The clear-button test becoming a two-mode loop keeps every branch assertion and adds the worktree path.

Design docs meet docs/design/README.md: both languages, same section order (problem → proposal → scope and constraints → validation and acceptance → risks), reciprocal links under the title, and the technical identifiers (worktree: {}, POST /session, the .qwen/worktrees/<slug> path) match across the pair.

Two non-blocking notes, take them or leave them:

1. The worktree option loses its "preview without committing" affordance — the footer's git worktree add line is now only visible once the intent is already worktree, i.e. on reopen. That's the same tradeoff "Current branch" already makes and reset covers it, so I'm fine with it; just naming it so it reads as a decision rather than a side effect.
2. Nothing asserts the reopen state (select Worktree → chip shows Worktree → reopen → option still checked, worktree command in the footer, no confirm button). Two extra lines in the existing worktree spec would pin the selected-state styling too.

Testing

This was an unattended CI run, so nothing in the PR was built or executed here — the evidence below is the PR's own CI, read through the API for the reviewed commit, plus static reading of the diff against the surrounding code.

CI results for 8b2d319 — this table auto-updates as CI workflows complete:

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

No check is red, so there is no failure log to excerpt. Reading the green ones for what they actually cover: Lint & Static gives ESLint and Prettier over the changed files, and Test (ubuntu) runs the package vitest suites — which for this component means the branch-name validation cases and the i18n unit tests, plus the App-level intent tests. None of those drive the popover.

The changed browser specs do not run in this PR's CI. The CI browser job runs the smoke lane (playwright test --grep @smoke), and web-shell.git-mode.spec.ts carries no @smoke tag, so the rewritten tests are not executed by any check above. The Capture web-shell visuals job is the closest thing: its git-mode scenario renders the closed chip, the open three-mode popover, and the branch sub-state as a before/after composite against the merge base — which will show the new, longer description string in the layout, and it never clicks Worktree, so it asserts nothing about this change. Not verified here: the one-click interaction itself, and the "exactly one POST /session with worktree: {}" contract. The author reports six local Chromium scenarios plus a real-daemon run covering those; that is the author's claim, not evidence this review re-ran.

Sandboxed verification would settle it: @qwen-code /tmux on the Web Shell surface — that one click on Worktree closes the popover, shows the chip, and that sending the first message produces a single session creation with worktree: {} and no branch, which no check in the table above exercises. @qwen-code /verify is the lane if you'd rather have the request contract A/B-proved against the base build. The author has write access, so either can be triggered directly.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 8b2d319a5ab6b665958ddb02ce57f2df3b683412 · re-run with @qwen-code /triage}

Confidence: 4/5 — clean, minimal removal whose premise I could verify in the code; the only reservations are about test reach, not about the change.

Stepping back: this is the rare UI PR where the diff is smaller than the justification. My own independent read of the title and the "why" was exactly what landed — make the Worktree option behave like the Current-branch option next to it, delete the button that never did what its label claimed, and correct the copy so it says when the isolated copy appears. There was no simpler version of this that I could find, and no scope to cut: 38 production lines, all of them deletions or a renamed handler, plus the copy and the tests that had to follow.

What convinces me it's right rather than just tidy: the second click was not a safety confirmation, it was a label lying. Nothing behind that button created a worktree; creation has always happened on the first message, and the Worktrees manager already starts a worktree draft in one click without anyone worrying about mis-selection. Reset before sending covers the accidental-click case and is now tested for worktree, which is the one real risk the design doc names. Six months from now this reads as "the selector has three options and all three behave the same way" — that's a maintenance win, not a debt.

Where I'd hold back a point: the tests that prove the behaviour are the ones CI doesn't run. The rewritten specs are genuinely better than what they replace — asserting one POST /session with worktree: {} and nothing sent before the first message beats the old button-visibility guard — but they sit outside the smoke lane, so no check on this commit executes them. The green suite above tells me lint, formatting, i18n and the App-level intent tests are fine; it does not tell me the click works. That's a gap in what CI reaches, not a defect I found, and the author's local browser runs plus the real-daemon capture are plausible — they're just not evidence I re-ran. If you want the claim settled rather than believed, @qwen-code /tmux on the Web Shell surface is one comment away. The two nits from the review (no assertion on the reopen state; the worktree footer command is now only visible on reopen) are worth a follow-up at most, not a round trip.

CI is still running on the reviewed commit — Test (ubuntu-latest) and the web-shell visuals capture were in flight at review time, with nothing red. So approval is deferred until CI lands green on 8b2d319a5ab6b665958ddb02ce57f2df3b683412; the finalize job posts the commit-pinned approval at that point, and withholds it if anything fails or the head moves. No approval is submitted by this run.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 8b2d319a5ab6b665958ddb02ce57f2df3b683412 · re-run with @qwen-code /triage}

🖼️ web-shell visual preview

Rendered against a mock daemon (no real backend): the PR base vs this PR head aa4613e. Only screenshots that changed are shown (flows below, if any, are head-only) — refreshes on every push.

Screenshots · before / after

_{Full-resolution recordings (.webm) are attached to the workflow run.}

— Qwen Code · web-shell visuals

Maintainer verification — PR #13607: fix(web-shell): Select worktree mode without extra confirmation

Verdict: merge-ready — 10,991/10,991 scripted assertions passed, 0 unexpected failures.
Verified head: 8b2d319a5ab6 · base: 718ae1e6c6da (current main tip, so the A/B is also the merge preview).

Central claim

Selecting Worktree in the composer git-mode popover now selects the mode and closes the popover in one click (previously a second click on a "Create worktree" button was required, which only recorded a draft intent). No session request is sent at selection time; the first message sends exactly one POST /session carrying worktree: {} and no branch, and the daemon then auto-names and creates the real git worktree.

A/B load-bearing proof

Same committed spec (client/e2e/web-shell.git-mode.spec.ts @ 8b2d319a5ab6) run against both builds; trees differ only in the PR's production code (each tree's @qwen-code/sdk realpath verified tree-local).

Witnesses: 01-ab-head-spec-green.png, 02-ab-base-spec-red.png.

Mutation check (vacuity): reverting only the onClick={handleSelectWorktree} line back to setSelectedMode('worktree') at head — keeping everything else — turns exactly the two worktree tests red (the branch-clear test stays green, correctly). The onClick hunk alone is load-bearing, and the new spec is pinned by the behavior, not by construction.

Independent harness (maintainer-written, not from the PR)

The PR description cites four adversarial browser scenarios that are not committed to the repo. I re-implemented them as an independent spec driving the head build through the same mock-daemon seam (29 scripted assertions, all passing — 03-independent-harness.png):

1. Worktree → Branch: select Worktree (chip flips, zero POSTs of any kind), switch to New branch, confirm — send carries branch, no worktree.
2. Branch → Worktree: confirm branch first, switch to Worktree — send carries worktree: {}, no branch.
3. Keyboard select with prefilled composer: Enter on the Worktree radio selects and closes without submitting; composer text preserved; explicit send then issues exactly one POST /session with worktree: {}.
4. Escape unconfirmed invalid branch: invalid name disables confirm; Escape restores current-branch mode; send carries neither key.

Real-daemon arm (head qwen serve + real Chromium)

Drove the head-built web-shell served by the head-built daemon (packages/cli/dist/index.js serve --workspace /tmp/pr13607-wt-test, isolated git repo, scratch HOME seeded with auth) in real Chromium: one click on Worktree → type → send.

• Wire: exactly one POST /session, body {"cwd":…,"sessionScope":"thread","approvalMode":"yolo","sourceType":"default","worktree":{}} — worktree: {} present, no branch key; zero POST requests before the first message.
• Disk: /tmp/pr13607-wt-test/.qwen/worktrees/bright-fox-41c1e6 created, registered in git worktree list, branch worktree-bright-fox-41c1e6 checked out inside it. 10/10 assertions.

Witnesses (live browser shots against the real daemon): rd-2-popover.png (new copy "Creates an isolated copy when you send your first message"; no confirm button), rd-3-selected.png (one click → chip shows Worktree with reset control), rd-4-after-send.png (session created; real model turn started).

Environment note: with a scratch HOME lacking credentials, the same flow fails at POST /session with 500 Authentication required and leaves no worktree on disk — a clean, pre-existing daemon failure mode unrelated to this PR (the PR only changes what the UI sends; the wire body was verified correct in that run too).

Gates

Findings

Suggestion (non-blocking): the one-click Worktree selection has no unit-level pin. GitModePopover.test.tsx (16 tests) exercises only branch-name validation — the word "worktree" appears in neither unit test file. All behavioral coverage is e2e-only; a component-level test (click Worktree → onIntentChange({mode:'worktree'}) + popover closes) would catch a regression faster than the browser suite. The e2e coverage itself is proven load-bearing by the A/B above, so this is a test-pyramid nicety, not a gap in protection.

Not covered

• Windows / Linux (macOS only, Node 22.23.1, Chromium 1.61.1).
• Model output quality: the real-daemon arm did start a real model turn, but only session/worktree creation was asserted.
• Mobile webkit viewport of the popover.
• The branch-mode flow is covered only by the committed spec (passes at both builds) — unchanged code path.

Methodology

Two git worktrees at the exact headRefOid/baseRefOid resolved from the PR, each installed with corepack pnpm install --frozen-lockfile --ignore-scripts, with only @qwen-code/acp-bridge + @qwen-code/sdk + (head) the full monorepo built. Workspace links verified tree-local via readlink -f (no cross-tree leak). Browser suites ran via Playwright against each tree's own Vite dev server (ports 5191/5192); the base arm ran the PR's spec copied verbatim into the base tree, changing no base production code. The real-daemon arm used the head-built CLI daemon with an isolated git workspace and a scratch HOME (auth block seeded from the maintainer's settings; no secret material copied into artifacts). Raw logs: tmp/pr13607-verify-20261007-221640/ (logs-head-spec.txt, logs-base-spec.txt, serve-5196.log, evidence/).

Local verification by @wenshao's maintainer harness; evidence images hosted on the verify-pr13607-assets branch of wenshao/qwen-code.