[qqqys]

What this PR does

Bundled Generated UI is now offered only to sessions whose client can render MCP Apps. The daemon's ACP bridge, whose sessions Web Shell and Desktop display, declares an MCP App host capability when it connects to the agent, and the agent marks those session configs as MCP App hosts before initialization. Every other session, including the interactive TUI, qwen -p and other headless runs, editor ACP clients and channels, reports a new unsupported-client reason and receives neither the generated_ui_show tool nor the writer skill. This includes channels the daemon runs: their sessions come through the daemon bridge, but carry the channel source, and their users read replies in the IM client.

unsupported-client is an expected state, so it does not produce a startup warning. This also removes the misleading "Bundled Generated UI is unavailable (unsupported-runtime)" line the daemon printed at every start even though its sessions had Generated UI enabled.

Why it's needed

With experimental.generatedUi on, every trusted local session received the tool and skill. In clients that cannot show a card, the model still used them: a real qwen -p run (qwen3.8-max) loaded the skill, called generated_ui_show, and finished with "the interactive splitter is ready, drag the sliders in the card above", although the terminal has no card. This blocks turning the experimental setting on by default, and #14019 requires that CLI/headless clients not receive a Web Shell-only experience.

Reviewer Test Plan

How to verify

1. Enable experimental.generatedUi in user settings in a trusted workspace.
2. Run qwen -p "<a request to adjust a bill split interactively>" --output-format stream-json. The stream should contain no generated-ui skill load and no mcp__generated-ui__generated_ui_show call, and the answer should not refer to a card.
3. Start qwen serve, open Web Shell and make the same request. The session status reports generatedUi: { version: 1, enabled: true } and the model can show the card.
4. The daemon log should no longer contain "Bundled Generated UI is unavailable (unsupported-runtime)" at startup.

Unit coverage: core config (unsupported-client status for non-host clients and daemon-created channel sessions, no warning, setting-disabled still reported first, provider withheld), acpAgent (the setter is called before initialize only when the client advertises qwen.mcpAppHost), acp-bridge handshake capabilities, and MCP client manager fixtures that now declare an MCP App host.

Evidence (Before & After)

Same settings, model and prompt (聚餐分账：菜品总价 924 元，6 个人平分。我想在对话里直接拖动/输入人数、优惠金额和服务费比例，实时看到总价和每人应付。不需要写文件。), qwen -p --output-format stream-json:

	Before (e67cb4a8b4)	After
Tool calls	skill generated-ui, tool_search, mcp__generated-ui__generated_ui_show	no Generated UI skill or tool
Final answer	"已生成交互式分账计算器，可以直接在上方卡片里拖动滑块或输入数值。"	a text answer without a card reference

Web Shell sessions on the same daemon still report generatedUi: { version: 1, enabled: true } and render the card.

Targeted tests: packages/core config/skills/MCP suites (1480 passed), packages/acp-bridge bridge.test.ts (1023 passed), packages/cli acpAgent MCP App host and Goal proposal cases (9 passed).

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

Local bundle (npm run build && npm run bundle), isolated HOME, qwen serve with Web Shell and qwen -p, model qwen3.8-max.

Risk & Scope

• Main risk or tradeoff: the capability belongs to the connection that creates the session. A daemon session viewed only through the SDK still receives the tool and shows the readable summary there; sessions created by direct ACP clients never receive it.
• Not validated / out of scope: making the setting default-on, and the Generated UI presentation and model-guidance changes that follow in later steps of feat(web-shell): complete experimental intelligent UI with stateful interactions #14019.
• Breaking changes / migration notes: users who enabled the setting and used Generated UI through a non-daemon ACP client lose it there; those clients could not render the card.

Linked Issues

Part of #14019.

中文说明

这个 PR 做了什么

