Atomic can create extensions. Ask it to build one for your use case.
Extensions
Extensions are TypeScript modules that extend Atomic’s behavior. They can subscribe to lifecycle events, register custom tools callable by the LLM, add commands, and more.Placement for /reload: Put extensions inKey capabilities:~/.atomic/agent/extensions/(global) or.atomic/extensions/(project-local) for auto-discovery; legacy.pipaths remain supported. Useatomic -e ./path.tsonly for quick tests. Extensions in auto-discovered locations can be hot-reloaded with/reload.
- Custom tools - Register tools the LLM can call via
pi.registerTool() - Event interception - Block or modify tool calls, inject context, customize compaction
- User interaction - Prompt users via
ctx.ui(select, confirm, input, notify) - Custom UI components - Full TUI components with keyboard input via
ctx.ui.custom()for complex interactions - Custom commands - Register commands like
/mycommandviapi.registerCommand() - Session persistence - Store state that survives restarts via
pi.appendEntry() - Custom rendering - Control how tool calls/results and messages appear in TUI
- Permission gates (confirm before
rm -rf,sudo, etc.) - Git checkpointing (stash at each turn, restore on branch)
- Path protection (block writes to
.env,node_modules/) - Custom compaction (summarize conversation your way)
- Conversation summaries (see
summarize.tsexample) - Interactive tools (questions, wizards, custom dialogs)
- Stateful tools (todo lists, connection pools)
- External integrations (file watchers, webhooks, CI triggers)
- Games while you wait (see
snake.tsexample)
Table of Contents
- Quick Start
- Extension Locations
- Available Imports
- Writing an Extension
- Events
- ExtensionContext
- ExtensionCommandContext
- ExtensionAPI Methods
- State Management
- Custom Tools
- Custom UI
- Error Handling
- Mode Behavior
- Examples Reference
Quick Start
Create~/.atomic/agent/extensions/my-extension.ts:
--extension (or -e) flag:
Extension Locations
Security: Extensions run with your full system permissions and can execute arbitrary code. Only install from sources you trust.Extensions are auto-discovered from:
| Location | Scope |
|---|---|
~/.atomic/agent/extensions/*.ts | Global (all projects) |
~/.atomic/agent/extensions/*/index.ts | Global (subdirectory) |
.atomic/extensions/*.ts | Project-local |
.atomic/extensions/*/index.ts | Project-local (subdirectory) |
settings.json:
Available Imports
| Package | Purpose |
|---|---|
@bastani/atomic | Extension types (ExtensionAPI, ExtensionContext, events) |
typebox | Schema definitions for tool parameters |
@earendil-works/pi-ai | AI utilities (StringEnum for Google-compatible enums) |
@earendil-works/pi-tui | TUI components for custom rendering |
package.json next to your extension (or in a parent directory), then install dependencies with Bun:
node_modules/ are resolved automatically.
For distributed Atomic packages installed with atomic install (npm or git), runtime deps must be in dependencies. Package installation uses production dependency installs by default, so devDependencies are not available at runtime; when npmCommand is configured, git packages use plain install for compatibility with wrappers.
Node.js built-ins (node:fs, node:path, etc.) are also available.
Writing an Extension
An extension exports a default factory function that receivesExtensionAPI. The factory can be synchronous or asynchronous:
Promise, Atomic awaits it before continuing startup. That means async initialization completes before session_start, before resources_discover, and before provider registrations queued via pi.registerProvider() are flushed.
Async factory functions
Use an async factory for one-time startup work such as fetching remote configuration or dynamically discovering available models.atomic --list-models.
Extension Styles
Single file - simplest, for small extensions:atomic here, from the running Atomic package/config), not the extension package’s own "name" field. The legacy pi key is still accepted as a compatibility shim. Run bun install in the extension directory, then imports from node_modules/ work automatically.
Events
Lifecycle Overview
Resource Events
resources_discover
Fired aftersession_start so extensions can contribute additional skill, prompt, and theme paths.
The startup path uses reason: "startup". Reload uses reason: "reload".
Session Events
See Session Format for session storage internals and the SessionManager API.session_start
Fired when a session is started, loaded, or reloaded.session_before_switch
Fired before starting a new session (/new) or switching sessions (/resume).
session_shutdown for the old extension instance, reloads and rebinds extensions for the new session, then emits session_start with reason: "new" | "resume" and previousSessionFile.
Do cleanup work in session_shutdown, then reestablish any in-memory state in session_start.
session_before_fork
Fired when forking via/fork or cloning via /clone.
session_shutdown for the old extension instance, reloads and rebinds extensions for the new session, then emits session_start with reason: "fork" and previousSessionFile.
Do cleanup work in session_shutdown, then reestablish any in-memory state in session_start.
session_before_compact / session_compact
Fired on compaction. See Compaction for details.session_before_tree / session_tree
Fired on/tree navigation. See Sessions for tree navigation concepts.
session_shutdown
Fired before an extension runtime is torn down.Agent Events
before_agent_start
Fired after user submits prompt, before agent loop. Can inject a message and/or modify the system prompt.systemPromptOptions field gives extensions access to the same structured data Atomic uses to build the system prompt. This lets you inspect what Atomic has loaded — custom prompts, guidelines, tool snippets, context files, skills — without re-discovering resources or re-parsing flags. Use it when your extension needs to make deep, informed changes to the system prompt while respecting user-provided configuration.
Inside before_agent_start, event.systemPrompt and ctx.getSystemPrompt() both reflect the chained system prompt as of the current handler. Later before_agent_start handlers can still modify it again.
agent_start / agent_end
Fired once per user prompt.turn_start / turn_end
Fired for each turn (one LLM response + tool calls).message_start / message_update / message_end
Fired for message lifecycle updates.message_startandmessage_endfire for user, assistant, and toolResult messages.message_updatefires for assistant streaming updates.message_endhandlers can return{ message }to replace the finalized message. The replacement must keep the samerole.
tool_execution_start / tool_execution_update / tool_execution_end
Fired for tool execution lifecycle updates. In parallel tool mode:tool_execution_startis emitted in assistant source order during the preflight phasetool_execution_updateevents may interleave across toolstool_execution_endis emitted in tool completion order after each tool is finalized- final
toolResultmessage events are still emitted later in assistant source order
context
Fired before each LLM call. Modify messages non-destructively. See Session Format for message types.before_provider_request
Fired after the provider-specific payload is built, right before the request is sent. Handlers run in extension load order. Returningundefined keeps the payload unchanged. Returning any other value replaces the payload for later handlers and for the actual request.
This hook can rewrite provider-level system instructions or remove them entirely. Those payload-level changes are not reflected by ctx.getSystemPrompt(), which reports Atomic’s system prompt string rather than the final serialized provider payload.
after_provider_response
Fired after an HTTP response is received and before its stream body is consumed. Handlers run in extension load order.Model Events
model_select
Fired when the model changes via/model command, model cycling (CTRL+P), or session restore.
thinking_level_select
Fired when the thinking level changes. This is notification-only; handler return values are ignored.pi.setThinkingLevel(), model changes, or built-in thinking-level controls change the active thinking level.
Tool Events
tool_call
Fired aftertool_execution_start, before the tool executes. Can block. Use isToolCallEventType to narrow and get typed inputs.
Before tool_call runs, Atomic waits for previously emitted Agent events to finish draining through AgentSession. This means ctx.sessionManager is up to date through the current assistant tool-calling message.
In the default parallel tool execution mode, sibling tool calls from the same assistant message are preflighted sequentially, then executed concurrently. tool_call is not guaranteed to see sibling tool results from that same assistant message in ctx.sessionManager.
event.input is mutable. Mutate it in place to patch tool arguments before execution.
Behavior guarantees:
- Mutations to
event.inputaffect the actual tool execution - Later
tool_callhandlers see mutations made by earlier handlers - No re-validation is performed after your mutation
- Return values from
tool_callonly control blocking via{ block: true, reason?: string }
Typing custom tool input
Custom tools should export their input type:isToolCallEventType with explicit type parameters:
tool_result
Fired after tool execution finishes and beforetool_execution_end plus the final tool result message events are emitted. Can modify result.
In parallel tool mode, tool_result and tool_execution_end may interleave in tool completion order, while final toolResult message events are still emitted later in assistant source order.
tool_result handlers chain like middleware:
- Handlers run in extension load order
- Each handler sees the latest result after previous handler changes
- Handlers can return partial patches (
content,details, orisError); omitted fields keep their current values
ctx.signal for nested async work inside the handler. This lets Escape cancel model calls, fetch(), and other abort-aware operations started by the extension.
User Bash Events
user_bash
Fired when user executes! or !! commands. Can intercept.
Input Events
input
Fired when user input is received, after extension commands are checked but before skill and template expansion. The event sees the raw input text, so/skill:foo and /template are not yet expanded.
Processing order:
- Extension commands (
/cmd) checked first - if found, handler runs and input event is skipped inputevent fires - can intercept, transform, or handle- If not handled: skill commands (
/skill:name) expanded to skill content - If not handled: prompt templates (
/template) expanded to template content - Agent processing begins (
before_agent_start, etc.)
continue- pass through unchanged (default if handler returns nothing)transform- modify text/images, then continue to expansionhandled- skip agent entirely (first handler to return this wins)
ExtensionContext
All handlers receivectx: ExtensionContext.
ctx.ui
UI methods for user interaction. See Custom UI for full details.ctx.hasUI
false in print mode (-p) and JSON mode. true in interactive and RPC mode. In RPC mode, dialog methods (select, confirm, input, editor) work via the extension UI sub-protocol, and fire-and-forget methods (notify, setStatus, setWidget, setTitle, setEditorText) emit requests to the client. Some TUI-specific methods are no-ops or return defaults (see RPC mode).
ctx.cwd
Current working directory.ctx.sessionManager
Read-only access to session state. See Session Format for the full SessionManager API and entry types. Fortool_call, this state is synchronized through the current assistant message before handlers run. In parallel tool execution mode it is still not guaranteed to include sibling tool results from the same assistant message.
ctx.modelRegistry / ctx.model
Access to models and API keys.ctx.signal
The current agent abort signal, orundefined when no agent turn is active.
Use this for abort-aware nested work started by extension handlers, for example:
fetch(..., { signal: ctx.signal })- model calls that accept
signal - file or process helpers that accept
AbortSignal
ctx.signal is typically defined during active turn events such as tool_call, tool_result, message_update, and turn_end.
It is usually undefined in idle or non-turn contexts such as session events, extension commands, and shortcuts fired while Atomic is idle.
ctx.isIdle() / ctx.abort() / ctx.hasPendingMessages()
Control flow helpers.ctx.shutdown()
Request a graceful shutdown of Atomic.- Interactive mode: Deferred until the agent becomes idle (after processing all queued steering and follow-up messages).
- RPC mode: Deferred until the next idle state (after completing the current command response, when waiting for the next command).
- Print mode: No-op. The process exits automatically when all prompts are processed.
session_shutdown event to all extensions before exiting. Available in all contexts (event handlers, tools, commands, shortcuts).
ctx.getContextUsage()
Returns current context usage for the active model. Uses last assistant usage when available, then estimates tokens for trailing messages.ctx.compact()
Trigger compaction without awaiting completion. UseonComplete and onError for follow-up actions.
ctx.getSystemPrompt()
Returns Atomic’s current system prompt string.- During
before_agent_start, this reflects chained system-prompt changes made so far for the current turn. - It does not include later
contextmessage mutations. - It does not include
before_provider_requestpayload rewrites. - If later-loaded extensions run after yours, they can still change what is ultimately sent.
ExtensionCommandContext
Command handlers receiveExtensionCommandContext, which extends ExtensionContext with session control methods. These are only available in commands because they can deadlock if called from event handlers.
ctx.waitForIdle()
Wait for the agent to finish streaming:ctx.newSession(options?)
Create a new session:parentSession: parent session file to record in the new session headersetup: mutate the new session’sSessionManagerbeforewithSessionrunswithSession: run post-switch work against a fresh replacement-session context. Do not use captured oldpi/ commandctx; see Session replacement lifecycle and footguns.
ctx.fork(entryId, options?)
Fork from a specific entry, creating a new session file:position:"before"(default) forks before the selected user message, restoring that prompt into the editorposition:"at"duplicates the active path through the selected entry without restoring editor textwithSession: run post-switch work against a fresh replacement-session context. Do not use captured oldpi/ commandctx; see Session replacement lifecycle and footguns.
ctx.navigateTree(targetId, options?)
Navigate to a different point in the session tree:summarize: Whether to generate a summary of the abandoned branchcustomInstructions: Custom instructions for the summarizerreplaceInstructions: If true,customInstructionsreplaces the default prompt instead of being appendedlabel: Label to attach to the branch summary entry (or target entry if not summarizing)
ctx.switchSession(sessionPath, options?)
Switch to a different session file:withSession: run post-switch work against a fresh replacement-session context. Do not use captured oldpi/ commandctx; see Session replacement lifecycle and footguns.
SessionManager.list() or SessionManager.listAll() methods:
Session replacement lifecycle and footguns
withSession receives a fresh ReplacedSessionContext, which extends ExtensionCommandContext with async sendMessage() and sendUserMessage() helpers bound to the replacement session.
Lifecycle and footguns:
withSessionruns only after the old session has emittedsession_shutdown, the old runtime has been torn down, the replacement session has been rebound, and the new extension instance has already receivedsession_start.- The callback still executes in the original closure, not inside the new extension instance. That means your old extension instance may already have run its shutdown cleanup before
withSessionstarts. - Captured old
pi/ old commandctxsession-bound objects are stale after replacement and will throw if used. Use only thectxpassed towithSessionfor session-bound work. - Previously extracted raw objects are still your responsibility. For example, if you capture
const sm = ctx.sessionManagerbefore replacement,smis still the oldSessionManagerobject. Do not reuse it after replacement. - Code in
withSessionshould assume any state invalidated by yoursession_shutdownhandler is already gone. Only capture plain data that survives shutdown cleanly, such as strings, ids, and serialized config.
ctx.reload()
Run the same reload flow as/reload.
await ctx.reload()emitssession_shutdownfor the current extension runtime- It then reloads resources and emits
session_startwithreason: "reload"andresources_discoverwith reason"reload" - The currently running command handler still continues in the old call frame
- Code after
await ctx.reload()still runs from the pre-reload version - Code after
await ctx.reload()must not assume old in-memory extension state is still valid - After the handler returns, future commands/events/tool calls use the new extension version
await ctx.reload(); return;).
Tools run with ExtensionContext, so they cannot call ctx.reload() directly. Use a command as the reload entrypoint, then expose a tool that queues that command as a follow-up user message.
Example tool the LLM can call to trigger reload:
ExtensionAPI Methods
pi.on(event, handler)
Subscribe to events. See Events for event types and return values.pi.registerTool(definition)
Register a custom tool callable by the LLM. See Custom Tools for full details.pi.registerTool() works both during extension load and after startup. You can call it inside session_start, command handlers, or other event handlers. New tools are refreshed immediately in the same session, so they appear in pi.getAllTools() and are callable by the LLM without /reload.
Use pi.setActiveTools() to enable or disable tools (including dynamically added tools) at runtime.
Use promptSnippet to opt a custom tool into a one-line entry in Available tools, and promptGuidelines to append tool-specific bullets to the default Guidelines section when the tool is active.
Important: promptGuidelines bullets are appended flat to the Guidelines section with no tool name prefix. Each guideline must name the tool it refers to — avoid “Use this tool when…” because the LLM cannot tell which tool “this” means. Write “Use my_tool when…” instead.
See dynamic-tools.ts for a full example.
pi.sendMessage(message, options?)
Inject a custom message into the session.deliverAs- Delivery mode:"steer"(default) - Queues the message while streaming. Delivered after the current assistant turn finishes executing its tool calls, before the next LLM call."followUp"- Waits for agent to finish. Delivered only when agent has no more tool calls."nextTurn"- Queued for next user prompt. Does not interrupt or trigger anything."interrupt"- WithtriggerTurn: true, aborts an active streaming turn and immediately starts a new turn with the custom message. When idle, behaves like a triggered custom message.
triggerTurn: true- If agent is idle, trigger an LLM response immediately. Required for"interrupt"; ignored for"nextTurn".excludeFromContext: true- Render and persist the custom message without adding it to LLM context. With nodeliverAs, this remains display-only even while the agent is streaming.interruptAbortMessage- Optional text used to replace generic abort results (for exampleOperation aborted) whendeliverAs: "interrupt"aborts an active turn.
pi.sendUserMessage(content, options?)
Send a user message to the agent. UnlikesendMessage() which sends custom messages, this sends an actual user message that appears as if typed by the user. Always triggers a turn.
deliverAs- Required when agent is streaming:"steer"- Queues the message for delivery after the current assistant turn finishes executing its tool calls"followUp"- Waits for agent to finish all tools
deliverAs, throws an error.
See send-user-message.ts for a complete example.
pi.appendEntry(customType, data?)
Persist extension state (does NOT participate in LLM context).pi.setSessionName(name)
Set the session display name (shown in session selector instead of first message).pi.getSessionName()
Get the current session name, if set.pi.setLabel(entryId, label)
Set or clear a label on an entry. Labels are user-defined markers for bookmarking and navigation (shown in/tree selector).
pi.registerCommand(name, options)
Register a command. If multiple extensions register the same command name, Atomic keeps them all and assigns numeric invocation suffixes in load order, for example/review:1 and /review:2.
/command ...:
pi.getCommands()
Get the slash commands available for invocation viaprompt in the current session. Includes extension commands, prompt templates, and skill commands.
The list matches the RPC get_commands ordering: extensions first, then templates, then skills.
sourceInfo as the canonical provenance field. Do not infer ownership from command names or from ad hoc path parsing.
Built-in interactive commands (like /model and /settings) are not included here. They are handled only in interactive
mode and would not execute if sent via prompt.
pi.registerMessageRenderer(customType, renderer)
Register a custom TUI renderer for messages with yourcustomType. See Custom UI.
pi.registerShortcut(shortcut, options)
Register a keyboard shortcut. See Keybindings for the shortcut format and built-in keybindings.pi.registerFlag(name, options)
Register a CLI flag.pi.exec(command, args, options?)
Execute a shell command.pi.getActiveTools() / pi.getAllTools() / pi.setActiveTools(names)
Manage active tools. This works for both built-in tools and dynamically registered tools.pi.getAllTools() returns name, description, parameters, and sourceInfo.
Typical sourceInfo.source values:
builtinfor built-in toolssdkfor tools passed viacreateAgentSession({ customTools })- extension source metadata for tools registered by extensions
pi.setModel(model)
Set the current model. Returnsfalse if no API key is available for the model. See Custom models for configuring custom models.
pi.getThinkingLevel() / pi.setThinkingLevel(level)
Get or set the thinking level. Level is clamped to model capabilities (non-reasoning models always use “off”). Changes emitthinking_level_select.
pi.events
Shared event bus for communication between extensions:pi.registerProvider(name, config)
Register or override a model provider dynamically. Useful for proxies, custom endpoints, or team-wide model configurations. Calls made during the extension factory function are queued and applied once the runner initialises. Calls made after that — for example from a command handler following a user setup flow — take effect immediately without requiring a/reload.
If you need to discover models from a remote endpoint, prefer an async extension factory over deferring the fetch to session_start. Atomic waits for the factory before startup continues, so the registered models are available immediately, including to atomic --list-models.
name- Display name for the provider in UI such as/login.baseUrl- API endpoint URL. Required when defining models.apiKey- API key or environment variable name. Required when defining models (unlessoauthprovided).api- API type:"anthropic-messages","openai-completions","openai-responses", etc.headers- Custom headers to include in requests.authHeader- If true, addsAuthorization: Bearerheader automatically.models- Array of model definitions. If provided, replaces all existing models for this provider. Model definitions can setbaseUrlto override the provider endpoint for that model.oauth- OAuth provider config for/loginsupport. When provided, the provider appears in the login menu.streamSimple- Custom streaming implementation for non-standard APIs.
pi.unregisterProvider(name)
Remove a previously registered provider and its models. Built-in models that were overridden by the provider are restored. Has no effect if the provider was not registered. LikeregisterProvider, this takes effect immediately when called after the initial load phase, so a /reload is not required.
State Management
Extensions with state should store it in tool resultdetails for proper branching support:
Custom Tools
Register tools the LLM can call viapi.registerTool(). Tools appear in the system prompt and can have custom rendering.
Use promptSnippet for a short one-line entry in the Available tools section in the default system prompt. If omitted, custom tools are left out of that section.
Use promptGuidelines to add tool-specific bullets to the default system prompt Guidelines section. These bullets are included only while the tool is active (for example, after pi.setActiveTools([...])).
Important: promptGuidelines bullets are appended flat to the Guidelines section with no tool name prefix or grouping. Each guideline must name the tool it refers to — avoid “Use this tool when…” because the LLM cannot tell which tool “this” means. Write “Use my_tool when…” instead.
Note: Some models are idiots and include the @ prefix in tool path arguments. Built-in tools strip a leading @ before resolving paths. If your custom tool accepts a path, normalize a leading @ as well.
If your custom tool mutates files, use withFileMutationQueue() so it participates in the same per-file queue as built-in edit and write. This matters because tool calls run in parallel by default. Without the queue, two tools can read the same old file contents, compute different updates, and then whichever write lands last overwrites the other.
Example failure case: your custom tool edits foo.ts while built-in edit also changes foo.ts in the same assistant turn. If your tool does not participate in the queue, both can read the original foo.ts, apply separate changes, and one of those changes is lost.
Pass the real target file path to withFileMutationQueue(), not the raw user argument. Resolve it to an absolute path first, relative to ctx.cwd or your tool’s working directory. For existing files, the helper canonicalizes through realpath(), so symlink aliases for the same file share one queue. For new files, it falls back to the resolved absolute path because there is nothing to realpath() yet.
Queue the entire mutation window on that target path. That includes read-modify-write logic, not just the final write.
Tool Definition
isError: true on the result and reports it to the LLM), throw an error from execute. Returning a value never sets the error flag regardless of what properties you include in the return object.
Early termination: Return terminate: true from execute() to hint that the automatic follow-up LLM call should be skipped after the current tool batch. This only takes effect when every finalized tool result in that batch is terminating. See examples/extensions/structured-output.ts for a minimal example where the agent ends on a final structured-output tool call.
StringEnum from @earendil-works/pi-ai for string enums. Type.Union/Type.Literal doesn’t work with Google’s API.
Argument preparation: prepareArguments(args) is optional. If defined, it runs before schema validation and before execute(). Use it to mimic an older accepted input shape when Atomic resumes an older session whose stored tool call arguments no longer match the current schema. Return the object you want validated against parameters. Keep the public schema strict. Do not add deprecated compatibility fields to parameters just to keep old resumed sessions working.
Example: an older session may contain an edit tool call with top-level oldText and newText, while the current schema only accepts edits: [{ oldText, newText }].
Overriding Built-in Tools
Extensions can override built-in tools (read, bash, edit, write, grep, find, ls) by registering a tool with the same name. Interactive mode displays a warning when this happens.
--no-builtin-tools to start without any built-in tools while keeping extension tools enabled:
read with logging and access control.
Rendering: Built-in renderer inheritance is resolved per slot. Execution override and rendering override are independent. If your override omits renderCall, the built-in renderCall is used. If your override omits renderResult, the built-in renderResult is used. If your override omits both, the built-in renderer is used automatically (syntax highlighting, diffs, etc.). This lets you wrap built-in tools for logging or access control without reimplementing the UI.
Prompt metadata: promptSnippet and promptGuidelines are not inherited from the built-in tool. If your override should keep those prompt instructions, define them on the override explicitly.
Your implementation must match the exact result shape, including the details type. The UI and session logic depend on these shapes for rendering and state tracking.
Built-in tool implementations:
- read.ts -
ReadToolDetails - bash.ts -
BashToolDetails - edit.ts
- write.ts
- grep.ts -
GrepToolDetails - find.ts -
FindToolDetails - ls.ts -
LsToolDetails
Remote Execution
Built-in tools support pluggable operations for delegating to remote systems (SSH, containers, etc.):ReadOperations, WriteOperations, EditOperations, BashOperations, LsOperations, GrepOperations, FindOperations
For user_bash, extensions can reuse atomic’s local shell backend via createLocalBashOperations() instead of reimplementing local process spawning, shell resolution, and process-tree termination.
The bash tool also supports a spawn hook to adjust the command, cwd, or env before execution:
--ssh flag.
Output Truncation
Tools MUST truncate their output to avoid overwhelming the LLM context. Large outputs can cause:- Context overflow errors (prompt too long)
- Compaction failures
- Degraded model performance
- Use
truncateHeadfor content where the beginning matters (search results, file reads) - Use
truncateTailfor content where the end matters (logs, command output) - Always inform the LLM when output is truncated and where to find the full version
- Document the truncation limits in your tool’s description
rg (ripgrep) with proper truncation.
Multiple Tools
One extension can register multiple tools with shared state:Custom Rendering
Tools can providerenderCall and renderResult for custom TUI display. See TUI components for the full component API and tool-execution.ts for how tool rows are composed.
By default, tool output is wrapped in a Box that handles padding and background. A defined renderCall or renderResult must return a Component. If a slot renderer is not defined, tool-execution.ts uses fallback rendering for that slot.
Set renderShell: "self" when the tool should render its own shell instead of using the default Box. This is useful for tools that need complete control over framing or background behavior, for example large previews that must stay visually stable after the tool settles.
renderCall and renderResult each receive a context object with:
args- the current tool call argumentsstate- shared row-local state acrossrenderCallandrenderResultlastComponent- the previously returned component for that slot, if anyinvalidate()- request a rerender of this tool rowtoolCallId,cwd,executionStarted,argsComplete,isPartial,expanded,showImages,isError
context.state for cross-slot shared state. Keep slot-local caches on the returned component instance when you want to reuse and mutate the same component across renders.
renderCall
Renders the tool call or header:renderResult
Renders the tool result or output:Component such as an empty Container.
Keybinding Hints
UsekeyHint() to display keybinding hints that respect the active keybinding configuration:
keyHint(keybinding, description)- Formats a configured keybinding id such as"app.tools.expand"or"tui.select.confirm"keyText(keybinding)- Returns the raw configured key text for a keybinding idrawKeyHint(key, description)- Format a raw key string
- Coding-agent ids use the
app.*namespace, for exampleapp.tools.expand,app.editor.external,app.session.rename - Shared TUI ids use the
tui.*namespace, for exampletui.select.confirm,tui.select.cancel,tui.input.tab
keybindings.json uses those same namespaced ids.
Custom editors and ctx.ui.custom() components receive keybindings: KeybindingsManager as an injected argument. They should use that injected manager directly instead of calling getKeybindings() or setKeybindings().
Best Practices
- Use
Textwith padding(0, 0). The default Box handles padding. - Use
\nfor multi-line content. - Handle
isPartialfor streaming progress. - Support
expandedfor detail on demand. - Keep default view compact.
- Read
context.argsinrenderResultinstead of copying args intocontext.state. - Use
context.stateonly for data that must be shared across call and result slots. - Reuse
context.lastComponentwhen the same component instance can be updated in place. - Use
renderShell: "self"only when the default boxed shell gets in the way. In self-shell mode the tool is responsible for its own framing, padding, and background.
Fallback
If a slot renderer is not defined or throws:renderCall: Shows the tool namerenderResult: Shows raw text fromcontent
Custom UI
Extensions can interact with users viactx.ui methods and customize how messages/tools render.
For custom components, see TUI components which has copy-paste patterns for:
- Selection dialogs (SelectList)
- Async operations with cancel (BorderedLoader)
- Settings toggles (SettingsList)
- Status indicators (setStatus)
- Working message, visibility, and indicator during streaming (
setWorkingMessage,setWorkingVisible,setWorkingIndicator) - Widgets above/below editor (setWidget)
- Autocomplete providers layered on top of built-in slash/path completion (addAutocompleteProvider)
- Custom footers (setFooter)
Dialogs
Timed Dialogs with Countdown
Dialogs support atimeout option that auto-dismisses with a live countdown display:
select()returnsundefinedconfirm()returnsfalseinput()returnsundefined
Manual Dismissal with AbortSignal
For more control (e.g., to distinguish timeout from user cancel), useAbortSignal:
Widgets, Status, and Footer
ctx.ui.theme.fg(...).
Autocomplete Providers
Usectx.ui.addAutocompleteProvider() to stack custom autocomplete logic on top of the built-in slash-command and path provider.
Typical pattern:
- inspect the text before the cursor
- return your own suggestions when your extension-specific syntax matches
- otherwise delegate to
current.getSuggestions(...) - delegate
applyCompletion(...)unless you need custom insertion behavior
gh issue list and filters them locally for fast #... completion. It requires GitHub CLI (gh) and a GitHub repository checkout.
Custom Components
For complex UI, usectx.ui.custom(). This temporarily replaces the editor with your component until done() is called:
tui- TUI instance (for screen dimensions, focus management)theme- Current theme for stylingkeybindings- App keybinding manager (for checking shortcuts)done(value)- Call to close component and return value
{ signal } to dismiss the custom UI if an operation is aborted; the returned promise rejects with the signal reason.
See TUI components for the full component API.
Overlay Mode (Experimental)
Pass{ overlay: true } to render the component as a floating modal on top of existing content, without clearing the screen:
overlayOptions. Use onHandle to control visibility programmatically:
OverlayOptions API and overlay-qa-tests.ts for examples.
Custom Editor
Replace the main input editor with a custom implementation (vim mode, emacs mode, etc.):- Extend
CustomEditor(not baseEditor) to get app keybindings (escape to abort, ctrl+d, model switching) - Call
super.handleInput(data)for keys you don’t handle - Factory receives
themeandkeybindingsfrom the app - Use
ctx.ui.getEditorComponent()beforesetEditorComponent()to wrap the previously configured custom editor - Pass
undefinedto restore default:ctx.ui.setEditorComponent(undefined)
Message Rendering
Register a custom renderer for messages with yourcustomType:
pi.sendMessage():
Theme Colors
All render functions receive atheme object. See Themes for creating custom themes and the full color palette.
Error Handling
- Extension errors are logged, agent continues
tool_callerrors block the tool (fail-safe)- Tool
executeerrors must be signaled by throwing; the thrown error is caught, reported to the LLM withisError: true, and execution continues
Mode Behavior
In non-interactive modes, check
ctx.hasUI before using UI methods.
Examples Reference
All examples in examples/extensions/.| Example | Description | Key APIs |
|---|---|---|
| Tools | ||
hello.ts | Minimal tool registration | registerTool |
question.ts | Tool with user interaction | registerTool, ui.select |
questionnaire.ts | Multi-step wizard tool | registerTool, ui.custom |
todo.ts | Stateful tool with persistence | registerTool, appendEntry, renderResult, session events |
dynamic-tools.ts | Register tools after startup and during commands | registerTool, session_start, registerCommand |
structured-output.ts | Final structured-output tool with terminate: true | registerTool, terminating tool results |
truncated-tool.ts | Output truncation example | registerTool, truncateHead |
tool-override.ts | Override built-in read tool | registerTool (same name as built-in) |
| Commands | ||
pirate.ts | Modify system prompt per-turn | registerCommand, before_agent_start |
summarize.ts | Conversation summary command | registerCommand, ui.custom |
handoff.ts | Cross-provider model handoff | registerCommand, ui.editor, ui.custom |
qna.ts | Q&A with custom UI | registerCommand, ui.custom, setEditorText |
send-user-message.ts | Inject user messages | registerCommand, sendUserMessage |
reload-runtime.ts | Reload command and LLM tool handoff | registerCommand, ctx.reload(), sendUserMessage |
shutdown-command.ts | Graceful shutdown command | registerCommand, shutdown() |
| Events & Gates | ||
permission-gate.ts | Block dangerous commands | on("tool_call"), ui.confirm |
protected-paths.ts | Block writes to specific paths | on("tool_call") |
confirm-destructive.ts | Confirm session changes | on("session_before_switch"), on("session_before_fork") |
dirty-repo-guard.ts | Warn on dirty git repo | on("session_before_*"), exec |
input-transform.ts | Transform user input | on("input") |
model-status.ts | React to model changes | on("model_select"), setStatus |
provider-payload.ts | Inspect payloads and provider response headers | on("before_provider_request"), on("after_provider_response") |
system-prompt-header.ts | Display system prompt info | on("agent_start"), getSystemPrompt |
claude-rules.ts | Load rules from files | on("session_start"), on("before_agent_start") |
prompt-customizer.ts | Add context-aware tool guidance using systemPromptOptions | on("before_agent_start"), BuildSystemPromptOptions |
file-trigger.ts | File watcher triggers messages | sendMessage |
| Compaction & Sessions | ||
custom-compaction.ts | Custom compaction summary | on("session_before_compact") |
trigger-compact.ts | Trigger compaction manually | compact() |
git-checkpoint.ts | Git stash on turns | on("turn_start"), on("session_before_fork"), exec |
auto-commit-on-exit.ts | Commit on shutdown | on("session_shutdown"), exec |
| UI Components | ||
status-line.ts | Footer status indicator | setStatus, session events |
working-indicator.ts | Customize the streaming working indicator | setWorkingIndicator, registerCommand |
github-issue-autocomplete.ts | Add #1234 issue completions on top of built-in autocomplete by preloading recent open issues from gh issue list | addAutocompleteProvider, on("session_start"), exec |
custom-footer.ts | Replace footer entirely | registerCommand, setFooter |
custom-header.ts | Replace startup header | on("session_start"), setHeader |
modal-editor.ts | Vim-style modal editor | setEditorComponent, CustomEditor |
rainbow-editor.ts | Custom editor styling | setEditorComponent |
widget-placement.ts | Widget above/below editor | setWidget |
overlay-test.ts | Overlay components | ui.custom with overlay options |
overlay-qa-tests.ts | Comprehensive overlay tests | ui.custom, all overlay options |
notify.ts | Simple notifications | ui.notify |
timed-confirm.ts | Dialogs with timeout | ui.confirm with timeout/signal |
mac-system-theme.ts | Auto-switch theme | setTheme, exec |
| Complex Extensions | ||
plan-mode/ | Full plan mode implementation | All event types, registerCommand, registerShortcut, registerFlag, setStatus, setWidget, sendMessage, setActiveTools |
preset.ts | Saveable presets (model, tools, thinking) | registerCommand, registerShortcut, registerFlag, setModel, setActiveTools, setThinkingLevel, appendEntry |
tools.ts | Toggle tools on/off UI | registerCommand, setActiveTools, SettingsList, session events |
| Remote & Sandbox | ||
ssh.ts | SSH remote execution | registerFlag, on("user_bash"), on("before_agent_start"), tool operations |
interactive-shell.ts | Persistent shell session | on("user_bash") |
sandbox/ | Sandboxed tool execution | Tool operations |
subagent/ | Spawn sub-agents | registerTool, exec |
| Games | ||
snake.ts | Snake game | registerCommand, ui.custom, keyboard handling |
space-invaders.ts | Space Invaders game | registerCommand, ui.custom |
doom-overlay/ | Doom in overlay | ui.custom with overlay |
| Providers | ||
custom-provider-anthropic/ | Custom Anthropic proxy | registerProvider |
custom-provider-gitlab-duo/ | GitLab Duo integration | registerProvider with OAuth |
| Messages & Communication | ||
message-renderer.ts | Custom message rendering | registerMessageRenderer, sendMessage |
event-bus.ts | Inter-extension events | pi.events |
| Session Metadata | ||
session-name.ts | Name sessions for selector | setSessionName, getSessionName |
bookmark.ts | Bookmark entries for /tree | setLabel |
| Misc | ||
inline-bash.ts | Inline bash in tool calls | on("tool_call") |
bash-spawn-hook.ts | Adjust bash command, cwd, and env before execution | createBashTool, spawnHook |
with-deps/ | Extension with npm dependencies | Package structure with package.json |