Local verification on e59d0f0a6e (macOS arm64, Node.js 24.19.0): PASS.

The real daemon-backed WebShell rendered the configured larger resource inside its MCP App sandbox; clicking the fixture button changed it to “Interaction verified”. After stopping and restarting the daemon, the saved transcript retained exactly 1,048,577 HTML bytes, rendered the App, and supported the same interaction. Three unedited screenshots are embedded in the PR body; the fixture and screenshots contain only synthetic test data.

Full build + bundle, repository-wide typecheck, four focused suites (347 tests), ESLint, Prettier and diff checks passed. Tests also cover UTF-8/base64 limits, configured boundary/clamping, cancellation, pool isolation, metadata/session tool projections, and worst-case JSON escaping of the final 4 MiB ceiling. Independent review caught a replay-budget risk in the initial larger ceiling; the final ceiling leaves approximately 8 MiB of envelope headroom under the existing 32 MiB replay limit.

Limit of this evidence: the real Amplitude endpoint was contacted but returned 401 invalid_token; OAuth authorization did not complete. No real Amplitude chart or external Data Agent embedding was verified. Local fixture rendering must not be read as a claim of authenticated Amplitude compatibility.

Addressed the review's documentation finding: the pool-key comment now explicitly covers shared tool-snapshot settings and explains why App resource limits must remain in the fingerprint—they are stored during discovery and are not re-projected per session. This follow-up changes comments only.

The pool-fragmentation tradeoff is now recorded in the PR's English and Chinese risk sections. Different configured policies require separate entries for correct isolation; redesigning the per-name budget is outside this resource-loading fix. The request and abort signal intentionally share the same resolved deadline, as already documented and covered by the short-timeout case.

Validation: full repository build and typecheck, 27 pool-key tests, ESLint, Prettier, and a clean diff audit. Existing rendering/replay screenshots and E2E evidence remain applicable because executable code is unchanged.

已修复 review 指出的注释问题，说明 App 限制属于共享工具快照配置，因此必须参与连接池指纹。本次仅修改注释。连接池条目增加的权衡已补入 PR 中英文风险说明；超时信号与 SDK 使用同一截止时间的行为保持不变。全仓构建、类型检查、27 项连接池测试、Lint、格式检查和 diff 自查通过。

Verdict: merge-ready — 828/828 scripted assertions passed, 0 unexpected failures. Verified head: e59d0f0a6e3ad2ba836561f5a5b54c8233c5fccb (single-commit PR; control build = its parent 42f9d13cda, so the A/B differs by exactly this PR).

Central claim and A/B proof

Claim: each MCP server can opt into a larger App HTML limit and a longer App resource-read deadline via appResourceMaxBytes / appResourceTimeoutMs; defaults stay 1 MiB / 10 s; explicit values are clamped to 4 MiB / [100 ms, 120 s]; the general MCP timeout alone must not raise the App deadline.

Method: a real stdio MCP fixture server (fixture-mcp-server.mjs, built on @modelcontextprotocol/sdk, scenario selected via argv) serves a chart tool whose _meta['ui/resourceUri'] points at ui://fixture/chart; resources/read returns HTML of an exact byte size after an exact delay. The driver (drive-cell.mjs) runs the worktree's own compiled packages/core/dist through connectToMcpServer → discoverTools → tool.build({}).execute(signal) — no mocks of the code under test — and records the returned McpAppResultDisplay, elapsed time, and the warning text. Every cell ran identically on both arms; the driver asserts the realpath of @qwen-code/qwen-code-core stays inside the arm's worktree before running.

Every rejection preserved the successful tool result (llmContent still carried chart tool result ok); every head-side timeout warning named the responsible setting key. Matrix: 111/111 assertions passed (matrix-results.json). Witness: 01-ab-matrix-base-vs-head.png —

Secondary claims

• Pool separation. pool-key.mjs runs fingerprint() from each arm's compiled dist on configs differing only in the new fields: head → pool keys differ for both appResourceMaxBytes and appResourceTimeoutMs; base → identical (control proving the probe actually set the fields). Different resource policies cannot share a pooled tool.
• Warnings are actionable. S2/T1 head cells carry mcpServers.<server>.appResourceMaxBytes / .appResourceTimeoutMs in the user-facing warning; the underlying cause is retained via debugLogger.warn ((cause: …)), so no information was suppressed.
• Settings wiring (static census). mcpServers entries arrive as plain JSON objects cast to MCPServerConfig — no new MCPServerConfig(...) in the settings path and no stripping schema (the VS Code companion schema declares mcpServers as additionalProperties: true and never enumerates per-server keys, so there is no schema drift either). The harness sets the limits as plain properties, exactly how settings.json delivers them.

Reviewer Test Plan walk-through

• "1,048,577 bytes: default warns and retains the tool result; 2 MiB renders" → S2/S3, both confirmed. The "remains interactive after transcript replay" half is not covered (WebShell rendering/replay is outside this harness; see below).
• "11-second resource: general 30 s timeout still hits the App cap; explicit 15 s allows; shorter explicit rejects" → T2/T3/T4, all confirmed.
• "Cancel during resource loading aborts the read and preserves the text result; different limits must not share a pooled policy" → C1 + pool-key probe, both confirmed.

Vacuity check (mutation A/B)

Mutation: boundedAppLimit in packages/core/src/tools/mcp-tool.ts replaced to ignore the configured value (interface-preserving; compiles clean). Targeted run of the PR's clamp/bounds tests:

