Built-in Plugins

Taiku ships with six built-in plugins that cover the most common workflows people reach for in collaborative terminal sessions. These plugins are useful on their own, but they also serve as reference implementations -- each one demonstrates a different combination of plugin surfaces, permissions, and architectural patterns.

All built-in plugins are available immediately in any taiku session. You can enable them from the plugin panel without installing anything.

Agent Monitor

What it does. Agent Monitor provides a real-time dashboard for AI agent activity across all shells in a session. When you have Claude, Codex, OpenCode, or other AI agents running in your terminals, Agent Monitor detects them through escape sequence parsing and pattern matching, then presents their status, token usage, cost tracking, and session history in a single panel.

When to use it. Agent Monitor is designed for sessions where you are running one or more AI coding agents and want to keep track of what they are doing without scanning raw terminal output. If you have three agents working in parallel across different shells, Agent Monitor shows you which ones are active, which are idle, what models they are using, and how much they have spent on API calls.

Permissions. Agent Monitor requires events.subscribe, session.read, agent.events, ui.panel, ui.toolbar.custom, and hotkey.register. The agent.events permission gives it access to the agent session tracking system, which provides structured data about agent activity beyond what you would see in raw terminal output.

How it works. The plugin opens as a sidebar panel (default width 340px) and subscribes to agent events. The panel displays a summary bar at the top with aggregate counts, followed by per-agent cards showing status, model, token usage (input/output/cached), and estimated cost. You can click on an agent card to open the agent session overlay, which shows the full event history for that agent's session.

Usage scenario. You are running Claude Code in three terminals simultaneously -- one refactoring a module, one writing tests, and one updating documentation. Without Agent Monitor, you would need to switch between terminals to check on progress. With it, you glance at the sidebar and see: shell 1 is actively generating (12k tokens used, $0.04), shell 2 is idle at a prompt (completed its task), and shell 3 is in a tool call (reading files). You click on shell 1's card to open the detailed session overlay and review its recent tool calls.

Hotkey: Cmd+Shift+A toggles the panel.

Event Log

What it does. Event Log provides a live, filterable stream of every event that occurs in a taiku session. This includes shell creation and destruction, user joins and leaves, chat messages, plugin events, agent activity, workspace changes, and custom events broadcast by other plugins.

When to use it. Event Log is the debugging tool for understanding what is happening in a session at the event level. It is useful during plugin development (to see what events your plugin is emitting), during collaboration troubleshooting (to see when users connected or disconnected), and in high-traffic sessions where you need a chronological record of activity.

Permissions. Event Log requires session.read, events.subscribe, agent.events, ui.panel, ui.toolbar.custom, and hotkey.register. These are all read-only permissions -- Event Log observes the session without modifying it.

How it works. The plugin opens as a bottom panel (default height 240px) and subscribes to all session events using a wildcard listener. Each event is rendered as a timestamped row with the event type, source, and data payload. The panel includes filtering controls so you can narrow the stream to specific event types -- for example, showing only agent events or only chat messages.

Usage scenario. You are building a custom plugin and want to verify that your broadcastEvent calls are reaching other plugins. You enable Event Log, open your plugin in another panel, trigger the action, and watch the event stream. You see your custom event appear with the correct type and data payload, confirming that the broadcast is working. Later, you notice a collaborator's session is not updating -- you check the event log and see their last heartbeat was 30 seconds ago, confirming a connection issue on their end.

Hotkey: Cmd+Shift+Y toggles the panel.

Chat Notifier

What it does. Chat Notifier ensures you never miss a chat message, even when you are not actively looking at the taiku session. It listens for new chat messages and surfaces them through two channels: in-app toast notifications (brief pop-ups within the taiku UI) and browser desktop notifications (OS-level notifications that appear even when the tab is in the background).

When to use it. Chat Notifier is essential in long-running collaborative sessions where you might be focused on a terminal or working in another application. It is the difference between checking the chat panel every few minutes and being notified the moment someone sends a message.

Permissions. Chat Notifier requires events.subscribe, chat.read, ui.toast, ui.notify, and audio.play. The ui.notify permission triggers a browser permission prompt the first time it fires -- the user must grant notification access for desktop notifications to work. The audio.play permission allows it to play a notification chime.

How it works. Chat Notifier runs as a background panel -- it has no visible UI. It loads a hidden iframe that subscribes to chat events. When a new message arrives, it calls showToast() to display an in-app notification and sendNotification() to trigger a browser desktop notification. It uses playSound() to play a brief chime. Because it runs in the background, it works even when you do not have the chat panel open.

Usage scenario. You are pair programming with a colleague. They are in the session writing code while you are reviewing a PR in another browser tab. Your colleague types "ready for review on the auth module" in the session chat. Chat Notifier plays a chime and shows a desktop notification with the message. You switch back to the taiku tab and see the toast notification fading out. You never had to actively monitor the chat panel.

File Browser

What it does. File Browser provides a graphical file explorer for the session's working directory. It lists files and directories, shows file sizes, and lets you navigate the directory tree -- all without typing ls or find commands in a terminal.

When to use it. File Browser is useful when you want to orient yourself in a project directory, quickly check what files exist, or open files without dropping to a shell prompt. It is particularly helpful in sessions where the working directory is unfamiliar -- for example, when you are joining a collaborator's session and want to understand the project structure.