内置 Generated UI 现在只提供给能渲染 MCP App 的客户端所在的会话。daemon 的 ACP bridge（Web Shell 和 Desktop 显示的就是它的会话）在连接 agent 时声明自己是 MCP App 宿主，agent 在初始化前把这些会话的配置标记为 MCP App 宿主。其他会话，包括交互式 TUI、qwen -p 及其他 headless 运行、编辑器 ACP 客户端和频道，都会报告新的 unsupported-client 原因，既拿不到 generated_ui_show 工具，也拿不到写作技能。

unsupported-client 是预期状态，因此不会产生启动警告。这也去掉了 daemon 每次启动都会打印的误导性日志 "Bundled Generated UI is unavailable (unsupported-runtime)"——实际上它的会话是启用了 Generated UI 的。

为什么需要

开启 experimental.generatedUi 后，每个受信任的本地会话都会拿到工具和技能。在无法显示卡片的客户端里，模型照样会用：一次真实的 qwen -p 运行（qwen3.8-max）加载了技能、调用了 generated_ui_show，最后回复"已生成交互式分账计算器，可以直接在上方卡片里拖动滑块"，而终端里根本没有卡片。这会阻碍把这个实验设置默认开启；#14019 也要求 CLI/headless 客户端不能收到只在 Web Shell 可用的体验。

审阅者测试计划

如何验证

1. 在受信任的工作区中，于用户设置里开启 experimental.generatedUi。
2. 运行 qwen -p "<一个想交互式调整分账的请求>" --output-format stream-json。输出中不应有 generated-ui 技能加载，也不应有 mcp__generated-ui__generated_ui_show 调用，回答也不应提到卡片。
3. 启动 qwen serve，在 Web Shell 中提同样的请求。会话状态报告 generatedUi: { version: 1, enabled: true }，模型可以展示卡片。
4. daemon 启动日志中不应再出现 "Bundled Generated UI is unavailable (unsupported-runtime)"。

单元测试覆盖：core 配置（unsupported-client 状态、无警告、setting-disabled 仍优先报告、不注入 provider）、acpAgent（只有客户端声明 qwen.mcpAppHost 时才在 initialize 之前调用 setter）、acp-bridge 握手能力，以及 MCP client manager 中现在需要声明 MCP App 宿主的测试夹具。

证据（修改前后）

相同设置、模型和提示词（聚餐分账：菜品总价 924 元，6 个人平分。我想在对话里直接拖动/输入人数、优惠金额和服务费比例，实时看到总价和每人应付。不需要写文件。），qwen -p --output-format stream-json：

	修改前（e67cb4a8b4）	修改后
工具调用	skill generated-ui、tool_search、mcp__generated-ui__generated_ui_show	没有 Generated UI 技能或工具
最终回答	"已生成交互式分账计算器，可以直接在上方卡片里拖动滑块或输入数值。"	纯文字回答，不提卡片

同一个 daemon 上的 Web Shell 会话仍报告 generatedUi: { version: 1, enabled: true } 并能渲染卡片。

定向测试：packages/core 配置/技能/MCP 相关测试（1480 通过）、packages/acp-bridge bridge.test.ts（1023 通过）、packages/cli acpAgent 中 MCP App 宿主与 Goal proposal 用例（9 通过）。

测试平台

OS	状态
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

环境（可选）

本地 bundle（npm run build && npm run bundle）、隔离的 HOME、qwen serve 配合 Web Shell，以及 qwen -p，模型 qwen3.8-max。

风险与范围

• 主要风险或取舍：能力属于创建会话的那条连接。只通过 SDK 查看的 daemon 会话仍会拿到工具，在那里显示可读摘要；由直连 ACP 客户端创建的会话永远拿不到。
• 未验证 / 不在范围内：把设置改为默认开启，以及 feat(web-shell): complete experimental intelligent UI with stateful interactions #14019 后续步骤中的 Generated UI 展示和模型引导改动。
• 破坏性变更 / 迁移说明：开启了该设置并通过非 daemon 的 ACP 客户端使用 Generated UI 的用户会在那里失去它；这些客户端本来也无法渲染卡片。