• Mutated: 13 of 17 failed — all 6 bounds the configured resource timeout cases, 5/7 enforces the configured HTML byte boundary cases, both sub-10 s rows of reports the resource timeout with MCP timeout. The 4 survivors are rows whose expectation equals the fallback value (NaN/Infinity → default, mcpTimeout ≥ 10 s → 10 s) — correct pinning, not vacuity.
• Restored: 17/17 pass (control). Witness: 02-mutation-clamp-disabled.png —

Harness artifact worth noting for future rounds, not a product defect: two earlier mutation attempts appeared to "hang" — in fact vitest was rendering megabyte-scale assertion diffs on failed 1 MiB-string comparisons (loads larger configured … compares the full HTML on failure). Orphaned workers from those attempts were killed; the runs above used only small-diff fixtures.

Gates

Findings

None. No blocking or non-blocking findings from the exercised surface.

Not covered

• WebShell rendering, interactivity, and cold-restart transcript replay of the App HTML (the author's own screenshots cover this on macOS; this round verified the core decision layer that admits/rejects the resource).
• Real Amplitude service (out of scope per the PR's own Risk & Scope section).
• Full CLI end-to-end from a settings.json file — the harness injects the limits as plain config properties exactly as the settings loader produces them (static census above); a model-in-the-loop run was not in budget.
• Windows/macOS — this round ran on Linux aarch64 (Orange Pi 6 Plus, Node v24.14.0), complementing the author's macOS run; the changed code is platform-independent.
• Per-commit verification: single-commit PR, aggregate diff verified.

Methodology

Local maintainer-driven round on Linux aarch64 (12-core, Node v24.14.0). Head and control were checked out as sibling worktrees (tmp/head-tree @ e59d0f0a, tmp/base-tree @ 42f9d13cda — the PR's parent, since baseRefOid is stale relative to the PR's single commit); package-lock.json is byte-identical across HEAD, parent, and head, so node_modules was hardlink-copied into both trees and only packages/core rebuilt in each (sibling workspace dists copied identically into both arms — the dependency layer is the same for both cells). The driver asserts realpath(node_modules/@qwen-code/qwen-code-core) resolves inside the arm's own worktree before every cell. Harnesses: fixture-mcp-server.mjs, drive-cell.mjs, run-matrix.mjs, pool-key.mjs (all in this artifact dir, rerunnable); raw per-cell server request logs under server-logs/; cell records in matrix-results.json. Total wall time ≈ 75 min including the 130 s max-clamp cell and the 120 s budget for diagnosing the megabyte-diff vitest wedge.

Maintainer-driven local verification round (/verify-pr protocol). Harnesses, raw logs, and cell records preserved locally under tmp/pr12258-verify-20260919-225033/.

@qwen-code /takeover from 2

🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. This window's round counter starts at 2 (the rounds this PR spent in review before takeover), so the Critical-only brake engages after 3 more change-producing round(s) instead of a full fresh 5. Remove the autofix/takeover label (or comment @qwen-code /takeover stop) to release.

✅ AutoFix round 11 finished — view run. See this round's report below.

🤖 AutoFix updated a stale base — the fix did not pass verification, but this PR was behind main, so it merged current main in via update-branch and will retry on the next scan. A stale base (a dependency or symbol main already changed) can fail the build without being the fix's fault; if it still fails once current, it hands off to a human.

What I found before stopping:
Qwen failed during address-review: status 143.

See the Qwen Autofix agent step logs for model/tool output.

Run log: https://github.com/QwenLM/qwen-code/actions/runs/35470296850

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.24.1

🤖 Addressed the latest review feedback (round 4/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 4/100 轮）。改动内容与我反驳保留之处如下：

Autofix round — PR #12258 review feedback

Commit: 269182b4e8 fix(mcp): Degrade oversized App HTML per historical page document (#12258)

Eight of the nine findings from the CHANGES_REQUESTED review are implemented and verified; the ninth (R1-2, carrying the two keys through the hand-enumerated config surfaces) is deferred to the next round with a reply on its thread — it is the widest change and this round's batch was already at its bound.

Dispositions

• R1-1 (Critical, mcp-tool.ts:775 — 4 MiB ceiling vs five tighter budgets) — Fixed. Historical-page admission in packages/web-shell/client/daemon/session/transcript-page-table.ts now degrades per document instead of failing per page: fitPageWithinBudget blanks every MCP App display's html whole (the documented degrade path — replay mounts the iframe only for non-empty html and never re-fetches the ui:// resource) and re-measures, throwing HistoricalTranscriptPageTooLargeError only when nothing degradable remains. Applied at all three admission sites (sequential, anchored, boundary), with the empty-page branch kept ahead of the fit so its window-full semantics are unchanged. Companion test in turn-navigation-store.test.ts uses the default 16 MiB budget with two 4 MiB mcp_app displays and asserts locateOrdinal resolves with selected.status: 'ready' and the retained blocks carry html: '' with intact fallbackText. The design doc's ceiling rationale (EN + zh-CN) now names all five budgets a retained document crosses, in their own units (16 MiB historical page estimated as UTF-16 code units ×2; 4 MiB compacted replay window; 2 MiB EventBus per-subscriber live frame; 32 MiB JSON restore page; 32 MiB replay envelope) and states the per-document degradation rule.
• R1-2 (Suggestion, mcp-server-config.ts:161 — keys dropped by hand-enumerated config surfaces) — Deferred to the next round (batch bound; widest of the nine). A reply with the planned shape is posted on its thread.
• R1-3 (Suggestion, mcp-tool.ts:821 — warning names a settings path that shadows extension/project servers) — Fixed. appLimitSettingRef prints the mcpServers.<name>.<key> path only for settings-declared servers and otherwise names the declaring extension or .mcp.json; provenance (extensionName, scope) rides the limits object built at discovery, so it survives all tool projections including the reconnect replay leg. Two new tests assert the warning names the declaring source and never the settings path; docs/users/features/mcp.md now says the keys must be set in the source that declares the server because same-named entries replace whole server objects.
• R1-4 (Suggestion, mcp-pool-key.ts:145 — fingerprint hashes raw values while enforcement clamps) — Fixed. New shared module packages/core/src/tools/mcp-app-resource-limits.ts owns the four bounds plus the clamp; the read site and the fingerprint both consume it, so they cannot drift. The key now hashes enforced values: unset ≡ explicit 1 MiB default, over-ceiling values collapse, and a quoted "4194304" hashes like unset (matching its read-site behavior). The timeout arm hashes null for unset/invalid because the effective fallback derives from timeout, which is hashed separately. The over-ceiling appResourceTimeoutMs arm of the isolation test was inverted to in-range values (20 s vs 30 s), and a new test pins the normalization equivalences.
• R1-5 (Suggestion, docs/users/features/mcp.md:497 — guidance omits where App HTML is mounted) — Fixed with one paragraph: App HTML is mounted only in daemon-backed WebShell sessions and in replay of a recorded transcript; terminal and headless sessions render the fallback text, so there the keys change only the warning text, fetch cost/latency, and retained transcript size.
• R1-6 (Suggestion, mcp-tool.ts:846 — timeout warning always names appResourceTimeoutMs) — Fixed. The warning credits the key that produced the deadline, computed with the same finite-number test the clamp uses so a discarded non-numeric override is not credited: appResourceTimeoutMs only when an explicit finite value is set, otherwise timeout (covering both a configured general timeout and the 10 s default). The four mcpTimeout-only table rows now expect mcpServers.<server>.timeout; a new row with an explicit App timeout keeps expecting appResourceTimeoutMs.
• R1-7 (Suggestion, mcp-tool.ts:294 — non-finite configured limit silently discarded) — Fixed. appResourceLimit emits one debugLogger.warn naming the server, the key, the rejected value, and the fallback now in effect; behavior (log, not throw) is unchanged, and the NaN/Infinity fallback-value cases still pass. Both boundary tables gained a quoted-string case plus warn assertions (valid rows assert no discard warn).
• R1-8 (Suggestion, mcp-tool.ts:520 — reconnect/replay propagation leg untested) — Fixed. New test under auto-reconnect on connection error: the first client's callTool rejects with Connection closed, ensureTool resolves a re-discovered tool carrying appResourceUri and a 2 MiB appResourceMaxBytes, and a 1 MiB+1 HTML resource renders through the replay with no warning in fallbackText.
• R1-9 (Suggestion, mcp-pool-key.ts:116 — daemon pool doc contradicts the fingerprint contract) — Fixed. docs/developers/daemon/05-mcp-transport-pool.md now lists the two fields as hashed, retitles the category to transport + shared tool-snapshot settings, and states the rule next to the discoveryTimeoutMs paragraph: a field consumed at discovery and never re-projected per session belongs in the key even when it is not transport-defining. Scoped to the two fields this PR adds; the pre-existing authProviderType/targetAudience/targetServiceAccount list drift is left alone as the finding instructed.

Mutation probes

• R1-1: forced fitPageWithinBudget to fail closed → new degradation test reds; restored → green.
• R1-3: removed the provenance branches → both declaring-source cases red; restored → green.
• R1-4: reverted the fingerprint to raw values → hashes App resource limits at their enforced values reds; restored → green.
• R1-6: made attribution unconditional → exactly the four .timeout rows red, the appResourceTimeoutMs row stays green; restored → green.
• R1-7: silenced the discard warn → all six warned rows (NaN/Infinity/string × bytes/timeout) red; restored → green.
• R1-8: dropped newTool.appResourceLimits from the replay constructor → reconnect replay test reds; restored → green.

Verification

• npm run build — the monolithic command exceeds this runner's 120 s foreground ceiling (and this harness dropped my attempts to raise the timeout or detach it), so I ran every constituent step to green instead: npm run generate, each workspace build in dependency order (browser-use, core, all channels, audio-capture, node-repl, acp-bridge, sdk-typescript, web-shell, web-templates, cli, qwen-live, vscode-ide-companion, chrome-extension, both integrations/), plus node --import tsx/esm scripts/generate-settings-schema.ts (regenerated; no git drift). A partial dist left by a killed run was diagnosed (@qwen-code/web-shell/transcript missing) and repaired by rebuilding web-shell before web-templates/cli.
• npm run typecheck --workspace=packages/core --workspace=packages/web-shell --workspace=packages/sdk-typescript — passed, 0 errors.
• npx tsc -p integration-tests/tsconfig.json --pretty false — passed, 0 errors.
• npx eslint on all 12 changed files — passed, 0 problems. npx prettier --check — one new file reformatted, then clean.
• npx vitest run src/tools (packages/core) — 3792 passed, 1 failed: todoWrite.test.ts expects the default ~/.qwen/todos path, but this runner exports QWEN_HOME=/…/qwen-autofix-review-home; with env -u QWEN_HOME the file passes 57/57. Environmental, unrelated to this diff (those files are untouched).
• npx vitest run client/daemon/session (packages/web-shell) — 992 passed.
• Focused re-run on the committed tree — mcp-tool + mcp-pool-key 171 passed; turn-navigation-store + transcript-page-table 105 passed.

🧭 Gate advisory — this round modified areas outside the PR footprint (machine-measured, not agent-authored):

• packages/web-shell
  Review the expansion deliberately; the footprint gate is in advisory mode. · 本轮改动了 PR 足迹之外的区域（门自动测量，非 agent 文本），当前足迹门为 advisory 模式，请有意识地审阅该扩张。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 8 selected review thread(s). · 已关闭全部选中的 8 条评审线程。

Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.24.1

Local follow-up completed at 4bf5e1864f (two focused fixes):

• R1-1, remaining live-delivery failure: reproduced a 3 MiB App disconnecting the client with one pending progress event, and the symmetric App-first/ordinary-event-next case. Queued consumers now receive the completed fallback text; waiting consumers and the reconnect ring keep the original HTML. App fallbacks that still exceed the byte budget remain rejected. Frame-count and forced-replay rules are unchanged.
• R1-2, configuration loss: both settings now survive TypeScript SDK schema/types, CLI initialization, and daemon settings read/write for stdio, HTTP and SSE. Zero, negative and fractional finite numbers are preserved for the core's existing floor/clamp policy. Existing route ownership and settings scope are unchanged.

Validation: full repository build, bundle and typecheck; 64 bridge + 354 core + 105 WebShell + 796 CLI + 105 SDK tests = 1,424 passed; SDK public-type compiler fence; ESLint and Prettier. New disconnect and configuration tests failed before the fixes and passed afterward. Independent verification exercised seven live-queue scenarios, five historical-page/navigation scenarios, SDK initialization and actual node dist/cli.js --acp settings writes, disk persistence and reads for all three transports. Two clean self-audit passes and independent correctness review found no outstanding blocker in these changes.

The screenshot uses synthetic data and shows a 4 MiB App with subsequent conversation text. The existing pinned historical-window limit can still require navigating to an adjacent turn and back; the real browser verified recovery, so that separate memory-protection behavior was preserved. Authenticated Amplitude rendering remains unverified because OAuth was not completed.

The non-blocking timeout-warning attribution issue is deferred: when the default 10-second cap supplies the deadline, the current warning names the general timeout although raising it cannot override that cap; an explicit App timeout is required. This does not change execution or acceptance behavior. Following the repository's review-scope rule after roughly five rounds, this wording refinement is left out of the two correctness fixes.

本轮已修复剩余实时断连及配置丢字段问题，推送两个独立提交。全量构建、类型检查、1,424 项相关测试和独立本地验证通过；截图为真实 WebShell 上的合成数据。原有历史缓存窗口限制可通过邻近对话导航恢复，保持不变。真实 Amplitude 仍待 OAuth 验证。默认超时警告的归因措辞作为非阻塞改进留待后续，避免本轮继续扩大修复范围。

Authenticated Amplitude follow-up on 224cd3567e:

• Actual OAuth + MCP resources/read: 2,333,981 UTF-8 bytes, identical on two reads; 88.715 s / 79.107 s complete-read durations. 4 MiB is enough for this resource version, while the default 1 MiB / 10 s is insufficient. The Amplitude example now uses 4 MiB / 120 s; the previous 30 s example would fail both measured reads.
• Actual core and bundled CLI accepted the unmodified captured HTML with the override and rejected it with defaults. The accepted HTML's SHA-256 matches the original, including the persisted transcript. Local replay was not used to claim remote timing behavior.
• The real resource executes in WebShell, but displays “Host does not support fetching chart data.” The tool result for this browser test contains a synthetic chart reference, not real analytics; it does not inject chart data to bypass the App's data-fetch path. Full chart compatibility is therefore not fixed or claimed by this PR. App-initiated tool/data requests remain a follow-up; MCP Apps: Amplitude chart UI rejected by fixed 1 MiB HTML limit and 10s resource timeout #11945 explicitly scopes this PR to resource-loading limits.

Only the screenshot is published. OAuth tokens stayed in memory; raw HTML and tool metadata stayed in a private local temporary directory. Temporary test servers were stopped. Documentation-only change: inspected diff and git diff --check; no production code changed after the prior full build/typecheck and 1,424 targeted tests.

已完成真实 OAuth 实测：2.23 MiB，79–89 秒。4 MiB 足以容纳本次资源，文档超时示例修正为 120 秒。真实 HTML 原样通过配置后的 core/CLI 并在 WebShell 运行，但图表仍因宿主缺少数据获取能力而失败；截图明确记录该剩余限制，未声称 Amplitude 完整兼容已修复。

Qwen Code resolved the merge conflicts and pushed the branch update.

Merge resolution — PR #12258 ← origin/main

One conflict, one file: packages/core/src/tools/tool-registry.ts; merge commit 0dcbf8b12a. The merged tree is exactly the union of both sides — git diff HEAD^2 HEAD touches only PR files, git diff HEAD^1 HEAD only main files — and no markers remain.

Root cause

Main picked up #12539 (99fd76553e), which extended a comment inside the inline tool-removal loop of discoverToolsForServer. This PR deleted that loop, delegating to the pre-existing removeMcpToolsByServer() and adding a reconnect flag. Same lines, two edits → conflict. The rest of #12539 auto-merged.

Textual, not semantic

Main changed prose; the PR changed the code that prose described. Delegation is behaviour-preserving because removeMcpToolsByServer is a strict superset of main's loop — same this.tools sweep, same revealedDeferred.delete(name), plus a purge of the PR's new mcpAppTools:

async discoverToolsForServer(serverName: string, reconnect = false) {
  this.removeMcpToolsByServer(serverName);
  // prompts + resources removal unchanged
  await this.mcpClientManager.discoverMcpToolsForServer(
    serverName, this.config, reconnect);
}

That sentence being main's whole edit, I carried it to where the deletion now lives — appended to the existing comment in removeMcpToolsByServer: "…The reviewed-declaration record is deliberately left alone: see reviewedDeferredDeclarations." Nothing else outside the hunk changed.

Load-bearing

• removeMcpToolsByServer / removeDiscoveredTools must keep not touching reviewedDeferredDeclarations: a pruned entry reads as "never reviewed" and waves a replacement tool through — the bug Deferred review findings from PR #10410: feat(core): preserve prompt cache for deferred tools #11321 closed.
• reconnect must stay defaulted false; every pre-existing caller passes one argument.
• The mcpAppTools purge must run before discoverMcpToolsForServer, or a reconnect leaves the previous connection's app-only tools callable.

Not verified

No build, typecheck, lint or tests run here. tool-registry.test.ts auto-merged with new tests from both sides: main's "keeps the reviewed declaration after removal" (~L1147) and "removeMcpToolsByServer also drops revealedDeferred entries" (~L1122) now run against the PR's helper, which also clears mcpAppTools. Both should still hold — those tools are built without appVisibility, so both visibility getters are true — but I did not execute them.

@qwen-code /takeover from 10

🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. This window's round counter starts at 10 (the rounds this PR spent in review before takeover), so the Critical-only brake engages after 0 more change-producing round(s) instead of a full fresh 5. Remove the autofix/takeover label (or comment @qwen-code /takeover stop) to release.

🔀 Base updated: red check(s) [TUI parity snapshots (ink vs opentui), Test (ubuntu-latest, Node 22.x), OpenTUI no-flicker gate, Lint & Static (ubuntu-latest, Node 22.x), Integration Tests (no-AK, No Sandbox), web-shell E2E Smoke (ubuntu-latest, Node 22.x)] pass on current main — merged current main via update-branch; CI will re-run.

R11 follow-up on cab293b: 0d6eb9e fixes the two standing R8 findings, with no new feature scope.

• R8-1: resource timeout warnings now point to the App-specific setting when raising the general timeout cannot exceed the enforced ceiling. Enforced deadlines are unchanged.
• R8-3: failed initialization handoffs revoke the App tool callback, abort calls and close/unload the App. Late failures from an old mount cannot hide or clear its replacement.
• R8-2 was already fixed by cab293b; exactly one sourceSessionId binding remains, and the full build succeeds.

Validation: frozen pnpm installation, full build and bundle, full workspace/integration typechecks, focused lint/format checks, 172 core tests and 38 App component tests passed. Three independent DOM probes passed, including a genuinely pending request cancelled at the component/host-adapter boundary. Minimal temporary mutations proved the new checks fail when the timeout attribution branch or input/result teardown is removed, and when the timeout comparison is inverted. These are core/component checks, not a new vendor or remote browser acceptance run.

R1-1 was rechecked against the exact tree. Replacing a very short HTML payload with a fallback can increase bytes, but the page accounts for the signed byte difference and rejects an over-budget result. Both replay-envelope callers revalidate the serialized envelope after their bounded degradation pass. I found no confirmed budget bypass or unbounded retry; this does not claim every oversized page can be recovered. The truncated unresolved review note provides no additional trigger to reproduce.

The maintainer-reproduced cross-tab HTTP/1.1 wedge remains open, as previously recorded; this commit does not solve it. The event-stream delivery proposal still needs the stated maintainer decision about pre-merge work versus a follow-up. The existing non-critical suggestions remain deferred under the convergence rule, and earlier Amplitude/Tableau evidence retains its original scope. The core change in this round is limited to diagnostic attribution; no timeout or tool-execution policy changed.

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix review round — no change (verification-only)

Head verified: 45c260aad1383a05bc83cd2c3456a781fef3ae56 (merge of main; includes 0d6eb9e2db and cab293b3dd). Working tree was clean before and after this round; no commit was created.

Critical-only mode is active for this window (seeded at round 10 by takeover). This round re-verified every actionable Critical finding against the exact tree and found all of them fixed at HEAD. The failed-checks list is empty. The one remaining functional item is an explicit maintainer decision, which this round deliberately does not settle.

Standing Critical findings — verified fixed at HEAD

R1-1 (aggregate App-HTML budget) — traced at HEAD, no confirmed bypass

The standing "unresolved, please confirm" item was re-traced leg by leg against the exact tree:

• Page assembly (history-replay-page.ts, replayContext.sendUpdate): the overflow pass blanks App html oldest-first using signed byte deltas (serializedUpdateBytes -= old − new), so a replacement that grows the payload (a very short html swapped for the longer omission notice) increases the accounted size instead of hiding it. The loop is bounded by the page length, and a page still over budget after the delivered update itself is degraded throws HistoryReplayLimitError — an explicit failure, not a silently over-budget page.
• Envelope backstop (degradeReplayEnvelopeAppHtml): same signed accounting and bounded loop, and both callers (acpAgent.ts:5924, acpAgent.ts:6100) re-run validateLoadReplayEnvelope immediately afterwards.
• Replay window (compactionEngine.ts): two-phase degrade with signed deltas, eviction as the backstop, newest segment degraded only when eviction cannot make the window fit.
• Live queue (eventBus.ts): degradation only when a nonempty backlog would overflow, and frames with empty fallbackText are never degraded into empty content.
• Historical page (transcript-page-table.ts): html is dropped whole and replaced with the omission notice when the fallback is empty.

No silent over-budget admission, no unbounded loop, and no empty-content frame was found in any leg; a document that cannot be degraded enough fails with an explicit, visible error. This matches the author's R11 recheck. The two related fails-closed hardening notes from rounds 6/8 (newest-segment eviction order; non-shrinking loop exit) sit in this window's deferred audit record and were not touched.

Maintainer items

• Cross-tab connection wedge (maintainer rounds 5–6) — maintainer decision, left open. The per-page cap fixed the single-tab case (maintainer-verified), but the browser's 6-connection-per-host budget is shared across tabs, so 3 tabs × 1 pending App call can still starve the approval request. The maintainer explicitly framed this as his call: merge as-is and track the event-stream delivery (round-4 option (a)) as a follow-up, or require it before merge. This round does not pick a contested structural direction on his behalf; the question stands for @wenshao.
• Cheap follow-ups named by the maintainer — not done this round, reason recorded. F-3 (String.replace $-pattern corruption at the two __HOST_ORIGIN__ substitution sites, mcp-app-sandbox.ts:199,262 — fix is a replacer function), F-2 (refuse new mints at the 256-registration cap instead of evicting), and the live-vs-replay App-call count mismatch. The maintainer classified all three as follow-ups that do not block merge, and this window is Critical-only; growing a merge-ready diff for non-Critical items works against the convergence policy. They remain recorded for the follow-up pass.
• Remote HTTPS full-deployment acceptance remains the author-tracked limitation recorded in the PR description; no new evidence or request arrived in this window.

Deferred non-Critical feedback

The bot Suggestions listed in this window's "Deferred non-Critical feedback" section are an audit record; per the Critical-only brake they were not worked, resolved, or replied to.

Verification

• npm run build — passed (run with COREPACK_HOME=/tmp/corepack-home; the default $HOME corepack cache is not writable in this sandbox).
• vitest run src/tools/mcp-tool.test.ts (packages/core) — 172 passed.
• vitest run client/components/messages/McpApp.dom.test.tsx client/components/messages/McpApp.test.ts (packages/web-shell) — 38 passed.
• vitest run src/serve/mcp-app-sandbox.test.ts src/serve/server/telemetry.test.ts src/serve/server/telemetry-catalog.test.ts (packages/cli) — 88 passed.
• vitest run src/acp-integration/session/history-replay-page.test.ts (packages/cli) — 33 passed.
• vitest run src/eventBus.test.ts src/compactionEngine.test.ts (packages/acp-bridge) — 200 passed.
• vitest run src/bridgeClient.test.ts (packages/acp-bridge) — 149 passed.
• vitest run test/unit/DaemonClient.test.ts (packages/sdk-typescript) — 489 passed.
• npm run typecheck — passed (full workspace, unchanged tree).

Total: 1,169 focused tests passed at the unchanged head. No source or test file was modified; git status is clean.

Deferred non-Critical feedback

Critical-only mode is active: the round counter reached 5 (this window was seeded at round 10 by @qwen-code /takeover from 10, plus 0 change-producing round(s) since). The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (@qwen-code /retry starts a fresh counting window.)

• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)
• PR comment by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (comment)
• PR comment by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (comment)
• PR comment by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (comment)
• PR comment by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (comment)

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 17 selected review thread(s). · 已关闭全部选中的 17 条评审线程。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.24.6

Maintainer verification, round 7 (head 45c260aad1)

Verdict: both new fixes work in a real browser, and nothing regressed. No new blocker. The only open decision is still the cross-tab wedge from rounds 5–6.

• R8-1 fixed. Timeout warnings used to point at mcpServers.<srv>.timeout, which cannot raise the App deadline. They now point at appResourceTimeoutMs. Following the new advice renders the App. The deadlines themselves did not change.
• R8-3 fixed. I injected a failed tool-result handoff. In the build without the fix, the card showed its fallback text, but the hidden App stayed alive. Its own tool call reached the approval panel and ran on the server. With the fix, the iframe is unloaded, no approval appears, and the server runs 0 calls. I found no natural trigger for this failure, so treat it as a defensive fix.
• R8-2 fixed. The build passes. For the first time, an App call from an older turn was checked in a real browser, on the historical page, and it works.
• Round 4–6 results still hold. 5 concurrent App calls: 5/5. MCP crash: 1 restart, no replay. The canary secret does not leak. Data-mode fallback works in Chromium and WebKit.
• Still open, unchanged: the cross-tab wedge (3 tabs × 1 App call: 0/3 executed, 300 s timeout). Triage F-2/F-3 are also unchanged, because mcp-app-sandbox.ts has not changed since round 6.

What changed since round 6

Round 6 tested e6c7a795d0. Since then there are two fix commits and three merges of main: 0dcbf8b12a, 90b0bbd41b and 45c260aad1.

• 52 files are touched only by this PR. The only changes in them are 0d6eb9e2db's 4 files: mcp-tool.ts, McpApp.tsx and their tests.
• 21 files are also changed by main. I compared the PR's own ± lines in them between round 6 and now, ignoring whitespace. Two differences remain:
  • tool-registry.ts (the conflict /resolve fixed): only a comment moved. discoverToolsForServer now calls removeMcpToolsByServer. That function does the same deletions as main's inline loop, and also clears mcpAppTools. Main's fix(core): keep the deferred-tool bridge halves on the same tool #12539 rule is kept: reveal state is dropped, and the reviewed-declaration record is not touched.
  • ChatPane.tsx: main's feat(web-shell): support selective host artifact integration #12588 added the same sourceSessionId={connection.sessionId} prop the PR already had. The merge 90b0bbd41b left two copies, which fails typecheck (TS17001). cab293b3dd removed one. Both copies had the same value, so behavior does not change.

Setup

• Two builds of the same tree (pnpm install --frozen-lockfile, pnpm run build, pnpm run bundle):
  • after: head 45c260aad1.
  • before: the same head with only 0d6eb9e2db's two source files reverted, so the source trees differ only in those files. In the bundles, the core ceiling branch appears 1 time vs 0, and the web-shell oncalltool=void 0 appears 2 times vs 0.
• Browser and chain: Chromium 149 (Playwright 1.61.1) on macOS arm64. Browser → bundled WebShell → dist/cli.js serve on 127.0.0.1 → ACP child → a real stdio MCP server built on the official @modelcontextprotocol/ext-apps App SDK.
• Scripted parts: only the model's tool choice. Every approval was a real click in the approval panel.
• Rig: the round-5 rig, plus two new App variants:
  • a slow resource whose resources/read takes 12 s;
  • a self-calling App that calls its App-visible tool stable_app_tool on its own 5 s after connecting.
• Scripts, per-run result.json files and the mutation results are under pr-12258-round7/.

1. R8-1: the timeout warning now names the setting that can change the deadline

Each server points at the same slow resource. Only its config differs.

The fixture's ledger shows the server-side abort in each case. Reads aborted at 10 000–10 003 ms or 5 001 ms, and both builds give the same numbers. So only the text of the warning changed.

2. R8-3: a failed handoff now tears the App down (fault injection)

Can this happen naturally? The host sends sandbox-resource-ready, tool-input and tool-result as one-way postMessage notifications, and their payloads are JSON. A handler that throws inside the App cannot reject them on the host side. So I found no way to make them fail in a real run.

Injection: I patched the served WebShell bundle so that the host's PostMessageTransport.send throws for ui/notifications/tool-result. This is the "transport errors" trigger named in R8-3. Both builds got exactly the same patch.

Not checked in a browser: the "stale failure after a remount" case. The unit tests cover it, and mutation M3 below confirms the test catches it.

3. R8-2 and the historical page

After the App turn, I added 12 turns of 900 KB each and reloaded. The App turn fell outside the live window (0 live cards). Opening turn 2 from the session timeline gave the historical viewport. There:

• the App rendered;
• the host advertised serverTools;
• stable_app_tool asked for approval and ran once;
• the historical page showed 0 feedback buttons.

Round 4 could only check this path with unit tests.

4. Round 4–6 cases on the new head

5. Tests and mutation

• Focused suites on head: 861/861 passing.
  • core mcp-tool, tool-registry: 251
  • web-shell McpApp: 38
  • web-shell TranscriptViewport.mcp-app, ChatPane: 175
  • CLI mcp-app-sandbox, history-replay-page: 48
  • acp-bridge eventBus, compactionEngine, bridgeClient: 349
• CI on 45c260aad1 is green.
• Mutations on 0d6eb9e2db's code: 6 of 10 were killed.

M9 and M10 are cheap follow-up tests. Neither blocks the merge: a connect() failure is rare, and cleanup also aborts and closes the bridge.

Not covered this round

• No real vendor run (Tableau Cloud or Amplitude) and no remote HTTPS run.
• WebKit was only re-run for the data-mode case.
• Triage F-2/F-3 and the live-vs-replay App-call count mismatch were not re-run. Their code is unchanged since round 6, and they remain follow-ups.

Merge reference

• Nothing new blocks the merge. R8-1, R8-2 and R8-3 are fixed as described. The merges of main changed none of the PR's behavior.
• The open decision is the same as rounds 5–6: the cross-tab wedge. One option is to merge and track event-stream delivery (round-4 option (a)) as a follow-up. The other is to require it before merge.
• Cheap follow-ups: tests for M9/M10, the F-3 replacer function and the F-2 refuse-when-full rule.
• The review decision is still CHANGES_REQUESTED, from the bot's earlier review.

Earlier rounds: round 5, round 6.

@qwen-code /triage

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix round: no code change

Head reviewed: 45c260aad1 (matches origin/codex/amplitude-mcp-app-limits; working tree clean).

What the actionable feedback contains

The only item in this round's actionable sections is @wenshao's round-7 maintainer verification (issue-level comment ic:5852089456). It is a verification report, not a change request:

• R8-1 fixed — timeout warnings now name appResourceTimeoutMs; verified in a real browser across five server configs, with server-side abort ledgers confirming only the warning text changed.
• R8-3 fixed — under fault injection (host PostMessageTransport.send throwing for tool-result), the failed App is now torn down: iframe unloaded, no approval shown, 0 server executions, versus the pre-fix build where the hidden App stayed alive and ran a tool call after approval.
• R8-2 fixed — an App call from an older turn was exercised for the first time in a real browser on the historical page: renders, advertises serverTools, runs once after approval, no feedback buttons.
• Round 4–6 results still hold on the new head: 5/5 concurrent App calls, one MCP restart with no replay after a crash, no canary-secret leakage, isolation probes blocked, data-mode fallback working in Chromium and WebKit.
• 861/861 focused tests pass; CI on 45c260aad1 is green. Mutation run on the latest fix commit killed 6 of 10 mutants; the 4 survivors were judged practically equivalent (M5, M7) or cheap non-blocking test gaps (M9, M10).
• The two merge-conflict resolutions since round 6 (tool-registry.ts, ChatPane.tsx) were re-verified as behavior-preserving.

There are no inline comments, no review bodies, and no failed or still-red checks in this round's actionable sections.

Why no code change was made

1. No new blocker and no new defect claim. The verification explicitly concludes "both new fixes work in a real browser, and nothing regressed. No new blocker." Nothing in the actionable feedback reproduces a correctness, security, build, or test defect against the current head, so there is no Required item to fix, and a probe would have nothing to reproduce.

2. Critical-only mode is active. The deterministic brake has engaged (window seeded at round 10). The items the maintainer names as remaining work — tests for mutations M9/M10, the F-3 replacer function, the F-2 refuse-when-full rule — are explicitly categorized by the maintainer as "cheap follow-ups" that do not block the merge, and F-2/F-3 touch mcp-app-sandbox.ts, unchanged since round 6. Under critical-only mode these stay deferred to follow-up rather than growing this PR.

3. The deferred ci-bot comment is an audit record. Per the critical-only rules it was excluded from this round's actionable sections, so no code, thread resolution, or reply was produced for it.

Open decision that needs a maintainer (unchanged from rounds 5–6)

The cross-tab wedge: 3 tabs × 1 App call → 0/3 executed, 300 s timeout; at 6 s, 3 session event streams and 3 POST …/mcp-app/tools/call requests remain open. This is a reproduced defect, but the maintainer has held it as an explicit merge decision for three consecutive rounds:

• Option A: merge now and track the event-stream delivery fix (round-4 option (a)) as a follow-up.
• Option B: require the cross-tab fix before merge.

This choice is a scope/product judgment, not an autonomous one: option (a) is a daemon event-stream delivery change in core infrastructure, and implementing it unilaterally in a critical-only round would contradict both the brake and the maintainer's framing. The recommendation from the evidence at hand is Option A — every verified behavior on the head passes, the wedge has a narrow multi-tab trigger, and the maintainer's own round-7 verdict records no new blocker — but the call belongs to the maintainer. It is left open here so it reads as an explicit question, not a verdict this round already reached.

State checks performed

• git status — clean; branch up to date with origin/codex/amplitude-mcp-app-limits.
• git log / git diff origin/main...HEAD --stat — confirmed head 45c260aad1 and PR footprint (73 files, +5839/−428) for context; no files were modified this round.
• No build, typecheck, lint, or test runs were needed: no code changed.

Deferred non-Critical feedback

Critical-only mode is active: the round counter reached 5 (this window was seeded at round 10 by @qwen-code /takeover from 10, plus 0 change-producing round(s) since). The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (@qwen-code /retry starts a fresh counting window.)

• PR comment by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (comment)

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.24.6

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix round — no action taken

No changes were made in this round. There was nothing actionable to address:

• Critical-only mode is active. The workflow's deterministic brake has engaged for this PR (the counting window was seeded at round 10 by @qwen-code /takeover from 10, and the round counter has reached 5). All remaining feedback was deterministically deferred and appears only in the audit-only Deferred non-Critical feedback section of the prepared feedback, which this bot does not act on: one non-Critical review from @qwen-code-ci-bot, plus a notice that @wenshao's regular-feedback budget for this window is spent.
• No Critical feedback. The actionable sections (reviews, inline comments, issue-level comments) contained no items.
• No failed checks. All CI checks on the current head are green (SUCCESS) or legitimately SKIPPED/CANCELLED; there are no failed or still-red checks to diagnose.
• No base-conflict resolution was requested (--conflict false), so no merge of origin/main was performed.

To resume automated handling of the deferred non-Critical feedback, a maintainer can start a fresh counting window by commenting @qwen-code /retry on the PR, or escalate a specific item by prefixing a comment with [Critical] or submitting a Request changes review.

Verification

No code changes were made, so no build, typecheck, lint, or test runs were required. The round's inputs were verified as follows:

• Read the prepared feedback for this round — actionable sections (reviews, inline comments, issue-level comments, failed checks, still-red checks) are all empty; only the audit-only deferred section is present.
• Inspected the raw CI check rollup for the current head — every check reports SUCCESS, SKIPPED, or CANCELLED (the cancelled entries are superseded route jobs); no FAILURE state exists.
• git status --porcelain on the PR head branch is clean; the working tree was left untouched.

Deferred non-Critical feedback

Critical-only mode is active: the round counter reached 5 (this window was seeded at round 10 by @qwen-code /takeover from 10, plus 0 change-producing round(s) since). The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (@qwen-code /retry starts a fresh counting window.)

• Review by @qwen-code-ci-bot: fix(mcp): Support larger Apps, scoped tool calls and isolated origins #12258 (review)

• @wenshao is at this window's regular-feedback budget — to continue: start your comment with [Critical], submit a Request changes review, or comment @qwen-code /retry for a fresh window. / @wenshao 本窗口常规反馈预算已用完——继续请以 [Critical] 开头评论、提交 Request changes、或评论 @qwen-code /retry 开新窗口。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.24.6

@qwen-code /triage

R12 recheck: this PR was merged at 2026-09-27 04:56:49 UTC as 81c260b. The final PR head is 45c260a.

I checked the latest reviews and verification reports, the final CI rollup, and the four files from 0d6eb9e against the final head. Those four files are unchanged. CI has 33 successful checks, 165 skipped checks and two cancelled superseded route jobs, with no failed or pending check. R8-1 and R8-3 have explicit fixed rulings; the maintainer's round-7 report independently confirms both fixes in a real browser, including that failed Apps no longer execute tool calls. The latest sandbox round reports 105/105 executed assertions and no new blocking finding.

No code change or new test run was needed in this recheck. This does not close the known cross-tab HTTP/1.1 wedge: the current limiter is per page, and cross-tab-safe delivery remains follow-up work. The event-stream proposal should preserve client-targeted private App results and cancellation. The previously deferred Low findings F-1/F-2/F-3/F-5 also remain open; merge and green CI do not mean those have been fixed. Earlier vendor/remote evidence retains its original scope.