Repository navigation
TUI: Bash tool calls only show description, not actual command #1736
Description
Description
When opencode executes bash commands through the TUI, only the description parameter is displayed in the tool call title, not the actual command being executed. This makes it difficult to understand what specific command was run.
Expected Behavior
The TUI should display the actual bash command being executed (e.g., git status, npm install, etc.) in the tool call title or alongside the description.
Actual Behavior
Only the description is shown (e.g., "Get current git status" instead of git status).
Environment
- opencode version: v0.4.1
- OS: Arch Linux
- Terminal: Ghostty
- Shell: zsh (with Zellij)
Steps to Reproduce
- Run any opencode session that executes bash commands
- Observe the tool call display in the TUI
- Note that only descriptions are shown, not the actual commands
Technical Details
The issue is in packages/tui/internal/components/chat/message.go at lines 701-704 in the renderToolTitle() function:
case "bash":
if description, ok := toolArgsMap["description"].(string); ok {
title = fmt.Sprintf("%s %s", title, description)
}This only renders the description parameter, while the actual command parameter is available but not displayed in the title.
Impact
- Reduces transparency about what commands are being executed
- Makes it harder to understand the assistant's actions
- Inconsistent with user expectations for shell command visibility
Metadata
Metadata
Assignees
Labels
No labels
Activity
2asoft commentedon Aug 8, 2025
I ran into this yesterday, and between starting to debug it and filing this report, it went away. I know this sounds dumb :)
Report filed via overly-permissive claude + github mcp config in opencode in the middle of debugging. Feel free to close if you must.
I'm looking into it a bit more to understand why I cant repro this myself anymore.
2asoft commentedon Aug 9, 2025
I believe I was seeing a rendering bug that was (accidentally?) fixed by #1716.
Since it is fixed, there is nothing to report. But I believe the render fix was a side effect, so persisting the details here in case this is useful to the team.
Prior to the above PR
After the above PR
Notice that after toggling tool details off the first time, prior to the PR, the details are said to be off, but in fact render as on, and from there, toggling causes a visual mismatch between what the tooltip says should be and what is actually rendered. If the viewport is scrolled (see end of recording), a re-render happens and the tool display is correct again. Not shown in the recording, but resize and mouse click also trigger the re-render. Possibly other triggers as well, did not look into it any further.
After the PR, toggling tool details works correctly immediately, no scrolling or other input needed.
Looking at the code in the PR, this line stood out:
m.viewport.GotoBottom()It eventually calls
m.memo.Invalidate(), which, given name, I believe causes the re-render. I didnt debug this further than verifying that this call is what fixed it.