关联 Issue

属于 #14019 的一部分。

[wenshao]

Verdict: merge-ready — 35/35 scripted assertions at head f6a2297a30b0facb70976797a6a55d8fc149eeb0 (base d60124ad266058b46c3d88b1a929158f4125b2af). The central claim is load-bearing on a real build: qwen -p loses the Generated UI skill and mcp__generated-ui__generated_ui_show at head while daemon sessions keep both, and the daemon startup warning is gone. Two non-blocking test-coverage gaps are reported below.

中文摘要

结论：merge-ready（35/35 条脚本断言全部通过）。 验证对象：head f6a2297a，base d60124ad（merge-base；PR 落后 main 6 个提交）。

中心主张 A/B（真实构建 + 真实 qwen -p / qwen serve，模型侧用本地假 OpenAI 端点）：

• headless（qwen -p）：base 在系统提示词里提供 generated-ui 技能，tool_search 能取到 mcp__generated-ui__generated_ui_show 的完整 schema；head 两者都没有（返回 Not found: ...）。
• daemon（qwen serve + Web Shell 会话）：两臂都返回 generatedUi: {version:1, enabled:true}，技能与工具都可发现——补齐能力没有把 Web Shell 的 Generated UI 一起关掉。
• 启动日志：base 的 daemon 每次启动打印 Bundled Generated UI is unavailable (unsupported-runtime)，head 为 0 次。

trial merge（main tip 57f4bd14 + PR 补丁 10 文件，3-way 干净应用）： 三格行为与 head 完全一致；门禁 975 / 1023 / 17 / 3 全绿，与 head 同值。

变异矩阵： M1（客户端门禁）、M2（告警抑制）、M3（acpAgent setter）、M4（bridge 能力声明）、M7（同文件对照）均被杀；M5（状态白名单新增 unsupported-client）与 M6（reason 表达式重排）幸存——属覆盖缺口，非阻塞建议，见 Findings F1/F2。

CI： 实质代码 lane（ubuntu 单测、lint、无 AK 集成、Web Shell smoke、OpenTUI）全绿；其余红点是 cancelled 的 job 与两个 gh: Bad credentials (401) 的自动化 job，没有代码级测试失败。

未覆盖： 真实模型下的自主行为（模型是否真去用卡片）、Web Shell 的 DOM 渲染、managed/hosted 会话、只通过 SDK 查看的 daemon 会话、Windows/macOS 渲染，以及全仓测试。

What the PR claims

Generated UI (the bundled MCP App provider) becomes conditional on the client being able to render MCP Apps. The daemon ACP bridge declares qwen.mcpAppHost: true in its handshake; the agent marks that session's config before initialization; every other client (interactive TUI, qwen -p, editor ACP clients, channels) reports the new unsupported-client reason and receives neither the generated_ui_show tool nor the writer skill. unsupported-client is silent, which also removes the misleading daemon startup warning.

A/B proof of the central claim

Both arms are separate worktrees built from this repository, driven as real processes. The model side is a local OpenAI-compatible endpoint, so the observable is the actual wire payload the product sends; the probe scripts the model to call tool_search for the tool by exact name and then reads the returned tool result.

cell	observable	base d60124ad	head f6a2297a
headless qwen -p, experimental.generatedUi: true	generated-ui skill in the request context	offered	withheld
headless qwen -p, setting on	tool_search select:mcp__generated-ui__generated_ui_show	full schema returned	Not found
headless qwen -p, setting off	skill / tool	absent / absent	absent / absent
daemon qwen serve, session created over the bridge	generatedUi receipt	{version:1, enabled:true}	{version:1, enabled:true}
daemon session	skill in the request context	present	present
daemon session	tool_search for the tool	full schema returned	full schema returned
daemon startup log	Bundled Generated UI is unavailable	1 occurrence	0 occurrences

