[Nowaker]

Note: I'm aware v1 is now the maintenance branch and new features go to v2 only. This PR is here for others to use, and I'll submit the v2 version once I've migrated my whole plugin system to it.

Issue for this PR

Closes #56006

Builds on #54968 (plugin and MCP tool output coloring), which builds on #54704 (bash command coloring). Their commits come first; review only the last commit.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Reads and searches print code from files, and it is drawn plain. syntax.file_output (default off) colors it in each file's language:

• Bash. When the command reads files of one language (cat, head, tail, sed -n, nl, awk, bat, git show <ref>:<path>, chained or piped through filters like head or grep), its output is colored whole. Lines that name their file (path:12:code, path-12-code, path:code, rg headings) are colored per file. A 12: gutter takes the command's language, and so does an rg -t py or --glob '*.rs'. Output that is a whole JSON document or starts like a diff is colored as such.
• read and grep tools. Their rows can be clicked to show the file or the matches as a colored block, and clicked again to fold back.
• Plugin and MCP output that syntax.tool_output leaves alone: GitHub code search snippets (grep_app) in the language of each Path:, docs with fenced code (context7) as markdown, and the line shapes above. A tool set to none stays plain.

Path, line-number and header prefixes are muted; red is never used. Output stays plain when the language is unclear: files of different languages read by one command, a command that also runs something else (ls && cat a.ts), or a pipe through a transform (cat a.json | jq).

Performance: the language is worked out once per finished call, never while it streams or per frame. Each file's lines are highlighted together once in the parser worker and cached by content, and the colors land on whatever part of them the shown text holds, so a collapsed preview is colored like the expanded output. Output over 100,000 characters stays plain, and only the first 64 files of a search are highlighted.

The design comes from ten days of my own tool history: 36,910 of 57,040 bash calls had a read or search stage, 19,673 of them naming files of a single language; there were 12,816 read calls and 873 grep calls.

How did you verify your code works?

• bun typecheck in packages/tui; bun test in packages/tui: 252 pass. Unit tests cover command parsing (pipes, chains, quoting, --type/--glob, git show), every output shape, the read and grep tool formats, code search snippets, and mapping a collapsed preview back onto the output. Frame tests show colored output wraps byte-identically to the plain text at 40, 80 and 160 columns.
• A real TUI (isolated config and database, throwaway tmux socket) at 80 and 160 columns with a grep -n over a .ts file, an rg --heading across .ts and .md, a sed -n of a .py file, a read of a .go file (clicked open) and a grep_app result: the code is in its language's colors, prefixes are muted, and the layout is unchanged.

Go string literals stay plain: nvim-treesitter's Go query captures them again as @spell, which has no style. That affects every Go view, file tools included, and is not changed here.

Screenshots / recordings

rg -n --heading output src, the path and 12: muted, the code colored as TypeScript and markdown:

src/util/file-output.ts
12:export function bashOutputModel(command: string, output: string) {
13:  if (!output) return

README.md
3:## Tool output

Checklist

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

This PR is AI generated, but under direct supervision and on request of @Nowaker.

[github-actions]

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