You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unify the remaining VSCode companion/web UI tool display labels with the CLI naming direction from #1367.
This finishes the still-live gaps on current main by centralizing label resolution and applying it to the shared tool-call components, so users no longer see a mix of labels such as Execute, Bash, Updated Plan, Web Fetch, and generic read labels where the CLI already uses the core tool names.
Screenshots / Video Demo
N/A — this is a display-name consistency change across existing tool-call cards, with no new user flow.
Dive Deeper
Issue #1367 was only partially addressed. Several labels had already been unified, but current main still had hardcoded mismatches in the shared web UI layer:
Execute / Bash instead of Shell
Updated Plan instead of TodoWrite
Web Fetch / Web Search instead of WebFetch / WebSearch
generic Read labels for read-family tools that could be resolved more precisely
This PR adds a shared getToolDisplayLabel() helper and uses it in the remaining tool-call components so the naming logic is defined once and reused consistently.
It also expands the VSCode companion tool-call router so read-family variants like read_many_files and list_directory reach ReadToolCall instead of falling back incorrectly.
A regression test covers the remaining mapping cases directly.
Reviewer Test Plan
Open the VSCode IDE Companion and trigger representative tool calls for shell, plan updates, web fetch/search, and read-family operations.
Confirm the displayed labels match the core names: Shell, TodoWrite, WebFetch, WebSearch, ReadFile, ReadManyFiles, ListFiles, Task, Skill, and ExitPlanMode where applicable.
Run the targeted regression test:
cd packages/webui
npx vitest run src/components/toolcalls/labelUtils.test.ts
Run type checks:
cd packages/webui && npm run typecheck
cd packages/vscode-ide-companion && npm run check-types
Testing Matrix
🍏
🪟
🐧
npm run
❓
❓
❓
npx
❓
❓
❓
Docker
-
-
-
Podman
-
-
-
Seatbelt
-
-
-
Local verification completed:
npx vitest run src/components/toolcalls/labelUtils.test.ts
npm run typecheck in packages/webui
npm run check-types in packages/vscode-ide-companion
focused eslint on the touched webui and companion files
This PR addresses issue #1367 by unifying tool display labels across the web UI and VSCode companion, centralizing label resolution logic in a new getToolDisplayLabel() helper. The implementation is well-structured with good test coverage, though there are some concerns about the VSCode companion routing changes and potential edge cases in label derivation.
🔍 General Feedback
Positive: Centralizing label logic in labelUtils.ts is an excellent architectural decision that eliminates duplication and ensures consistency
Positive: Comprehensive test coverage in labelUtils.test.ts covers all major tool variants and edge cases
Positive: The PR scope is focused and addresses the stated goal of unifying display labels
Pattern: Good use of TypeScript with proper typing for the helper function signature
Concern: The VSCode companion routing changes add many case aliases without the corresponding label utility, which could lead to inconsistencies
🎯 Specific Feedback
🟡 High
File: packages/vscode-ide-companion/src/webview/components/messages/toolcalls/index.tsx:36-41 - The switch case additions for read-family tools (read_file, read_many_files, readmanyfiles, list_directory, listfiles) route to ReadToolCall but don't include the corresponding label normalization. The ReadToolCall component in the diff shows it now uses getToolDisplayLabel(), but this utility isn't imported or used in the VSCode companion. This could result in the ReadToolCall receiving different kind values and producing inconsistent labels. Recommendation: Either import and use the same getToolDisplayLabel utility in the VSCode companion, or ensure the routing normalizes the kind value before passing it to components.
🟢 Medium
File: packages/webui/src/components/toolcalls/labelUtils.ts:94-98 - The getReadLikeLabelFromTitle function relies on parsing the title string to determine the label for generic read kind. This is fragile because it depends on title format consistency (e.g., "ReadFile packages/webui/src/index.ts"). If the title format changes or is localized, this logic will break. Recommendation: Consider having the backend provide a more explicit subKind or toolName field rather than parsing title strings.
File: packages/webui/src/components/toolcalls/labelUtils.ts:1 - Missing JSDoc comment for the module. Given this is a shared utility that's now central to tool display consistency, adding documentation about its purpose and usage would improve maintainability.
File: packages/webui/src/components/toolcalls/UpdatedPlanToolCall.tsx:145-149 - The getToolDisplayLabel call passes safeTitle(toolCall.title) as the title parameter, but the function signature expects title?: unknown. This is fine, but inconsistent with other usages that pass title directly (e.g., ShellToolCall.tsx, ReadToolCall.tsx). Recommendation: Standardize the pattern across all usages for consistency.
🔵 Low
File: packages/webui/src/components/toolcalls/labelUtils.ts:7-8 - Helper functions normalizeValue and startsWithAny are useful but could benefit from JSDoc comments explaining their purpose, especially for startsWithAny which is a somewhat unusual pattern.
File: packages/webui/src/components/toolcalls/labelUtils.ts - Consider exporting the helper functions (normalizeValue, startsWithAny, getReadLikeLabelFromTitle) for potential reuse or testing, or mark them as private with a comment if they're intentionally internal.
File: packages/webui/src/components/toolcalls/GenericToolCall.tsx:33 - The variable name displayLabel is used after extracting from getToolDisplayLabel(), which is good. However, the old inline function had a comment explaining its purpose ("Map tool call kind to appropriate display name"). Consider adding a brief comment near the usage to maintain clarity.
File: packages/webui/src/components/toolcalls/labelUtils.test.ts:22-32 - The test case name "normalizes todo write labels even when older titles are still present" is quite long. Consider shortening to "normalizes todo write variants" for consistency with other test names.
✅ Highlights
Excellent test coverage: The labelUtils.test.ts file comprehensively tests all tool variants including edge cases with legacy title formats
Clean refactoring: Removing duplicate getDisplayLabel functions from GenericToolCall.tsx and SearchToolCall.tsx reduces code duplication significantly
Thoughtful mapping: The comprehensive switch statement in labelUtils.ts covers many tool variants and aliases, showing careful consideration of different naming conventions
Good TypeScript practices: Proper typing with unknown for the title parameter shows defensive programming to handle potential type variations
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TLDR
Unify the remaining VSCode companion/web UI tool display labels with the CLI naming direction from #1367.
This finishes the still-live gaps on current main by centralizing label resolution and applying it to the shared tool-call components, so users no longer see a mix of labels such as
Execute,Bash,Updated Plan,Web Fetch, and generic read labels where the CLI already uses the core tool names.Screenshots / Video Demo
N/A — this is a display-name consistency change across existing tool-call cards, with no new user flow.
Dive Deeper
Issue #1367 was only partially addressed. Several labels had already been unified, but current
mainstill had hardcoded mismatches in the shared web UI layer:Execute/Bashinstead ofShellUpdated Planinstead ofTodoWriteWeb Fetch/Web Searchinstead ofWebFetch/WebSearchReadlabels for read-family tools that could be resolved more preciselyThis PR adds a shared
getToolDisplayLabel()helper and uses it in the remaining tool-call components so the naming logic is defined once and reused consistently.It also expands the VSCode companion tool-call router so read-family variants like
read_many_filesandlist_directoryreachReadToolCallinstead of falling back incorrectly.A regression test covers the remaining mapping cases directly.
Reviewer Test Plan
Shell,TodoWrite,WebFetch,WebSearch,ReadFile,ReadManyFiles,ListFiles,Task,Skill, andExitPlanModewhere applicable.cd packages/webuinpx vitest run src/components/toolcalls/labelUtils.test.tscd packages/webui && npm run typecheckcd packages/vscode-ide-companion && npm run check-typesTesting Matrix
Local verification completed:
npx vitest run src/components/toolcalls/labelUtils.test.tsnpm run typecheckinpackages/webuinpm run check-typesinpackages/vscode-ide-companioneslinton the touchedwebuiand companion filesLinked issues / bugs
Resolves #1367