claude-code - 💡(How to fix) Fix [Feature Request] Add plugin extensibility for TUI input events and output rendering hooks [1 comments, 2 participants]

Description Claude Code's plugin surface today (skills, slash commands, hooks, MCP servers, channels, status line, output styles) is rich for augmenting Claude's behavior but offers no way to augment the TUI itself. Hooks fire on Claude's lifecycle events; nothing fires on user input against rendered output. The chat renderer is closed.

That's a meaningful gap, because a lot of small but high-value developer-experience wins live exactly at that layer. One concrete example:

▎ When Claude mentions a file in chat output (e.g., src/components/auth/session.ts), I'd like to cmd-click it and see an ▎ inline accordion with the file contents or a diff — Quick Look, but in the TUI. Today the path is rendered in blue but the ▎ click does nothing.

I can't build this as a plugin. Not because the idea is hard, but because there's no extension primitive for it.

The ask (extensibility, not the feature)

Three primitives, in increasing scope. Any one of them would unblock a class of plugins, not just this one:

1. Output-pattern renderer hook. Plugins register a regex (or matcher) that runs against rendered output lines. Matches get wrapped in a registered widget type (link, expandable, button). Claude Code stays in charge of layout; plugins just describe the interactive zones.
2. TUI input events. A new hook category — OnClick, OnKeyChord — with target metadata (matched widget ID, position, modifiers). Without this, primitive #1 can render zones but can't react.
3. Inline-expand primitive. A built-in widget type for "click to expand this region into an inline panel" — so plugins don't each reimplement a TUI accordion. Powered by the underlying terminal capabilities Claude Code already uses for its own collapsible regions (tool-call cards, thinking blocks).

Why this unblocks more than just file previews

• Cmd-click on a line/range citation → jump to that line in $EDITOR
• Cmd-click on a PR / issue number → expand the body inline
• Cmd-click on a test name → expand its last failure output
• Hover/preview on a memory entry the assistant cited → show the source file
• Inline diff preview when Claude proposes a multi-file edit

All of these are currently slash-command-shaped today (/peek, /show, /diff) — usable, but a step away from the ergonomic ideal. The cost of typing a command is small per use but it adds up, and it breaks flow when the path is right there in the output.

Lower-effort fallback

If full input events are out of scope short-term, even just (1) — pattern-based renderer hooks that emit a slash-command suggestion when matched would help. Plugins could decorate file paths with a "press Tab to peek" affordance, with no new event system needed.

What I'd build with it

A quick-look plugin that registers a path matcher and on click expands an inline collapsible with the file contents (or a diff against HEAD if it's a tracked file with uncommitted changes). Happy to prototype against an early API.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.123
• Feedback ID: 45b18acb-e34a-440b-b447-80723d566029