The headless row is the defect the PR fixes: at base the tool and the skill are offered to a terminal that cannot render a card; at head they are not. The daemon rows are the positive control that the gate did not simply disable the feature: the capability plumbing reaches the child, the session still reports enabled: true, and the tool is still discoverable. The setting-off rows show the pre-existing gate still wins.

Capture: 01-ab-table.png (A/B cells) and 03-daemon-warning-ab.png (daemon startup log). Raw observations: obs/base.json, obs/head.json; harness harness/run-arm.mjs.

Findings

F1 — unsupported-client is not pinned in the bridge status allow-list (Suggestion, non-blocking)

packages/acp-bridge/src/session-control-plane.ts adds reason === 'unsupported-client' to the allow-list that decides whether a generatedUi reason survives the daemon's status relay. No test covers that new entry.

Measured: deleting exactly that clause leaves src/generated-ui.test.ts green (17/17). The same selection kills a mutant of an already-allow-listed reason (policy-disabled, 4 tests red), so this is a genuine gap rather than a dead harness.

Consequence: if the clause is later removed, the daemon silently drops the reason from the receipt and _meta; the Web Shell would still show its generic "not enabled in this session" text, but SDK/protocol consumers lose the diagnostic that distinguishes "this client cannot render" from "the runtime is unsupported". Suggested fix: add one reason: 'unsupported-client' case to generated-ui.test.ts mirroring the existing policy-disabled fixture.

Reproduce:

cd packages/acp-bridge && npx vitest run src/generated-ui.test.ts
# 17/17 green with and without the unsupported-client clause

F2 — the reason-precedence restructure is untested (Suggestion, non-blocking)

initializeBundledGeneratedUi was restructured so unsupported-runtime is only reported when the client is an MCP App host; otherwise the client check wins. Restoring the pre-PR expression leaves the targeted core test green (1/1).

The behavioural delta is real but narrow: a config with skipSkillManager or disableBundledGeneratedUi and a non-MCP-App client now reports unsupported-client instead of unsupported-runtime. That covers the transcript-replay config and the hosted harness/compression configs, none of which expose this status to an end user today, so this is documentation of an unpinned decision rather than a defect. If client-first is intended, pin it with a case that sets both flags.

Reproduce:

cd packages/core && npx vitest run src/config/config.test.ts -t 'clients that do not render MCP Apps'

Trial merge on current main

main moved 6 commits past the merge-base and touched three of the PR's files (acpAgent.ts, acpAgent.test.ts, session-control-plane.ts). The PR's 10-file patch (git diff d60124ad..f6a2297a) applies to main tip 57f4bd14 with git apply --3way cleanly, and the merged tree was built and driven through the same harness:

observable	head	trial merge
headless skill / tool	withheld / not found	withheld / not found
daemon generatedUi	enabled: true	enabled: true
daemon skill / tool	present / discoverable	present / discoverable
daemon startup warning	0	0
core/src/config/config.test.ts	975 passed	975 passed
acp-bridge/src/bridge.test.ts	1023 passed	1023 passed
acp-bridge/src/generated-ui.test.ts	17 passed	17 passed
cli/acpAgent.test.ts -t 'declares an MCP App host'	3 passed	3 passed

Capture: 04-trial-merge.png.

Mutation matrix

mutation	selection	baseline	outcome
M1 delete the mcpAppHostSupported gate	config.test.ts -t 'clients that do not render MCP Apps'	1 passed	KILLED
M2 re-enable the warning for unsupported-client	same	1 passed	KILLED
M3 drop the setMcpAppHostSupported(true) plumbing	acpAgent.test.ts -t 'declares an MCP App host'	3 passed	KILLED
M4 drop 'qwen.mcpAppHost': true from the bridge handshake	bridge.test.ts -t 'negotiates the capability…'	1 passed	KILLED
M7 control: drop policy-disabled from the same allow-list	generated-ui.test.ts (17 tests)	17 passed	KILLED
M5 drop unsupported-client from the allow-list	generated-ui.test.ts	17 passed	SURVIVED (F1)
M6 restore the pre-PR reason expression	config.test.ts -t …	1 passed	SURVIVED (F2)

