Built-in Plugins
What the bundled plugins are for and when to use each one.
Taiku ships these 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.
Install them from the Browse tab of the plugin marketplace: open Settings, expand Integrations, and pick Plugins. The marketplace is there when you are the session's admin.
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 shells opening and closing, user
joins, leaves and focus, agent activity, layout, tile and workspace changes,
terminal title changes, and custom events broadcast by other plugins. It does
not ask for chat.read, so chat messages are not in it.
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. It skips an event when its type and data match the last event of that type. Events appear as timestamped rows with the event type and data payload. The panel has filter buttons (Agent, User, Shell, Terminal, Layout, Tile, Workspace, Plugin) so you can narrow the stream, for example, to only agent events.
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, a collaborator says their view
stopped updating. You filter to User and see a user_left for them a minute
ago, so their connection dropped rather than anything in the session.
Hotkey: Cmd+Shift+Y toggles the panel (see the note above for Ctrl on
non-Mac keyboards).
Chat Notifier
What it does. Chat Notifier shows an in-app toast for messages from other people. It sends a desktop notification and plays a chime only when the taiku tab is in the background. Your own messages are ignored.
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, and desktop notifications
only work once the user allows it. The audio.play permission allows it to play
a notification chime.
How it works. Chat Notifier runs as a background panel with no visible UI.
It subscribes to chat events and calls showToast() for every message from
someone else. It calls sendNotification() for a desktop notification and
playSound() for a brief chime only when the taiku tab is in the background.
Your own messages are ignored. It works even when the chat panel is closed.
Usage scenario. You are pair programming with a colleague while reading a code review in another browser tab. Your colleague sends "ready for review" in the session chat. Since the taiku tab is in the background, Chat Notifier plays a chime and shows a desktop notification with the message. You switch back to taiku and open the chat panel to reply. Your reply does not trigger Chat Notifier.
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
taiku's file viewer. 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 list with a breadcrumb path. Clicking a directory moves into it; clicking a file opens it in taiku's file viewer. 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 add a shell someone else opened to your own workspace.
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
writeToShell bridge method. It can also read terminal output via
getShellOutput 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. Participants who turn on sync follow each other's play, pause and seek through the event broadcast system, so everyone in the sync group hears the same track at the same point.
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 (play, pause, track
changes, seeking) with the other members of the sync group.
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 your own plugin storage. When sync is on and you press play, the plugin broadcasts a playback event to the other instances in the session. Each synced instance that has a track with the same file name starts playing it at the same position. Storage is per person, so everyone in the group uploads the same files.
Usage scenario. You are running a four-hour pair programming session with two colleagues. All three of you have the same lo-fi playlist uploaded and turn on sync. You hit play and everyone hears the same track. 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).
Agent Monitor
What it does. Agent Monitor lists every AI agent taiku has detected across the session's shells, one card per agent, with its current status. An agent leaves the list when it stops. The header counts how many are active and how many are listed, and adds the session's agent cost, and your all-time cost, when the agents report it. The all-time cost is saved to your account, so it carries across sessions, and reloading the page does not count an agent's spend twice. The toolbar button shows how many agents are active.
When to use it. Tile badges already show each agent's state where it runs. Agent Monitor is for when several agents are running across different tiles and you want them in one list without hunting for each tile.
Permissions. events.subscribe, session.read, agent.events, ui.panel,
ui.toolbar.custom and hotkey.register.
How it works. It opens as a sidebar panel from its toolbar button or
Cmd+Shift+A, and updates from agent status events and changes to the shell
list, so it needs no polling.
Break Timer and Integrations Demo
Two examples in the registry exist mainly to show a technique. Break Timer reminds you to step away on a fixed interval, and is one plugin that runs in both the browser and the terminal client from one manifest; see One plugin, both surfaces. Integrations Demo connects a GitHub account and runs its actions; see External Integrations.
Choosing the right plugin
The built-in plugins serve different purposes. Here is a decision matrix to help you pick:
| If you need... | Use this plugin |
|---|---|
| High-level agent status in the workspace | Built-in UI (see Agents); add Event Log for a raw stream |
| Every agent in the session in one list | Agent Monitor |
| A raw event stream for debugging | Event Log |
| Chat notifications when you are not focused | Chat Notifier |
| A graphical file explorer | File Browser |
| A command runner targeting specific terminals | Terminal Commander |
| Shared background music for collaboration | Music Player |
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 to interact with and only delivers notifications.
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, Music Player and Agent Monitor 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.