fix(web-shell): refine tool detail presentation - #6399
Conversation
|
Thanks for the PR! Template looks good ✓ Problem: This is a product-design UI refinement, not a bug fix. The previous tool-group summary showed a generic "called N tools" count that was uninformative — replacing it with category-based descriptions (edited files, ran commands, read files, etc.) is a clear usability improvement. No reproduction needed for observable UI improvements. Direction: Aligned with web-shell product goals. Making tool transcripts scannable by describing actual work performed rather than tool counts is a straightforward UX win. CHANGELOG has no direct reference but the area is relevant — web-shell presentation is a core user-facing surface. Size: Not applicable — all 22 files are in Approach: The scope feels right for a cohesive visual overhaul. The changes split into four logical groups — (1) category-based summaries, (2) single-tool direct display, (3) consistent Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：这是产品设计层面的 UI 优化，不是 bug 修复。之前工具组的 summary 只显示"调用了 N 个工具"这种无信息量的计数，改为按工作类型分类描述（已编辑文件、已运行命令、已读取文件等）是明确的可用性改进。可观测的 UI 改进不需要复现。 方向：与 web-shell 产品目标一致。让工具记录通过描述实际执行的工作而非工具数量来提高可扫描性，是直接的 UX 提升。CHANGELOG 无直接参考但相关领域适用——web-shell 展示层是核心用户界面。 规模：不适用——全部 22 个文件在 方案：范围对于一个统一的视觉改版来说合理。改动分为四个逻辑组——(1) 基于类别的摘要、(2) 单工具直接展示、(3) 统一的 进入代码审查 🔍 — Qwen Code · qwen3.7-max |
Code ReviewIndependent proposal: For making tool summaries more descriptive, I would have added a category-bucket counting function in Comparison with the diff: The PR's approach matches this proposal closely and in some cases exceeds it. The One thing I would have done differently: the chevron CSS rewrite (border-based → pseudo-element-based) is duplicated across three CSS files ( The No critical blockers found. The code is straightforward, follows project conventions, and the new abstractions ( TestingUnit Tests92 tests total, all passing. Test coverage is thorough — the PR adds tests for the new summary formatting functions, single-tool rendering, ANSI output rendering, expandable content detection, sub-tool expand/collapse behavior, and i18n localizations. TypeScriptNo new type errors introduced. Pre-existing errors in unrelated files ( Real-Scenario TestingWeb-shell is a browser-rendered React application — tmux-based CLI testing cannot exercise React component rendering. Visual verification requires a browser environment. Prior browser-based verification by @wenshao (comment #4894123728) covered the A/B comparison in a real browser, confirming the visual changes render correctly. 中文说明代码审查独立方案： 为了让工具 summary 更具描述性，我会在 与 diff 对比： PR 的方案与此提议高度吻合，部分地方甚至更好。 我会做得不同的一点：箭头 CSS 重写（从 border 改为伪元素）在三个 CSS 文件中重复（
未发现关键阻塞问题。 代码直接、遵循项目约定，新抽象（ 测试单元测试共 92 个测试全部通过。测试覆盖了新的 summary 格式化函数、单工具渲染、ANSI 输出渲染、可展开内容检测、子工具展开/折叠行为以及 i18n 本地化。 TypeScript未引入新的类型错误。无关文件中的预存错误（ 真实场景测试Web-shell 是浏览器渲染的 React 应用——基于 tmux 的 CLI 测试无法验证 React 组件渲染。视觉验证需要浏览器环境。@wenshao 之前的浏览器验证（评论 #4894123728）覆盖了真实浏览器中的 A/B 对比，确认视觉更改正确渲染。 — Qwen Code · qwen3.7-max |
|
Stepping back: this is a well-executed UI refinement that solves a real usability problem. The previous "called N tools" summary was uninformative — replacing it with category-based descriptions that tell the user what work happened (edited files, ran commands, searched, etc.) is a clear improvement. The implementation is cohesive. Four interlocking changes — category summaries, single-tool direct display, consistent My independent proposal (written before reading the diff) landed on essentially the same approach, so I can't point to a materially simpler path the PR missed. The new abstractions are minimal — The chevron CSS duplication across three files is the only thing I'd flag for a future cleanup, but it's cosmetic and doesn't affect correctness or the PR's scope. 92 tests pass. No new type errors. The PR has already received browser-based verification from a maintainer. This looks ready to ship. 中文说明退一步看：这是一个执行良好的 UI 优化，解决了真实的可用性问题。之前的"调用了 N 个工具"summary 没有信息量——用基于类别的描述告诉用户发生了什么工作（已编辑文件、已运行命令、已搜索等）是明确的改进。 实现是内聚的。四个相互关联的更改——类别摘要、单工具直接展示、统一的 我在阅读 diff 之前写的独立方案得出了基本相同的方案，所以我无法指出 PR 遗漏了更简单的路径。新的抽象最小化—— 三个文件中的箭头 CSS 重复是我唯一想标记为未来清理的，但它是装饰性的，不影响正确性或 PR 范围。 92 个测试通过。无新的类型错误。PR 已收到维护者的浏览器验证。可以合并了。 — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
| {plainText ? ( | ||
| <pre className={styles.expandedOutput}>{content}</pre> | ||
| ) : ( | ||
| <Markdown content={fencedCodeBlock(language, content)} /> |
There was a problem hiding this comment.
[Critical] ExpandedReadContent 的 Markdown 渲染路径缺少滚动容器约束。
纯文本路径（line 256）使用 <pre className={styles.expandedOutput}> 获得了 max-height: 400px; overflow-y: auto，但 Markdown 路径直接将 <Markdown> 渲染在 .expandedRead div 中，而 .expandedRead 只有 overflow: hidden，没有 max-height。
这意味着一个 1000 行 / 200K 字符以内的源代码文件通过 Markdown+Shiki 渲染时，内容会完全展开没有滚动限制，可能将消息列表中后续内容推到视口之外。
| <Markdown content={fencedCodeBlock(language, content)} /> | |
| <div className={styles.expandedOutput}> | |
| <Markdown content={fencedCodeBlock(language, content)} /> | |
| </div> |
— qwen3.7-max via Qwen Code /review
Suggestions — commit
|
| File | Issue | Suggested fix |
|---|---|---|
ToolGroup.test.tsx (single-tool rendering) |
单工具渲染模式（tools.length === 1 + forceExpanded + hideHeader）是此 PR 的核心新功能，但没有对应的集成测试 |
添加一个测试：渲染单个 Shell 工具，验证 summary 文本为单工具格式、展开后有详情卡片且无 header |
ToolGroup.test.tsx (ExpandedReadContent) |
ExpandedReadContent 的 Markdown 路径和纯文本降级路径（超过 200K/1000 行）均未测试 |
添加渲染测试覆盖：常规 .ts 文件走 Markdown 路径、超大内容降级为 <pre> |
App.module.css:524-526 |
.approvalOverlay:focus, .approvalOverlay:focus-visible { outline: none } 移除了审批覆盖层的焦点指示器，违反 WCAG 2.4.7 |
用自定义 focus 样式替代（如 box-shadow），或仅在 :focus:not(:focus-visible) 时隐藏 outline |
ToolGroup.tsx:570-582 |
formatRunningSingleToolSummary 对 todo_write/ask_user_question 产生不通顺的运行状态文本，如 "Running Updated task list 0:03" |
对这两类工具在 running 状态使用工具显示名而非动作摘要 |
— qwen3.7-max via Qwen Code /review
| background: var(--secondary); | ||
| border: 0.5px solid var(--border); | ||
| border-radius: var(--radius); | ||
| padding: 8px 12px; |
There was a problem hiding this comment.
[Critical] .panel lost padding: 8px 12px, but the replacement padding (.expandedAgentCard in ToolChrome.module.css) only wraps the agent card when rendered through ToolLine with hideHeader=true. Two other rendering paths still use .panel directly without the wrapper:
ParallelAgentsGroup.tsx:198—<SubAgentPanel tool={agent} hideHeader />- Recursive
SubAgentPanel.tsx:105—<SubAgentPanel tool={tool} />(nested sub-agents)
Both render with content flush against the panel edges — a visible regression from the previous consistent spacing.
Suggested fix: restore padding: 8px 12px on .panel (and remove the duplicate from .expandedAgentCard), or add an equivalent padding wrapper at the two call sites above.
— qwen3.7-max via Qwen Code /review
| workspaceCwd?: string, | ||
| ): string { | ||
| return t('toolGroup.running', { | ||
| name: formatSingleToolSummary(tool, t, workspaceCwd), |
There was a problem hiding this comment.
[Suggestion] formatRunningSingleToolSummary delegates to formatSingleToolSummary for the name parameter, which returns past-tense strings like "Asked user" and "Updated task list". These get inserted into the "Running ${name} ${duration}" template, producing:
- "Running Asked user 0:03" (for
ask_user_question— especially common since it sits in pending while waiting for user input) - "Running Updated task list 0:05" (for
todo_write)
This tense mismatch is user-visible whenever a single ask/todo tool is in a running state.
Consider adding present-tense i18n keys (e.g., "Asking user", "Updating task list") and branching on tool type in this function, or passing an isRunning flag to formatSingleToolSummary.
— qwen3.7-max via Qwen Code /review
| @@ -186,61 +191,33 @@ export function buildUnifiedDiff(oldText: string, newText: string): string { | |||
| return result.reverse().join('\n'); | |||
There was a problem hiding this comment.
[Suggestion] The resolveShellOutputMaxLines function, the shellOutputMaxLines prop chain, and all consumer logic were removed. However, the daemon setting ui.shellOutputMaxLines still exists in the settings schema, and the i18n labels settings.label.ui.shellOutputMaxLines / settings.description.ui.shellOutputMaxLines are still present. Users who configured this setting will see no effect in the web-shell, with no deprecation notice.
Consider either noting this intentional removal in the PR description for changelog purposes, or adding a deprecation note to the settings schema clarifying that ui.shellOutputMaxLines now only applies to the CLI/TUI.
— qwen3.7-max via Qwen Code /review
✅ Verification report — real-browser A/B for the tool-detail presentationI built a real-browser A/B harness that renders the actual How it was tested
Results — every test-plan claim reproduces
Evidence (BEFORE =
|
| # | PR 描述的行为 | BEFORE (main) |
AFTER (#6399) | |
|---|---|---|---|---|
| 1 | 完成后的工具组按工作类型汇总，而非只显示数量 | Ran 5 tools |
Edited 2 files Ran 1 command Read 1 file Searched 1 time |
✅ |
| 2 | 单个工具直接展示，不再多一层「1 tool」 | Ran 1 tool |
Shell npm run test … · ReadFile … · Asked user · Updated task list · Task … |
✅ |
| 3 | 单个运行中工具保留状态 + 耗时 + 详情 | Running Shell 2s |
Running Shell npm run build -w packages/core 1s |
✅ |
| 4 | 详情视图统一为紧凑一致的卡片 | 样式不一致 / 嵌套 | shell / read / edit / ask / todo / agent 统一卡片 | ✅ |
| 5 | 读取文件→语法高亮 Markdown；mermaid 与超大文件→纯 pre | 纯 pre + 「N lines total」按钮 | .ts 高亮；.mermaid 与 1200 行→纯 pre |
✅ |
| 6 | Shell 输出完整、可滚动、不截断 | … first 9 lines hidden … + Show all (14 lines) |
完整 14 行，无截断 | ✅ |
| 7 | 子 agent 的子工具折叠态保持简洁；非标准工具也可展开 | 输出内联；非标准行不可展开 | 折叠态简洁；analyze_dependencies 可展开、内容可达 |
✅ |
截图
（见上方英文版：01 汇总、02 shell 完整输出、03 读取高亮、05 子 agent 面板、07 fallback 降级）
单元测试
ToolGroup.test.tsx(19) +toolFormatting.test.ts(29) +SubAgentPanel.test.tsx(5) = 在 PR HEAD 上 53/53 全部通过。- 非空性验证：把 PR 的测试文件跑在
main源码上 → 12 个失败（例如hides non-standard sub-tool summaries until the row is expanded）→ 说明新增测试确实守护了新行为，而非平凡通过。
一点提示
PR 自己写的风险点成立：展开后的 shell 详情现在渲染完整命令输出且不做行数截断（设计如此），因此当命令输出极大时，用户展开后浏览器渲染成本较高。读取文件路径有保护（高亮上限 1000 行 / 200KB，超过则降级为纯 pre，已验证）；shell 输出按设计没有该上限。这不是阻塞项，只是已记录的取舍。
结论： 行为端到端符合预期的产品设计，从展示层面看可以合并。👍
Verified with a throwaway Vite component harness rendering the real components in headless Chromium; A/B by swapping the 22 changed files between main and PR HEAD 16728a9. Not a full daemon+model E2E — not needed for a pure presentation change.
|
@qwen-code /triage |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
3 participants
What this PR does
This PR updates the web-shell tool presentation as a product-design change. Completed tool groups now summarize the actual kinds of work that happened, such as edited files, ran commands, read files, searched, updated task lists, asked the user, and other tools, instead of only saying that a number of tools were called.
When there is only one tool call, the outer summary now shows that tool directly, such as the command or file action, instead of adding an extra "called 1 tool" layer. A single running tool keeps the running state and elapsed time visible while still showing the tool detail in the summary.
Tool detail views were restyled to use a consistent compact card treatment for command output, grep/search results, task-list updates, ask-user output, edits, writes, and agent details. Read-file details continue to render as syntax-highlighted Markdown code blocks when appropriate, while very large reads and Mermaid files fall back to plain preformatted text. Shell details intentionally show the full output in a scrollable area to match the product expectation that web-shell users can scroll freely.
Sub-agent tool rows now keep the collapsed state concise and require expansion to view details, including non-standard tools. This preserves the compact agent panel while still making every sub-tool result reachable.
Why it's needed
The previous tool summary and detail layout emphasized the number of tool calls more than the work that was performed. That made transcripts harder to scan, especially in web-shell where users expect richer visual grouping and direct access to the most relevant action.
These changes align the web experience with the intended product design: summaries should describe the work, single-tool interactions should avoid unnecessary nesting, and expanded details should share a consistent visual language without hiding important output. Shell output is not truncated by design; the web surface should keep the full command output available when the user chooses to expand it.
Reviewer Test Plan
How to verify
Open a web-shell conversation with multiple completed tools and confirm the outer summary names the performed work by category rather than only showing a raw tool count. Try a single command tool and confirm the outer summary shows the command directly; while it is running, confirm the summary still shows the running state and elapsed time. Expand command, grep/search, task-list, ask-user, edit/write, read-file, and agent details and confirm they use the updated card treatment. In a sub-agent details panel, confirm sub-tools stay compact until expanded and that both standard tools and non-standard tools can be expanded to reveal their details. Expand a shell command with output and confirm the full output is available inside the scrollable detail area rather than being truncated.
Evidence (Before & After)
Before: tool groups primarily showed a generic count such as "called N tools", a single tool still required an extra summary layer, several expanded details used inconsistent or nested card treatments, and sub-agent tool rows could either expose extra collapsed summaries or fail to reveal non-standard tool results cleanly.
After: tool groups summarize work by category, a single tool appears directly in the outer summary, expanded details use a consistent compact card style, read-file content uses syntax-aware rendering with safe plain-text fallbacks, shell details keep full scrollable output, and sub-agent tools remain concise until expanded.
Tested on
Environment (optional)
Validated locally with targeted web-shell unit tests and TypeScript checking:
RUN v3.2.4 /Users/ytahdn/Documents/Codes/qwen/qwen-code/packages/web-shell/client
✓ components/messages/ToolGroup.test.tsx (19 tests) 34ms
✓ components/messages/tools/SubAgentPanel.test.tsx (5 tests) 32ms
Test Files 2 passed (2)
Tests 24 passed (24)
Start at 21:37:49
Duration 1.58s (transform 236ms, setup 0ms, collect 713ms, tests 66ms, environment 772ms, prepare 86ms); .
Risk & Scope
Linked Issues
N/A
中文说明
What this PR does
这个 PR 调整 web-shell 的工具展示方式，属于产品设计层面的展示行为改动。工具组完成后，现在会按实际发生的工作类型汇总，例如已编辑文件、已运行命令、已读取文件、已搜索、已更新任务清单、已询问用户以及其他工具，而不是只展示调用了几个工具。
当只有一个工具调用时，最外层 summary 会直接展示当前工具，例如命令或文件动作，不再额外展示一层“调用了 1 个工具”。单个工具正在运行时，summary 仍然保留运行状态和耗时，同时展示工具本身的信息。
工具详情视图统一调整为更紧凑一致的卡片样式，覆盖命令输出、grep/search 结果、任务清单更新、询问用户、编辑、写入和 agent 详情等场景。读取文件详情在适合时继续按文件后缀使用 Markdown 代码块高亮；超大读取内容和 Mermaid 文件会回退为纯 pre 文本展示。Shell 详情按照产品预期保留完整输出，并在详情区域内滚动查看，不做截断。
Sub-agent 内部的工具行现在保持折叠态简洁，需要展开后查看详情，包括非标准工具也可以展开查看结果。这样 agent 面板保持紧凑，同时不会丢失任何子工具结果。
Why it's needed
之前的工具 summary 更强调调用了多少个工具，而不是实际完成了什么工作。这让 transcript 不够容易扫读，尤其在 web-shell 中，用户更期待清晰的视觉分组和直接看到最相关的动作。
这些改动让 web 体验符合预期的产品设计：summary 应该描述实际工作，单工具交互不需要多一层嵌套，展开详情应该有一致的视觉语言，同时不能隐藏重要输出。Shell 输出按设计不截断；在 web 场景中，用户主动展开后应能通过滚动查看完整命令输出。
Reviewer Test Plan
How to verify
打开一个包含多个已完成工具的 web-shell 会话，确认最外层 summary 按工具类型展示完成的工作，而不是只展示工具数量。尝试单个命令工具，确认最外层 summary 直接展示该命令；运行中时确认仍展示运行状态和耗时。展开命令、grep/search、任务清单、询问用户、编辑/写入、读取文件和 agent 详情，确认使用新的统一卡片样式。在 sub-agent 详情面板中，确认子工具折叠态保持简洁，标准工具和非标准工具都能展开查看详情。展开带输出的 shell 命令，确认完整输出保留在可滚动详情区域中，而不是被截断。
Evidence (Before & After)
Before：工具组主要展示类似“调用了 N 个工具”的泛化数量；单个工具仍然需要额外 summary 层；部分展开详情样式不统一或出现嵌套卡片；sub-agent 工具行可能在折叠态暴露多余摘要，或无法清晰展示非标准工具结果。
After：工具组按工作类型汇总；单个工具直接展示在最外层 summary；展开详情使用一致的紧凑卡片样式；读取文件具备按后缀渲染和安全纯文本回退；shell 详情保留完整可滚动输出；sub-agent 工具保持折叠态简洁，展开后查看详情。
Tested on
Environment (optional)
本地通过 web-shell 定向单测和 TypeScript 检查验证：
RUN v3.2.4 /Users/ytahdn/Documents/Codes/qwen/qwen-code/packages/web-shell/client
✓ components/messages/ToolGroup.test.tsx (19 tests) 33ms
✓ components/messages/tools/SubAgentPanel.test.tsx (5 tests) 32ms
Test Files 2 passed (2)
Tests 24 passed (24)
Start at 21:37:59
Duration 1.24s (transform 203ms, setup 0ms, collect 524ms, tests 65ms, environment 438ms, prepare 67ms)；。
Risk & Scope
Linked Issues
N/A