Skip to content

bug(desktop): tool rows expand to empty, repeated, or placeholder details #5997

Description

@Colafornia
English

What happened

In the Desktop conversation, every tool row shows a disclosure chevron and can be expanded, even when there is nothing new to show. After expanding the row, the reader sees one of the following:

  • An empty detail area.
  • The same command line that the collapsed row already shows.
  • A raw type token such as [summary], [image], or [archived_tool_result].

The reader pays a click and learns nothing. This adds noise to every turn and teaches readers that tool details are not worth opening.

Expected behavior: a tool row is expandable only when its detail adds information beyond the collapsed row. A summary result shows its summarized text instead of [summary].

How to reproduce

This was found by code inspection on upstream/main and was not reproduced in a running window. The conditions below follow from the code paths.

  1. Run a turn in which a tool call produces no displayable result and no arguments beyond its invocation line. Expand its row. The detail area is empty.
  2. Run a single-line tool call without an intent, for example a short shell command. Expand its row. The detail repeats the collapsed target.
  3. Run a tool call whose result is stored as summary (an oversized result that the runtime summarized). Expand its row. The detail shows [summary].
  4. Do the same for a result of kind image or archived_tool_result. The detail shows [image] or [archived_tool_result].

Environment

  • Maka version or commit: upstream/main at 7c90bac2d
  • OS and version: macOS (code inspection, OS-independent)
  • Surface: Desktop
  • Node.js version, if running from source: not applicable

Logs, screenshots, or additional context

Root cause. Astryx ChatToolCalls makes a row expandable when call.resultDetail != null. In packages/ui/src/tool-activity.tsx, standardToolCall always passes a <ToolDetailReveal> element as resultDetail, even when describeToolCall returns { kind: 'none' }. The quietText fallback in describeToolCall shows the invocation line, which repeats the collapsed target when the call has no intent. The final fallback in packages/ui/src/tool-activity/tool-result-preview.tsx renders `[${content.kind}]` for image, summary, and archived_tool_result.

Astryx documents the intended use: "Provide resultDetail… for calls that produce output."

Proposed correction.

  • In standardToolCall, compute the detail decision first and pass resultDetail only when the detail adds information.
  • Treat these cases as not informative:
    • body.kind === 'none' with no sandbox or requires-bypass banner.
    • A single-line quietText without a title that equals the collapsed target.
    • image and archived_tool_result results that would only show a type token.
  • Render the summarized text of a summary result, with the same redaction and formatting as the text branch.
  • Keep a row expandable when a client plugin contributes to the conversation.tool.detail slot for that tool name.

Scope boundaries. Rows with diffs, terminal or shell output, web search results, JSON, live output, or banners keep their current behavior. This issue does not change tool grouping, the process disclosure lifecycle, output length bounds, or the requires-bypass retry action.

Acceptance criteria.

  • Rows whose detail would be empty, repeated, or a type token show no chevron and are not interactive.
  • An expanded summary result shows its summarized text.
  • Rows with meaningful detail behave as before.
  • Render tests cover each case above.

Related work. This is the first slice of #4863, which states "Only provide resultDetail when the result has meaningful content to inspect." The remaining #4863 scope, including WebFetch citation cards and shared bounds, stays there. #4773 tracks group layout.

中文

发生了什么

在 Desktop 对话里,每一行工具调用都有展开箭头,都可以点开,即使展开后没有任何新内容。点开后,读者会看到以下情况之一:

  • 一块空的详情区域。
  • 和收起状态下行上已经显示的同一条命令。
  • 一个原始类型标记,例如 [summary]、[image] 或 [archived_tool_result]。

读者点了一次,却什么也没得到。这给每一轮对话都增加了噪音,也让读者觉得工具详情不值得打开。

期望行为:只有详情能提供收起行之外的信息时,这一行才可以展开。summary 类型的结果应显示摘要正文,而不是 [summary]。

如何复现

这些问题是在 upstream/main 上通过阅读代码发现的,没有在运行中的窗口里复现。下面的条件由代码路径推出。

  1. 运行一轮对话,其中某次工具调用没有可显示的结果,除调用命令外也没有其他参数。展开这一行,详情区域是空的。
  2. 运行一次没有 intent 的单行工具调用,例如一条简短的 shell 命令。展开这一行,详情重复显示收起时的目标。
  3. 运行一次结果被存为 summary 的工具调用(运行时对过大的结果做了摘要)。展开这一行,详情显示 [summary]。
  4. 对 image 或 archived_tool_result 类型的结果做同样操作,详情显示 [image] 或 [archived_tool_result]。

环境

  • Maka 版本或 commit:upstream/main,7c90bac2d
  • 操作系统及版本:macOS(通过阅读代码发现,与操作系统无关)
  • 界面:Desktop
  • Node.js 版本(从源码运行时):不适用

日志、截图或其他上下文

根因。 Astryx ChatToolCalls 在 call.resultDetail != null 时让一行变成可展开。在 packages/ui/src/tool-activity.tsx 中,standardToolCall 总是把一个 <ToolDetailReveal> 元素作为 resultDetail 传入,即使 describeToolCall 返回 { kind: 'none' }。describeToolCall 的 quietText 兜底分支显示调用命令,当调用没有 intent 时,这与收起时的目标重复。packages/ui/src/tool-activity/tool-result-preview.tsx 的最后一个兜底分支对 image、summary 和 archived_tool_result 渲染 `[${content.kind}]`。

Astryx 文档写明了预期用法:"Provide resultDetail… for calls that produce output."

建议修正。

  • 在 standardToolCall 中先计算详情判断结果,只有详情能提供新信息时才传入 resultDetail。
  • 以下情况视为没有新信息:
    • body.kind === 'none',并且没有沙箱拦截或 requires-bypass 横幅。
    • 没有标题、只有一行、并且与收起时目标相同的 quietText。
    • 只会显示类型标记的 image 和 archived_tool_result 结果。
  • summary 类型的结果渲染其 summarized 正文,脱敏和格式化方式与 text 分支相同。
  • 如果某个客户端插件为该工具名向 conversation.tool.detail 插槽提供了内容,这一行保持可展开。

范围边界。 含有 diff、终端或 shell 输出、网络搜索结果、JSON、实时输出或横幅的行,保持现有行为。本 issue 不改变工具分组、过程折叠的生命周期、输出长度上限,也不涉及 requires-bypass 的重试操作。

验收标准。

  • 详情为空、重复或只有类型标记的行,不显示展开箭头,也不可交互。
  • 展开 summary 类型的结果时显示摘要正文。
  • 有实际详情内容的行,行为与之前一致。
  • 渲染测试覆盖上述每一种情况。

相关工作。 这是 #4863 的第一个切片。#4863 写明了"Only provide resultDetail when the result has meaningful content to inspect"。#4863 的其余范围,包括 WebFetch 引用卡片和统一的长度上限,仍留在 #4863。分组布局由 #4773 跟踪。

Activity

  1. self-assigned this
    on Oct 8, 2026
  2. ggbdpq commented on Oct 9, 2026

    @ggbdpq
    Contributor

    take

  3. github-actions commented on Oct 9, 2026

    @github-actions

    Issue #5997 is already assigned to Colafornia, so it was not reassigned.

  4. Colafornia commented on Oct 9, 2026

    @Colafornia
    MemberAuthor

    @ggbdpq Hi, this issue already has an assignee and an open PR, so there's no need to work on it again.

    Please choose a different issue to contribute to. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions