fix(export): stop embedding the Web Shell runtime in every HTML file

[yiliang114]

What happened?

The current /export html architecture embeds the complete browser dependency graph reachable from WebShellTranscript into every exported file. The generated document is about 19.5 MB even for an empty session because the same React and Web Shell runtime is copied into each export.

Measured with equivalent empty-session data:

• Earlier lightweight export: 311,990 bytes
• Current Web Shell document export: 19,526,066 bytes raw / 4,772,314 bytes gzip
• Raw size increase: about 62.6x
• A real one-turn TUI /export html file: 19,527,461 bytes

Most of this payload is identical across exports, making the default output unnecessarily expensive to store, attach, and share. This issue is about correcting the distribution model rather than attributing the behavior to one earlier change.

How to reproduce

1. Build the current branch containing the Web Shell document exporter.
2. Start Qwen Code and create any session.
3. Run /export html.
4. Check the generated file size and inspect its script tags.

The HTML contains roughly 19.5 MB of inline JavaScript and has no external script source.

What did you expect to happen?

The exported HTML should contain transcript data, styles, and a small bootstrap. The complete React and Web Shell renderer should be a browser-ready asset in the matching @qwen-code/qwen-code npm package and loaded from an immutable, exact-version unpkg URL, consistent with the earlier HTML export distribution model.

The generated HTML must pin the final asset bytes with Subresource Integrity, fail closed when the renderer is unavailable or incompatible, and retain its existing restrictions against network requests originating from document content.

The generated HTML size should also have an automated budget so a large inline-bundle regression cannot land unnoticed.

Client information

Client Information

Qwen Code v0.23.0
Model: qwen3.8-max-2026-09-02
Fast Model: qwen3-coder-flash
Auth: openai
Platform: darwin arm64 (24.1.0)
Node.js: v22.22.0
Session: 40f93c8e-ec87-4381-a18b-48099cbd005c
Git commit: 98a9c96415
LSP: disabled

Anything else we need to know?

The renderer does not exist in previously published package versions. The first release containing the fix must include export-transcript-document.js at the npm package root, followed by a smoke test against the exact unpkg URL. No separate OSS synchronization is needed.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Triage

• Type: bug — regression on main, on the default /export html path
• Labels: type/bug, category/performance, scope/web-shell, scope/build-system, roadmap/export-data, priority/P1
• Next: mechanism confirmed statically. The proposed CDN direction collides with two deliberate properties of the document renderer, so it needs a decision before an implementation PR.

Root cause

packages/web-templates/src/export-html/build.mjs builds document-main.tsx with bundle: true, format: 'iife' and no external list, then inlines the result into document-index.html at __DOCUMENT_INLINE_SCRIPT__. The legacy path in the same directory does the opposite: esbuild.config.mjs declares external: ['react', 'react-dom', 'react-dom/client'] and index.html loads React from unpkg.com/react@18.2.0/umd/react.production.min.js.

Where the bytes actually come from:

