fix(web-shell): make mobile access opt-in and simplify split composer - #12537

E2E and regression test report / E2E 与回归测试报告

• Baseline: the globally installed CLI launched, but its older UI could not exercise the current embedding behavior. Source-level reproduction produced three expected failures before the fix. / 基线：全局 CLI 可启动，但旧版 UI 无法覆盖当前嵌入行为；源码定向检查在修复前三项均失败。
• Component regression: npx vitest run client/App.test.tsx client/components/ChatPane.test.tsx client/components/ChatContextHeader.test.tsx --reporter=dot from packages/web-shell: 1,202 passed with the nested header.showMobileAccess API. / 组件回归：嵌套属性版本共 1,202 项通过。
• Review follow-up: the standalone test now explicitly enables mobile access; the six selected QR/header tests passed. / Review 修正：standalone 测试显式开启入口后，六项相关定向测试通过。
• Final-source Chromium run: passed. Two split QR entries, one single-chat QR entry, two split workspace header labels, editable split composers, and zero repeated split composer folder chips. / 最终源码 Chromium 验证通过：分屏两个二维码入口、单聊天一个入口、两个分屏工作区页头、可编辑输入框，且分屏输入框重复文件夹数量为零。
• Screenshots in the PR were visually inspected and are stored outside the implementation branch. Mock daemon only; no claim of real pairing, daemon, or Git backend verification. / PR 截图已目视检查并存于独立素材分支。仅使用模拟 daemon，不代表真实配对、daemon 或 Git 后端验证。
• Local validation: workspace build and bundle, Web Shell rebuild after API placement, full repository typecheck, changed-file lint, and commit hooks passed on macOS. / macOS 本地验证：工作区构建和打包、属性归位后的 Web Shell 重建、全仓类型检查、修改文件 lint 和提交钩子通过。

Executed verification at 7402e5baaaa9beb65a2b8dc7e2f3bab53d10d2bd

Verdict: mergeable. No Critical found.

I built the PR's own head tree and ran a four-cell A/B so the green is bound to the diff rather than merely observed. Every count below is read from vitest's own Test Files … / Tests … reporter line, never from an exit status taken across a pipe.

The arm, and why it is not the tmux drive the task names

Two substitutions, both measured rather than assumed:

• tmux is unavailable on this host. A bare tmux new-session -d -s X "sleep 20" returns lost server (rc=1), and tmux ls returns error connecting to /tmp/tmux-0/default. A sleep 20 payload cannot fail on any property of the subject, so the fault is the server, not the command string. Fresh -L <socket> and TMUX_TMPDIR=<dir> both fail identically, and each leaves a default.lock with no socket beside it — the server child dies between fork and bind. Not disk (0.86 GB free), not load (0.23), not ulimit -u (256027), not the socket path.
• For this surface a tmux TUI drive could not reach the code anyway. The delta is entirely under packages/web-shell/client/**, which the terminal TUI never mounts. I also checked the browser route before choosing: grep -rlE 'showMobileAccess|LocalControlQrButton' over packages/web-shell/client/e2e/ returns 0 hits, so no Playwright spec reaches the subject either — a browser run would have painted green without executing a changed line.

So the arm is the PR's own vitest suites, which do own the delta.

Tree and fidelity

git archive of the fetched PR head ref, tar -x, then hardlinked (cp -al, never symlinked) root node_modules, 26 of 26 package-level node_modules, 24 of 24 packages/*/dist, and packages/cli/src/generated. 9,230 files. Postconditions asserted both ways: symlinked package node_modules = 0, and readlink -f node_modules/@qwen-code/qwen-code-core resolves to /tmp/r408mn-arm/packages/core, inside the tree.

All 6 overlaid files are byte-faithful, each with a locally recomputed sha1('blob '+len+'\0'+bytes) equal to the API's own pulls/files[].sha, NUL_bytes=0:

App.test.tsx at 1.34 MB is above the REST contents route's inline cap, where the API answers HTTP 200 with encoding:"none" and an empty content — a void body that still reports a truthful size and sha. It came through git show instead, which is byte-faithful at any size. The four base-arm production blobs came through contents?ref=<base> (all under the cap), each asserted SIZE_MATCH=BLOBSHA_MATCH=True VOID=False NUL=0, and each byte delta closes against its own patch: App.tsx −397 for +13/−7, ChatPane.tsx −549 for +8/−14, customization.tsx +107 for +2/−0, main.tsx +42 for +1/−0.

