feat(tui): make file paths in read/grep/glob tool output clickable

[albertofrzara]

Issue for this PR

Relates to #37891 (partial: TUI file-path click only, not desktop/web)

Type of change

• New feature

What does this PR do?

Makes the summary line of Read, Grep, and Glob tool blocks in the TUI clickable. Clicking opens the referenced file (or search root for grep/glob) in $VISUAL/$EDITOR, falling back to code.

I first tried emitting OSC8 terminal hyperlinks from tool output text, but that doesn't work: with mouse: true (the default), opencode's own OpenTUI mouse capture intercepts clicks before the terminal ever sees them, so terminal-native link features (tested in Warp) never fire. The TUI already has an onMouseUp-based Link component and InlineTool already exposes an onClick prop (used today by the Task block), so I reused that same mechanism instead of fighting the terminal.

Added openFileAtLocation() in packages/tui/src/editor.ts — spawns the editor detached (non-blocking), appends --goto file:line:col for VS Code/Cursor/Codium/Windsurf when a line is known, otherwise passes the plain path (needed for grep/glob search roots, which can be directories).

Note: I found #15631 after opening this, which covers overlapping ground with a broader scope and a different mechanism (OS-default-app file:// links vs. editor-targeted --goto). Left details in the comments for maintainers to triage.

How did you verify your code works?

• bun run typecheck in packages/tui — passes clean, no errors.
• bun test --timeout 30000 in packages/tui — 191 pass, 1 skip (pre-existing, unrelated to this change), 0 fail.
• Manually reviewed the new onClick wiring against the existing Task block's usage of the same InlineTool/onClick pattern.

I don't have a way to click through the TUI interactively in my current environment, so I could not manually click-test the feature end-to-end — verification above is typecheck + full existing test suite passing with no regressions, not a manual interaction test.

Screenshots / recordings

Not included — I don't have a way to record the TUI in my current environment. Reviewers can verify by clicking a Read/Grep/Glob line locally.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #15631: feat(tui): add clickable URLs and file paths in tool output
#15631

Why it might be related: This PR also addresses making file paths clickable in TUI tool output. You should check whether it's already merged or closed, and if it overlaps with the current PR's scope (Read/Grep/Glob tools). If it was previously closed/abandoned, the current PR may be a revisit of the same feature with a different implementation approach.

[albertofrzara]

Flagging for maintainers: I found #15631 after opening this, which covers overlapping ground (clickable file paths in TUI tool output) — wanted to be upfront about it rather than let it be discovered later.

Differences, for triage purposes:

• feat(tui): add clickable URLs and file paths in tool output #15631 is broader: also covers Write/Edit/List/WebFetch/bash output, and parses arbitrary text for paths/URLs via a TextWithLinks component. It opens files via file:// + the OS default app (no editor targeting, no line/col jump).
• This PR is narrower (Read/Grep/Glob only) but opens directly via $VISUAL/$EDITOR (falling back to code) with --goto file:line:col support for VS Code/Cursor/Codium/Windsurf, so it jumps to the right line.
• feat(tui): add clickable URLs and file paths in tool output #15631 predates the packages/opencode/src/cli/cmd/tui → packages/tui extraction and is now CONFLICTING, so it'd need a rebase regardless of which approach is preferred.

Happy to close this in favor of #15631 if a maintainer picks that one up and rebases it, adjust scope, or fold the editor-targeting/line-jump behavior into that PR instead — whatever's least duplicate effort for the team.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[wulinsekai]

+1 — this is the exact behavior I want in the TUI. Our workflow generates a lot of file references from read/grep/tool output (mobile monorepo, handover docs), and today every one of them means copy-paste into an editor.

The $VISUAL/$EDITOR → code fallback chain is a good fit (I use Cursor, which is code-compatible). The OSC8 note also matches my experience — with mouse capture on, terminal-native hyperlinks never fire, so an explicit click handler is the right approach.

One suggestion: it'd be great if the click also worked on paths inside regular assistant message text (not just tool output), since handover docs list paths in prose. Looking forward to this landing — happy to test.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.