• document-main.tsx imports WebShellTranscript from the package root @qwen-code/web-shell. That root (client/index.tsx) also imports App, DaemonWorkspaceProvider and WorkspaceSessionProvider, does export * from './daemon-react-sdk', and value-exports the echarts renderers (EchartsFullDataBlock, createMarkdownChartRegistry, createEchartsFullDataRenderer).
• vite.lib.config.ts marks react/react-dom, radix-ui, lucide-react, echarts, react-markdown, remark-*, rehype-katex, shiki, mermaid, katex, codemirror and @datafe-open/* as external for the lib build. So dist/index.js leaves them as bare specifiers — and the document esbuild step, having no external, resolves and inlines every one of them. shiki + mermaid + echarts + katex account for the bulk.
• The injectCssModules plugin prepends a top-level side effect to the client/index.tsx facade chunk that injects the full scoped component stylesheet at import time. Root-importing therefore forces the whole CSS in too, and esbuild cannot shake a side effect.

toHtml() in packages/cli/src/ui/utils/export/formatters/html.ts takes the document renderer whenever originalRecords is present, so this is the default path rather than an opt-in.

The bisect in the report checks out: b1b6bed0 "feat(export): add portable transcript document renderer" (build.mjs +81/-2, adds document-index.html / document-main.tsx / document-styles.css), merged via #10076 on 2026-09-04 — roughly two hours before this issue was filed. Published 0.23.0 still uses the legacy renderer, so this is a main-only regression that ships with the next release.

On the proposed direction

The "expected behavior" asks for version-pinned CDN URLs. Two things in the current code push back on that:

• document-index.html sets default-src 'none'; script-src 'nonce-__EXPORT_NONCE__'; connect-src 'none'. A CDN <script src> is blocked by that CSP today, so adopting one means widening script-src to a third-party host and giving up the nonce-only, offline-openable, no-remote-code artifact the document renderer deliberately created.
• build.mjs carries an explicit comment that the export must stay self-contained, because resolving from a CDN at view time "would retroactively change how every already-generated export renders".

Not arguing the CDN route is wrong — it trades a real property away, which makes it a product decision rather than a straightforward fix.

There is a cheaper lever that keeps both properties, and the repo already prescribes it. docs/design/2026-07-14-chat-record-daemon-transcript-block-projection.md states "Do not rely on importing the package root or incidental tree shaking for browser safety", next to "a separate size budget with the baseline commit and measurement command recorded". Concretely: a transcript-only entry (the way the SDK added ./daemon/transcript) that document-main.tsx imports instead of the package root, plus an explicit external and budget policy on the document build. A read-only transcript has no reason to ship App, the daemon SDK, codemirror or xterm. Worth measuring that first — it may recover most of the 62x without any release-asset or CDN work.

On the size budget

Agreed, and there is an existing pattern to extend rather than new CI to invent. packages/sdk-typescript/scripts/build.js already asserts browser bundle sizes: hard throws at MAX_TRANSPORTS_BROWSER_BUNDLE_BYTES (48 KiB) and MAX_TRANSCRIPT_BROWSER_BUNDLE_BYTES (192 KiB), advisory warning at DAEMON_BROWSER_BUNDLE_WARNING_BYTES (216 KiB). The export path bounds the data envelope (EXPORT_TRANSCRIPT_RENDERER_LIMITS: 1000 blocks / 32 MiB, with version and limits consistency assertions in renderExportTranscriptDocumentToHtml) but nothing bounds the runtime inlined alongside it — which is how a 62x change landed unflagged.

Not verified

The exact byte counts (19,526,066 raw / 4,772,314 gzip / 311,990 for 0.23.0) were not re-measured. This is an unattended CI run, node_modules is not installed in the runner checkout, and the triage rules forbid building or executing repo code here. The mechanism above supports the direction and rough magnitude of the claim, but the numbers are the reporter's own measurements, not independently reproduced.

中文说明

• 类型：bug —— main 上的回归，且位于 /export html 的默认路径
• 标签：type/bug、category/performance、scope/web-shell、scope/build-system、roadmap/export-data、priority/P1
• 下一步：机制已通过静态分析确认。建议的 CDN 方案与 document renderer 两个刻意设计的属性冲突，需要先做决策再提实现 PR。

根因：build.mjs 用 bundle: true、format: 'iife' 且没有 external 构建 document-main.tsx，再把产物内联进 document-index.html。同目录的 legacy 路径恰好相反：esbuild.config.mjs 声明了 external: ['react', 'react-dom', 'react-dom/client']，index.html 从 unpkg CDN 加载 React。

体积来源：

• document-main.tsx 从包根 @qwen-code/web-shell 导入 WebShellTranscript。而包根 client/index.tsx 同时导入了 App、DaemonWorkspaceProvider、WorkspaceSessionProvider，还有 export * from './daemon-react-sdk'，并以值导出形式带出 echarts 渲染器。
• vite.lib.config.ts 把 react/react-dom、radix-ui、lucide-react、echarts、react-markdown、remark-*、rehype-katex、shiki、mermaid、katex、codemirror、@datafe-open/* 都标记为 lib 构建的 external，因此 dist/index.js 里它们是裸模块名；而 document 那步 esbuild 没有 external，于是把它们全部解析并内联。shiki + mermaid + echarts + katex 就是大头。
• injectCssModules 插件会在 client/index.tsx facade chunk 顶部注入一段顶层副作用代码，在 import 时注入完整的 scoped 组件样式表。所以从包根导入还会强制带上全部 CSS，而副作用是 esbuild 无法摇掉的。

formatters/html.ts 的 toHtml() 只要存在 originalRecords 就走 document renderer，所以这是默认路径而非可选项。

报告中的 bisect 核对无误：b1b6bed0「feat(export): add portable transcript document renderer」（build.mjs +81/-2，新增 document-index.html / document-main.tsx / document-styles.css），经 #10076 于 2026-09-04 合入 —— 大约就在本 issue 提交前两小时。已发布的 0.23.0 仍使用 legacy renderer，因此这是仅存在于 main、会随下个版本发布的回归。

关于建议的方向：期望行为要求使用版本锁定的 CDN URL。现有代码有两点与之相抵触：

• document-index.html 设置了 default-src 'none'; script-src 'nonce-__EXPORT_NONCE__'; connect-src 'none'。CDN 的 <script src> 在当前 CSP 下会被拦截，因此改用 CDN 意味着要把 script-src 放开到第三方域名，并放弃 document renderer 刻意建立的「仅 nonce、可离线打开、不加载远端代码」的产物特性。
• build.mjs 中有明确注释说明导出必须自包含，因为在浏览时从 CDN 解析「会追溯性地改变每一个已生成导出的渲染方式」。

并不是说 CDN 方案错误 —— 而是它确实换掉了一个真实属性，因此这是产品决策，不是一个直接的修复。

有一个更省力的路子能同时保住这两个属性，而且仓库自己已经写明了：docs/design/2026-07-14-chat-record-daemon-transcript-block-projection.md 指出「不要依赖从包根导入或偶然的 tree shaking 来保证浏览器安全」，旁边还写了「单独的体积预算，并记录基线 commit 与测量命令」。具体做法：像 SDK 增加 ./daemon/transcript 那样提供一个仅含 transcript 的入口，让 document-main.tsx 改为从它导入，并对 document 构建加上明确的 external 与预算策略。只读 transcript 没有理由携带 App、daemon SDK、codemirror 或 xterm。建议先量化这一步 —— 可能不需要任何发布产物或 CDN 工作就能收回 62x 里的大部分。

关于体积预算：同意，而且已有可复用的模式，无需新造 CI。packages/sdk-typescript/scripts/build.js 已在断言浏览器 bundle 体积：MAX_TRANSPORTS_BROWSER_BUNDLE_BYTES（48 KiB）与 MAX_TRANSCRIPT_BROWSER_BUNDLE_BYTES（192 KiB）为硬失败，DAEMON_BROWSER_BUNDLE_WARNING_BYTES（216 KiB）为告警。导出路径对数据信封有上限（EXPORT_TRANSCRIPT_RENDERER_LIMITS：1000 blocks / 32 MiB，并在 renderExportTranscriptDocumentToHtml 中做版本与上限一致性断言），但对旁边内联的运行时没有任何约束 —— 这正是 62x 变化能无声落地的原因。

未验证：具体字节数（raw 19,526,066 / gzip 4,772,314 / 0.23.0 的 311,990）未复测。本次为无人值守 CI 运行，runner 检出中没有安装 node_modules，且 triage 规则禁止在此构建或执行仓库代码。上述机制支持该结论的方向与大致量级，但数字是报告者自己的测量，未经独立复现。

--- Qwen Code

_{Static analysis at 419e8d57b2a9f9312b7d2955932e25c0d1cfc306 · re-run with @qwen-code /triage}

[yiliang114]

Reproduced on main (0dd5bf2).

Measurements (built packages/web-templates via its normal build, measured the generated templates — the export file is the template plus a small envelope):

• Document renderer template (dist/document.html): 19,525,807 bytes raw / 4,775,943 bytes gzip
• Legacy renderer template (dist/index.html): 311,854 bytes
• Ratio: ~62.6x — matches the report's 19,526,066 / 311,990 numbers.

The document HTML has no <script src=...> at all: the entire runtime is inlined under default-src 'none'; script-src 'nonce-...'.

Where the bytes come from (esbuild metafile on document-main.tsx, 36 MB pre-minify inputs → 19.5 MB output):

Input	Pre-minify bytes	Why it's there
@qwen-code/web-shell package-root facade (dist/index.js)	7,018,687	document-main.tsx imports WebShellTranscript from the package root, which drags in App, providers, the daemon SDK and the full injected component stylesheet
@shikijs/* (all languages/themes)	~9,700,000	full shiki import in the markdown code highlighter — needed by transcript rendering itself
mermaid + graph deps	~6,000,000	reached through the markdown renderer
echarts + zrender	~4,300,000	reached through the markdown chart renderer
codemirror packages	~1,000,000	only reachable via the package root (App's editor/diff dialogs)
lucide-react	~1,570,000	mostly app chrome reachable via the package root
@qwen-code/sdk daemon client	~236,000	only reachable via the package root

So there are two distinct payloads: the transcript renderer (markdown/shiki/mermaid/echarts/katex — legitimately needed to render a transcript offline) and the interactive Web Shell runtime (App, daemon SDK, editor, app chrome — never used by a read-only export). The second one is pure dead weight in every export.

Fix direction (per the stage-1 triage; working on it):

1. Add a transcript-only entrypoint to @qwen-code/web-shell (same pattern as the existing ./daemon-react-sdk subpath and the SDK's ./daemon/transcript) and point document-main.tsx at it, so the document build no longer pulls the package root. The export stays fully self-contained — no CDN, CSP unchanged (the CDN direction from the report collides with the deliberate offline/nonce-only design and needs a separate product decision).
2. Add a hard size budget on the inlined document runtime in the template build, mirroring the existing MAX_*_BROWSER_BUNDLE_BYTES assertions in packages/sdk-typescript/scripts/build.js, so a regression like this fails the build instead of landing silently.

Will report before/after numbers on the PR.