Both survivors are same-file controls or covered by one (M7), so they are coverage gaps, not harness failures; neither changes runtime behaviour of the shipped code. Capture: 02-mutation-matrix.png.

CI state at the verified head

The substantive lanes ran and passed on f6a2297a: Test (ubuntu-latest, Node 22.x), Lint & Static, Integration Tests (no-AK, No Sandbox), web-shell E2E Smoke, OpenTUI no-flicker, Managed Agent gate, Check TUI impact. The red checks are not test failures: verify, tmux-testing, triage, authorize, review-pr, Installed npm global and npx and the Node 26/Bun acceptance job are cancelled; precheck-pr and fallback-comment fail on gh: Bad credentials (HTTP 401). Test (macos-latest) is a skipped matrix entry.

Not covered

• Real-model behaviour. The model side is a fake OpenAI endpoint. Tool/skill availability is measured on the wire; whether a real model would have used the card, and whether its prose still mentions one, is not re-run here (the PR body has that evidence for qwen3.8-max).
• Web Shell DOM rendering. Only the session receipt and tool availability are measured; the MCP App card UI itself is not rendered in a browser this round.
• Managed / hosted sessions. Only the trusted local daemon path is driven.
• SDK-only daemon clients. The PR states these still receive the tool (the capability belongs to the connection that creates the session). That tradeoff was not exercised.
• Interactive TUI and editor ACP clients. They share the same code path as headless (no qwen.mcpAppHost), but only qwen -p was driven end to end.
• Windows/macOS rendering differences, the full repository suite, and typecheck (the PR's own CI ran lint and the ubuntu unit lane).
• Mixed-version bridge/CLI pairs. Relevant to F1: an older bridge dropping the new reason from a newer child's status was reasoned about, not executed.

Methodology

Two detached worktrees: base at the merge-base d60124ad, head at f6a2297a; head installed with corepack pnpm install --frozen-lockfile (lockfile identical at base, head and main tip), base seeded by hard-linking that node_modules, with readlink -f node_modules/@qwen-code/qwen-code-core asserted into each tree. Both built with Node 22.23.4 and an 8 GB heap. A third worktree at main tip 57f4bd14 received the PR's effective patch via git apply --3way and was built the same way. Each arm ran real node packages/cli/dist/index.js -p … --output-format stream-json and qwen serve processes with an isolated HOME/QWEN_HOME; the fake endpoint recorded every model request, and the harness read the tool_search tool result from the follow-up request. Raw logs are in obs/, the harness and mutation specs in harness/ and mutations.json.

[yiliang114]

APPROVE — zero P0/P1 findings

The gate is the right one: rendersMcpApps() chains mcpAppHostSupported (declared by the ACP bridge at handshake) with sessionSourceType !== 'channel' (excluding IM-bot sessions that travel through the same daemon bridge but whose users never see a card). Every other session — TUI, headless, editor ACP, channels — receives unsupported-client, which is an expected state and produces no startup warning.

Mechanisms verified at head f05832ee

1. Call-ordering guard. acpAgent.ts reads clientCapabilities._meta['qwen.mcpAppHost'] and calls config.setMcpAppHostSupported(true) before config.initialize(). The test asserts invocationCallOrder to catch any reordering that would leave the flag unset when initializeBundledGeneratedUi reads it.

2. Reason priority. generatedUiUnavailableReason() checks setting-disabled first, then rendersMcpApps() (→ unsupported-client), then the runtime/workspace/provided gates. A disabled setting correctly shadows the client check (unit-tested).

3. Warning suppression. Both setting-disabled and unsupported-client skip the warning, so the daemon no longer prints the misleading "Bundled Generated UI is unavailable (unsupported-runtime)" line at every start.

4. unsupported-runtime narrowing. initializeBundledGeneratedUi now only returns unsupported-runtime when the setting is enabled AND the client does render MCP Apps AND the options disable it — the old ternary would fire it unconditionally when disableBundledGeneratedUi || skipSkillManager was set. The real reason for a non-MCP-app client was always the client, not the runtime.

5. Session control plane. session-control-plane.ts adds unsupported-client to the filter list alongside the other inactive reasons, so the feature flag reports correctly.

Test coverage

• config.test.ts: unsupported-client for non-host clients, channel sessions, setting-disabled priority.
• acpAgent.test.ts: three-way it.each (true→called, false→not-called, undefined→not-called) with ordering check.
• bridge.test.ts & channel-handshake.ts: capabilities include qwen.mcpAppHost.
• mcp-client-manager.test.ts: fixture declares host support before initializeBundledGeneratedUi.

No P2/P3 findings.

中文

门控正确：rendersMcpApps() 将 ACP bridge 握手时声明的 mcpAppHostSupported 与 sessionSourceType !== 'channel' 串联，排除了走同一 daemon bridge 但用户在 IM 客户端读回复的频道会话。其他会话（TUI、headless、编辑器 ACP、频道）统一拿 unsupported-client，此状态不产生启动警告。

已核机制：

1. acpAgent 在 config.initialize() 前调用 setMcpAppHostSupported(true)，测试用 invocationCallOrder 守序。
2. 原因优先级：setting-disabled → unsupported-client → runtime/workspace 等，有单元测试验证 setting-disabled 优先。
3. unsupported-client 和 setting-disabled 均不产生警告，daemon 不再误打 log。
4. unsupported-runtime 收窄为「设置启用 + 客户端能渲染 MCP App + 选项禁用」三个条件同时成立才触发。
5. session-control-plane 过滤器补上了 unsupported-client。

零 P0/P1/P2，测试覆盖充分。

[qwen-code-dev-bot]

APPROVE — 审查版本 head f05832ee（提交前后两次读取一致）。

• 历史 Review：本 PR 没有正式 GitHub Review 记录；仅有 verify 报告（针对 f6a2297a，结论 merge-ready），其 F1（unsupported-client 进入 bridge 状态 allow-list 未加用例）与 F2（reason 优先级重排未加用例）均被报告方明确标注为非阻塞覆盖缺口，不影响正确性、安全或兼容性，按 Suggestion 处理。最新提交 f05832ee 已为频道会话门禁补了对应用例。
• CI：head 上唯一 required check Lint & Static (ubuntu-latest, Node 22.x) success；ubuntu 单测、no-AK 集成、web-shell E2E smoke、OpenTUI no-flicker、TUI parity、Managed Agent gate、linux x64/arm64 npm 安装、Node26/Bun 验收均 success。两个非 required 的 Installed npm global and npx (darwin-x64/arm64) 自 08:01Z 起排队未启动（同仓 Test (macos-latest) 也被 skip），属 macOS runner 基础设施问题，且本 PR 未触及打包路径。
• 独立检查未发现新 Critical：客户端门禁是唯一决策点，bundledGeneratedUiActive / getBundledGeneratedUiStatus() 的全部消费方（merged MCP servers、bundled skill 过滤、isBundledGeneratedUiServer、mcp-tool 可见性）都读同一状态；setMcpAppHostSupported 位于共享的 newSessionConfigInRuntimeContext，在 setSessionSource 之后、initialize() 之前执行，new/load/resume 路径一致；daemon 频道会话由 packages/cli/src/commands/channel/daemon-worker.ts 传 sourceType: 'channel'，被 rendersMcpApps() 正确排除；新 reason 已同时加入 BundledGeneratedUiStatus 类型联合与 session-control-plane.ts 的 allow-list，仓库内不存在遗漏该枚举值的 reason→文案映射；告警抑制仅限 setting-disabled 与 unsupported-client，setting-disabled 仍优先于客户端判定。

[qwen-code-review-bot]

Released in v0.26.3.