Permissions. File Browser requires session.read, fs.list, ui.open, ui.panel, ui.toolbar.custom, and ui.toast. The fs.list permission allows it to list directory contents. The ui.open permission lets it open files in the browser. Note that File Browser only reads directory listings -- it does not request fs.read or fs.write, so it cannot read file contents or modify files.

How it works. The plugin opens as a sidebar panel (default width 300px). It calls the filesystem listing bridge method to enumerate files in the working directory and renders them as a navigable tree. Clicking a directory expands it; clicking a file can open it in the browser if appropriate. The panel includes a toolbar button with a folder icon for quick access.

Usage scenario. You join a session where a colleague is debugging a Node.js application. You have never seen this codebase before. Instead of typing ls and tree to explore, you open File Browser and immediately see the project structure: src/, tests/, package.json, tsconfig.json. You click into src/ and see the module layout. In 10 seconds, you have the mental model you need to start helping with the debug.

Terminal Commander

What it does. Terminal Commander provides a command-runner surface that can target specific terminals and display their output within the workspace. It combines terminal read and write capabilities with panel rendering, giving you a dedicated interface for sending commands to shells and viewing their results.

When to use it. Terminal Commander is useful when you want to run commands across multiple terminals from a single control point, or when you want a command interface that is separate from the terminal itself. It is a good tool for orchestration-style workflows -- running a build in one terminal, tests in another, and monitoring output from both in the commander panel.

Permissions. Terminal Commander requires session.read, terminal.read, terminal.write, workspace.read, workspace.write, ui.panel, ui.toolbar.custom, ui.toast, and events.subscribe. This is one of the most permission-heavy built-in plugins because it needs to both read from and write to terminals, and it can manipulate the workspace layout to create new tiles.

How it works. The plugin opens as a sidebar panel (default width 360px). It queries the session for available shells, presents them in a selection interface, and lets you type commands to send to a specific shell. When you send a command, it writes the command text to the selected shell via the terminal.write bridge method. It can also read terminal output via terminal.read to display results directly in the commander panel.

Usage scenario. You have four terminals open: a dev server, a test runner, a database console, and a general-purpose shell. From Terminal Commander, you select the test runner terminal and type npm test -- --grep "auth". The command is sent to that terminal. You switch the selector to the dev server and send npm run build. You are orchestrating multiple terminals from a single panel without switching between tiles.

Music Player

What it does. Music Player lets you upload audio files and play them during a session. Playback state is synchronized across all session participants through the event broadcast system, so everyone hears the same music at the same time. It is a collaborative jukebox built into the terminal workspace.

When to use it. Music Player is designed for intentionally collaborative sessions where ambient music enhances the experience. It is also a compelling proof-of-concept for the plugin system -- it demonstrates event broadcasting for real-time state sync, server-side file storage for audio assets, and coordinated shared experiences beyond developer utilities.

Permissions. Music Player requires ui.panel, ui.toolbar.custom, ui.toast, events.subscribe, events.broadcast, storage.read, storage.write, session.read, and hotkey.register. The storage.read and storage.write permissions let it persist uploaded audio files on the server. The events.broadcast permission lets it sync playback state (play, pause, skip, volume) across all connected clients.

How it works. The plugin opens as a sidebar panel (default width 300px, height 340px). You upload audio files through the panel UI, and they are stored in the plugin's server-side file storage. When you press play, the plugin broadcasts a playback event to all other instances of the plugin in the session. Each instance receives the event and starts playing the same track at the same position. The plugin uses the audio.play permission for playback.

Usage scenario. You are running a four-hour pair programming session with two colleagues. You open Music Player, upload a lo-fi playlist, and hit play. All three participants hear the music. When one person pauses playback to take a call, the music pauses for everyone. When they resume, it picks back up. The shared music creates a sense of presence that goes beyond terminal output and chat messages.

Hotkey: Cmd+Shift+M toggles the panel.

Choosing the right plugin

The built-in plugins serve different purposes. Here is a decision matrix to help you pick:

For pure observability, Agent Monitor and Event Log are complementary. Agent Monitor gives you a structured, agent-focused view; Event Log gives you the raw event stream across all event types.

For hands-on tooling, File Browser and Terminal Commander address different needs. File Browser is read-only and focused on navigation. Terminal Commander is read-write and focused on command execution.

Chat Notifier stands alone as a background utility -- it has no panel you interact with, just quiet notification delivery.

Music Player demonstrates the outer boundary of what plugins can do: shared state, file storage, real-time synchronization, and media playback.

What these plugins demonstrate

Beyond their direct utility, the built-in plugins collectively demonstrate every surface the plugin system supports:

• Sidebar, bottom, and background panels (Agent Monitor uses sidebar, Event Log uses bottom, Chat Notifier uses a background panel)
• Toolbar actions with icons (all visible plugins register toolbar buttons)
• Hotkeys (Agent Monitor, Event Log, and Music Player register keyboard shortcuts)
• Event subscription and broadcasting (Event Log subscribes to all events, Music Player broadcasts playback state)
• Session and terminal read/write (Terminal Commander reads and writes to shells)
• Filesystem access (File Browser lists directory contents)
• Server-side file storage (Music Player stores audio files)
• Desktop notifications and audio (Chat Notifier uses both)

If you are building a custom plugin, studying these implementations is the fastest way to understand how the plugin system works in practice.