Built-in Plugins

Taiku ships with five bundled plugins in the default registry. They cover the most common workflows people reach for in collaborative terminal sessions. Each one is also a useful reference: different combinations of panels, permissions, and patterns you can copy when writing your own plugins.

You can enable them from the plugin panel in any session without installing anything.

Agent status, token usage, and cost are already surfaced in the main session UI (tile badges, the activity hub, and agent session drill-in). See Agents. For a raw, filterable stream of every session event—including agent events—use the Event Log plugin below.

When a plugin manifest shows Cmd+Shift+…, read Ctrl+Shift+… on Windows and Linux (same physical chord with the Control key).

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 (see the note above for Ctrl on non-Mac keyboards).

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 in another browser tab (for example reading a design or a code review). 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 project before. Instead of typing ls and tree to explore, you open File Browser and immediately see the project structure: source folder, tests, package metadata, TypeScript config. 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 local preview 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 preview 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 clear example of what plugins can do: event broadcasting for real-time state sync, server-side file storage for audio assets, and coordinated shared experiences that go beyond typical sidebar tools.

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 (see the note above for Ctrl on non-Mac keyboards).

Choosing the right plugin

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

For pure observability, the built-in activity views and Event Log are complementary: the UI highlights what needs attention now; Event Log shows the full chronological stream across every event type.

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 (for example File Browser and Music Player use sidebars, Event Log uses a bottom panel, Chat Notifier uses a background panel)
• Toolbar actions with icons (all visible plugins register toolbar buttons)
• Hotkeys (Event Log and Music Player register default 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, the built-ins are the quickest way to see how panels, permissions, and events fit together in a real session.