Four cells

Runner invoked as node <tree>/node_modules/vitest/vitest.mjs run — never npx/npm run, which injects an npm_config_* family that can shadow a test's own uppercase env. npm-ish env keys = [].

Failures across the four cells: 0 → 3 → 2 → 0.

Cell B is what makes A mean anything. Reverting only the four production files to base makes the head tests fail, and all three failures are AssertionError, not resolution failures (is not a function = 0, Cannot find module = 0, is not exported = 0, counted over both streams). The failing titles are exactly the ones this PR adds or rewrites:

• hides Mobile access by default in built-in and custom chat headers — expected <button type="button" …></button> to be null, i.e. at base the QR button is rendered where the new test expects null.
• hides the split header Mobile access entry by default and when disabled — same assertion.
• keeps the workspace in the split header and only shows the toolbar chip when embedded — expected [ 'addMenu', 'approvalMode', …(4) ] to not include 'workspace'.

Cell C is scoped, which is the strongest form of the reachability witness. Mutating one token — const showMobileAccess = header?.showMobileAccess ?? false; → ?? true (anchor uniqueness asserted before = 1, and after: original = 0, mutated = 1) — fails exactly the two tests that own the changed default and leaves all 158 ChatPane tests green. A mutation that failed everything would be ambiguous; one that fails only its own subject proves the harness reaches that subject and nothing else.

Cell D restores both suites to green, with files differing from the head blobs = [] and a mutation-token count of 0.

Non-vacuity: -t "Mobile access" reports 1030 total with 1028 skipped, so exactly 2 tests ran — the filter selected the two new titles and did not silently select nothing.

The one open question from the prior review, now settled

An earlier read of this PR left one axis explicitly unmeasured: the composer-toolbar workspace chip is now gated on embedded && alone, while its rewritten comment says "only embedded panes without a header need the composer chip" — so if a non-embedded pane could exist on a multi-workspace daemon without a header, that pane would lose its only workspace indicator.

It cannot. ChatPane.tsx renders its header block under {!embedded && ( and the workspace label inside it under {workspaceLabel && (, and the PR does not touch either line (its hunks are at 187, 1449, 1484 and 1499). So embedded and "has a header" are mutually exclusive by construction, and the two indicators are complementary: a non-embedded pane keeps its header label and drops the chip; an embedded pane has no header and keeps the chip. workspaceLabel is still computed from showWorkspaceChip alone, so the header path is unchanged at both arms.

The PR's own new test pins the same invariant from the other side — rerender({ …, embedded: true }) then expect(container.querySelector('header')).toBeNull(). Two disjoint routes agreeing.

Also checked

• No dead switch. showMobileAccess is declared once (in the public WebShellChatHeaderOptions), read at three sites in App.tsx (the LocalControlQrButton gate plus both onOpenLocalControlSettings ternaries), added to the useCallback dependency array — the omission that would have made it a stale closure — and set by a real caller (main.tsx in StandaloneApp). So the standalone entry keeps its QR button and only embedded hosts lose it by default, which is the stated intent.
• Docs match the code. The new README sentence claims the entry is controlled by header.showMobileAccess?: boolean, defaults to hidden, applies to both the main chat and split headers, and that main.tsx sets it explicitly — all four hold (?? false, both gates, showMobileAccess: true).
• CI at this head. Every executed product lane is green and fresh against headDate 2026-09-23T09:14:29Z, including web-shell E2E Smoke and Capture web-shell visuals, which are the two lanes that own this surface. action_required = 0 of 30, so this is not a fork-gated phantom green. check-runs 130/130 over 2 pages, staleA = staleB = 0.

Scope of this verdict

The claim is that the green is bound to the diff and that no merge-blocking defect was found in the four production files, read in full at both arms. It is not a claim that the whole repository builds: node_modules and dist are hardlinked from a checkout at a different commit, so the A/B is sound only on the six overlaid paths. README.md was read at patch level, which is not byte-faithful for control-character escapes — no claim here turns on a literal character.