Skip to main content
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 in ~/.atomic/agent/extensions/ (global) or .atomic/extensions/ (project-local) for auto-discovery; legacy .pi paths remain supported. Use atomic -e ./path.ts only for quick tests. Extensions in auto-discovered locations can be hot-reloaded with /reload.
Key capabilities:
  • Custom tools - Register tools the LLM can call via pi.registerTool()
  • Event interception - Block or modify tool calls, inject context, observe/cancel deletion-only compaction, and customize branch summaries
  • 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 /mycommand via pi.registerCommand()
  • Session persistence - Store state that survives restarts via pi.appendEntry()
  • Custom rendering - Control how tool calls/results and messages appear in TUI
Example use cases:
  • 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/)
  • Compaction policies (cancel compaction or provide exact deletion targets)
  • Conversation summaries (see summarize.ts example)
  • 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.ts example)
See examples/extensions/ for working implementations.

Table of Contents

Startup and lazy discovery

Atomic keeps the interactive startup path responsive by registering lightweight command/tool wrappers first and deferring noncritical discovery work until after the session is usable. Built-in MCP, workflow, subagent, web-access, and Intercom extensions expose their public commands/tools immediately, but expensive server connections, workflow module evaluation, result-watcher priming, cleanup scans, and browser/provider loading may run in the background or on first explicit use. Commands such as /workflow list, named workflow runs/inputs, failed or durable workflow resume, /mcp, direct MCP tool calls, mcp({ search }), mcp({ describe }), mcp({ server }), and explicit reload/setup flows still wait for the resources they need before returning results; cold-cache MCP proxy describe first narrows hydration to prefix-matched or explicitly requested servers without starting unrelated servers after a prefix-directed miss, cold-cache unscoped MCP proxy search intentionally hydrates all uncached lazy servers so it can search the full configured tool set, env-selected MCP direct tools warm only their selected servers and refresh live tool registration when ready, paused live-workflow resume/pickers bypass full workflow discovery, autocomplete falls back to current/admin completions when lazy discovery fails, and workflow session restore reads only lightweight config during session_start so persisted-run settings apply without evaluating workflow modules. Web-access and Intercom first-use calls await one shared lazy initializer plus the latest active lifecycle replay before executing. Failed initializer/replay attempts remain retryable. Session-scoped leases retire candidates synchronously on shutdown, reject calls spanning teardown, and require fresh initialization after restart; shutdown awaits retired replay/initializer cleanup before the extension instance can be replaced, and Intercom serializes replay with live lifecycle forwarding so matching ends and newer model selections cannot be overtaken by stale replay. Aborting one web-access caller during a shared wait does not cancel initialization for other callers, and host abort after provider/curator execution preserves the exact abort reason while explicit curator user cancellation remains result-shaped. Non-empty web_search/fetch_content batches with no successful items are marked as tool errors with stage diagnostics; partial successes remain successful and retain their completed items. Bundled MCP startup, proxy calls, direct tools, and readiness-critical commands share a generation-scoped initializer and exact session lease. Failed background attempts remain retryable and single-flight; stale contexts cannot reuse initialized state; commands keep the state they initialized across lazy imports; and direct/proxy operations revalidate ownership after lifecycle-spanning waits and before metadata or SDK side effects. Caller cancellation races readiness, connection, manager-close, and UI-start waits with the exact reason, closes any UI runtime produced after cancellation, and does not cancel shared producers needed by survivors. Session restart/shutdown retires OAuth ownership immediately and uses bounded, observed cleanup so non-abortable SDK work cannot permanently block replacement sessions while late completion remains fenced. SDK-supported resource/tool requests still receive the call signal, though protocol-level remote cancellation is advisory; UI-backed MCP Apps calls preserve terminal cancellation ordering and keep successful result events mutually exclusive. Per-server timeoutMs applies a validated local-or-remote MCP tool-call inactivity limit at every call path while composing with the host abort signal; progress resets that timer, so a continuously reporting tool can run indefinitely, and omitting the field keeps the MCP SDK default.

Interactive callback isolation

Interactive Atomic sessions run the agent engine, extensions, tools, hooks, workflow code, and extension-owned render components in a supervised child process. The terminal host owns stdin and cached rendering, so a synchronous busy loop in one callback cannot stop keyboard handling, spinners, or render scheduling. The engine sends a heartbeat every 50 ms; Atomic identifies the active callback after a 250 ms heartbeat gap and marks the engine unresponsive after one second. Escape requests cooperative cancellation and escalates to terminating the engine when it cannot acknowledge; the interrupted result is reported as unknown and is never retried automatically. Dialogs and ctx.ui.custom() components are proxied to the host as rendered lines with asynchronous input forwarding. Custom UI results must be JSON-safe. APIs that require a synchronous callback in the terminal process—raw onTerminalInput transforms, synchronous getEditorText, custom editor factories, autocomplete wrappers, component-factory widgets, and custom header/footer factories—are unavailable in isolated interactive mode and produce a warning rather than executing extension code in the host. Print and public RPC modes retain their existing execution model. For session-style list pickers use ctx.ui.hostSessionPicker(request) instead of remote-rendering a selector through ctx.ui.custom(): the terminal host mounts the real built-in session selector natively, fed with JSON-safe rows (HostSessionPickerRow: SessionInfo with createdAt/modifiedAt epoch millis). Arrow-key navigation and search never cross the process boundary; only semantic events do — the returned handle exposes result (resolves with the selected row’s path, or undefined on cancel), update(rows), error(message), and close(), and the request’s onDelete(path) callback owns deletion (the host keeps the row until the extension replies with update or error). Every interactive host implements the identical API — in-process (no IPC) when not isolated, over the engine protocol when isolated — so callers never branch; the member is absent only on non-interactive surfaces (headless RPC, print), where commands should fail with an actionable error. See Host-native session picker for an example. For structured forms use ctx.ui.hostInputForm(request). It accepts JSON-safe field descriptors (string, text, number, integer, boolean, or select, each with a raw initialValue) and resolves to a raw string record or undefined on cancellation. The terminal host owns the component, focus, validation, configured-keybinding handling, and mutable text state, so Tab, arrows, editing, Enter, Escape, and Ctrl+C are host-local rather than asynchronously forwarded to the engine child. Both interactive modes expose the same optional API; headless RPC and print omit it. See Host-native input form.

Quick Start

Create ~/.atomic/agent/extensions/my-extension.ts:
Test with --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: Additional paths via settings.json:
To share extensions via npm or git as Atomic packages, see Atomic packages.

Available Imports

Registry dependencies work too. Add a package.json next to your extension (or in a parent directory), then install dependencies with Bun:
Imports from 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 receives ExtensionAPI. The factory can be synchronous or asynchronous:
Extensions are loaded via jiti, so TypeScript works without compilation. If the factory returns a 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.
This pattern makes the fetched models available during normal startup and to atomic --list-models.

Long-lived resources and shutdown

Extension factories may run in invocations that never start a session, such as metadata commands or early configuration checks. Do not start background resources such as processes, sockets, file watchers, or timers from the factory. Defer background resource startup until session_start or the command/tool/event that needs the resource. Register an idempotent session_shutdown handler to close any session-scoped resources you start.

Extension Styles

Single file - simplest, for small extensions:
Directory with index.ts - for multi-file extensions:
Package with dependencies - for extensions that need npm packages:
The manifest key is the configured Atomic app name (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

Startup Events

project_trust

Fired before Atomic decides whether to trust a project with dynamic configs (.atomic, legacy .pi, or .agents/skills). It runs during startup and when session replacement (for example /resume) enters a cwd whose trust has not been resolved in the current process. Only user/global extensions and CLI -e extensions participate; project-local extensions are not loaded until after trust is resolved.
A project_trust handler must return { trusted: "yes" | "no" | "undecided" }. A user/global or CLI extension that returns "yes" or "no" owns the decision; the first yes/no decision wins and suppresses the built-in trust prompt. Use remember: true to persist a yes/no decision; otherwise it applies only to the current process. Return "undecided" to let later handlers or the built-in trust flow decide. Check ctx.hasUI before prompting. If no handler returns yes/no, normal trust resolution continues: saved trust.json decisions apply first, then defaultProjectTrust controls whether Atomic asks, trusts, or declines by default.

Resource Events

resources_discover

Fired after session_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_info_changed

Fired when the current session display name is set via /name, RPC, or pi.setSessionName().

session_before_switch

Fired before starting a new session (/new) or switching sessions (/resume).
After a successful switch or new-session action, Atomic emits 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.
After a successful fork or clone, Atomic emits 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 by /compact and auto-compaction, including a threshold crossing detected after tool results enter the prospective next-turn context. Atomic prepares the complete active transcript except for the exact newest preserve_recent context-visible messages. Extensions may cancel or provide a complete, non-empty compactedText replacement for that region; they cannot move firstKeptEntryId. The override is persisted verbatim and works without provider credentials. A successful post-tool compaction returns its rebuilt context directly to the already-active Pi loop; it does not start a separate continuation. Cancellation or failure prevents that loop’s follow-up provider request.

session_before_tree / session_tree

Fired on /tree navigation. See Sessions for tree navigation concepts.

session_shutdown

Fired before a started session runtime is torn down. Use this to clean up resources opened from session_start or other session-scoped hooks.

Agent Events

before_agent_start

Fired after user submits prompt, before agent loop. Can inject a message and/or modify the system prompt.
The 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 / agent_settled

agent_start begins a low-level run. agent_end fires when that run ends, but Atomic may still retry, compact and retry, or deliver queued follow-ups. Use agent_settled when a status integration needs to know Atomic has no automatic continuation left.

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_start and message_end fire for user, assistant, and toolResult messages.
  • message_update fires for assistant streaming updates.
  • message_end handlers can return { message } to replace the finalized message. The replacement must keep the same role.

tool_execution_start / tool_execution_update / tool_execution_end

Fired for tool execution lifecycle updates. In parallel tool mode:
  • tool_execution_start is emitted in assistant source order during the preflight phase
  • tool_execution_update events may interleave across tools
  • tool_execution_end is emitted in tool completion order after each tool is finalized
  • final toolResult message 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. When tool output crosses the buffered compaction threshold, the post-tool compaction preflight finishes before this hook runs for the follow-up call, so event.messages contains the rebuilt compacted context.

before_provider_headers

Fires after outgoing HTTP headers are assembled. Mutate event.headers to add, override, or remove headers. The event also identifies the provider and model.

before_provider_request

Fired after the provider-specific payload is built, right before the request is sent. Handlers run in extension load order. Returning undefined 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.
This is mainly useful for debugging provider serialization and cache behavior.

after_provider_response

Fired after an HTTP response is received and before its stream body is consumed. Handlers run in extension load order.
Header availability depends on provider and transport. Providers that abstract HTTP responses may not expose headers.

Model Events

model_select

Fired when the model changes via /model command, model cycling (CTRL+P), or session restore.
Use this to update UI elements (status bars, footers) or perform model-specific initialization when the active model changes.

thinking_level_select

Fired when the thinking level changes. This is notification-only; handler return values are ignored.
Use this to update extension UI when pi.setThinkingLevel(), model changes, or built-in thinking-level controls change the active thinking level.

Tool Events

tool_call

Fired after tool_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.input affect the actual tool execution
  • Later tool_call handlers see mutations made by earlier handlers
  • No re-validation is performed after your mutation
  • Return values from tool_call only control blocking via { block: true, reason?: string }

Typing custom tool input

Custom tools should export their input type:
Use isToolCallEventType with explicit type parameters:

tool_result

Fired after tool execution finishes and before tool_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, or isError); omitted fields keep their current values
Use 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:
  1. Extension commands (/cmd) checked first - if found, handler runs and input event is skipped
  2. input event fires - can intercept, transform, or handle
  3. If not handled: skill commands (/skill:name) expanded to skill content
  4. If not handled: prompt templates (/template) expanded to template content
  5. Agent processing begins (before_agent_start, etc.)
Results:
  • continue - pass through unchanged (default if handler returns nothing)
  • transform - modify text/images, then continue to expansion
  • handled - skip agent entirely (first handler to return this wins)
Transforms chain across handlers. See input-transform.ts and input-transform-streaming.ts for streamingBehavior-aware routing.

ExtensionContext

All handlers receive ctx: 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. Use CONFIG_DIR_NAME instead of hardcoding .atomic (or legacy .pi) when constructing project-local config paths. Rebranded distributions can use a different config directory name.

ctx.isProjectTrusted()

Returns whether project-local trust is active for the current session context. This includes temporary trust decisions and CLI trust overrides, not just saved decisions in the global trust store. Use this before reading project-local extension configuration that should only be honored for trusted projects.

ctx.sessionManager

Read-only access to session state. See Session Format for the full SessionManager API and entry types. For tool_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, or undefined 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.isProjectTrusted()

Returns whether project-local trust is active for the current extension context. Use this before reading project-local config, loading project-local resources, or exposing actions that should only run after the user has trusted the cwd.

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.
Emits 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 Atomic’s verbatim line compactor without awaiting completion. The planner emits numbered deleted-line ranges only; Atomic validates them and reconstructs retained text mechanically. Use compression_ratio (fraction of compactable lines to keep), client-side preserve_recent (an exact context-visible message count), and query to tune the run, and onComplete/onError for follow-up actions.
The planner cannot author context text: only validated line ranges enter the mechanical reconstruction path. The query parameter guides relevance selection inside the fixed prompt; it is not replacement prose. Extensions that need an offline replacement can return compactedText from session_before_compact.

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 context message mutations.
  • It does not include before_provider_request payload rewrites.
  • If later-loaded extensions run after yours, they can still change what is ultimately sent.

ExtensionCommandContext

Command handlers receive ExtensionCommandContext, 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:
Options:
  • parentSession: parent session file to record in the new session header
  • setup: mutate the new session’s SessionManager before withSession runs
  • withSession: run post-switch work against a fresh replacement-session context. Do not use captured old pi / command ctx; see Session replacement lifecycle and footguns.

ctx.fork(entryId, options?)

Fork from a specific entry, creating a new session file:
Options:
  • position: "before" (default) forks before the selected user message, restoring that prompt into the editor
  • position: "at" duplicates the active path through the selected entry without restoring editor text
  • withSession: run post-switch work against a fresh replacement-session context. Do not use captured old pi / command ctx; see Session replacement lifecycle and footguns.

ctx.navigateTree(targetId, options?)

Navigate to a different point in the session tree:
Options:
  • summarize: Whether to generate a summary of the abandoned branch
  • customInstructions: Custom instructions for the summarizer
  • replaceInstructions: If true, customInstructions replaces the default prompt instead of being appended
  • label: Label to attach to the branch summary entry (or target entry if not summarizing)

ctx.switchSession(sessionPath, options?)

Switch to a different session file:
Options: To discover available sessions, use the static 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:
  • withSession runs only after the old session has emitted session_shutdown, the old runtime has been torn down, the replacement session has been rebound, and the new extension instance has already received session_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 withSession starts.
  • Captured old pi / old command ctx session-bound objects are stale after replacement and will throw if used. Use only the ctx passed to withSession for session-bound work.
  • Previously extracted raw objects are still your responsibility. For example, if you capture const sm = ctx.sessionManager before replacement, sm is still the old SessionManager object. Do not reuse it after replacement.
  • Code in withSession should assume any state invalidated by your session_shutdown handler is already gone. Only capture plain data that survives shutdown cleanly, such as strings, ids, and serialized config.
Safe pattern:
Unsafe pattern:

ctx.reload()

Run the same reload flow as /reload.
Important behavior:
  • await ctx.reload() emits session_shutdown for the current extension runtime
  • It then reloads resources and emits session_start with reason: "reload" and resources_discover with 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
For predictable behavior, treat reload as terminal for that handler (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. Use Atomic’s export rather than importing StringEnum directly from Pi. It preserves Pi’s Google-compatible runtime schema while keeping the schema typed against Atomic’s direct TypeBox version.

pi.sendMessage(message, options?)

Inject a custom message into the session. The call returns void | Promise<void> for compatibility with synchronous hosts; use await Promise.resolve(pi.sendMessage(...)) when admission or routing failure must be observed. Atomic’s AgentSession runtime returns an admission receipt: it settles after the message is accepted by the local queue or workflow late-message route, without waiting for the resulting model turn to finish.
Options:
  • 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" - With triggerTurn: 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 no deliverAs, this remains display-only even while the agent is streaming.
  • interruptAbortMessage - Optional text used to replace generic abort results (for example Operation aborted) when deliverAs: "interrupt" aborts an active turn.

pi.sendMessages(messages, options?)

Atomically admit a batch of custom messages in array order. The call returns void | Promise<void> for compatibility with synchronous hosts; use await Promise.resolve(pi.sendMessages(...)) when admission or routing failure must be observed. The promise is an admission receipt and does not wait for the resulting model turn. Admission is indivisible; use this when a prelude and terminal notice must stay contiguous without globally serializing other extension work.
The batch supports triggerTurn, excludeFromContext, and deliverAs: "steer" | "followUp" | "nextTurn". Interrupt delivery remains a single-message operation.

pi.sendUserMessage(content, options?)

Send a user message to the agent. Unlike sendMessage() which sends custom messages, this sends an actual user message that appears as if typed by the user. Always triggers a turn.
Options:
  • 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
When not streaming, the message is sent immediately and triggers a new turn. When streaming without 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).
Appending emits entry_appended with the durable entry. This lets extensions react to session entries without polling.

pi.registerEntryRenderer(customType, renderer)

Register a TUI renderer for durable custom entries created by pi.appendEntry(). These entries render in the transcript but do not enter model 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).
Labels persist in the session and survive restarts. Use them to mark important points (turns, checkpoints) in the conversation tree.

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.
Optional: add argument auto-completion for /command ...:

pi.getCommands()

Get the slash commands available for invocation via prompt 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.
Each entry has this shape:
Use 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 your customType. 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.getActiveTools() returns the active tool names as string[]; pi.getAllTools() returns metadata for all configured tools.
pi.getAllTools() returns name, description, parameters, promptGuidelines, and sourceInfo. Typical sourceInfo.source values:
  • builtin for built-in tools
  • sdk for tools passed via createAgentSession({ customTools })
  • extension source metadata for tools registered by extensions

pi.setModel(model)

Set the current model. Returns false 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"; "xhigh" and "max" require model support). Changes emit thinking_level_select.

pi.events

Shared event bus for communication between extensions:

Native providers

In addition to registerProvider(name, config), extensions can register a complete native Provider from @earendil-works/pi-ai with pi.registerProvider(provider). Use the native overload for provider-owned authentication, catalog refresh, and transport behavior; use the config overload for ordinary proxies and custom endpoints.

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.
Config options:
  • name - Display name for the provider in UI such as /login.
  • baseUrl - API endpoint URL. Required when defining models.
  • apiKey - API key literal or explicit environment variable reference ($ENV_VAR or ${ENV_VAR}). Required when defining models (unless oauth provided).
  • api - API type: "anthropic-messages", "openai-completions", "openai-responses", etc.
  • headers - Custom headers to include in requests.
  • authHeader - If true, adds Authorization: Bearer header automatically.
  • models - Array of model definitions. If provided, replaces all existing models for this provider. Model definitions can set baseUrl to override the provider endpoint for that model.
  • oauth - OAuth provider config for /login support. When provided, the provider appears in the login menu.
  • auth.apiKey - Provider-owned API-key or connection setup for /login. Its name appears in the provider list and login({ signal, prompt }) returns the credential Atomic persists. Extension providers registered only in the isolated interactive engine child are synchronized into the host’s /login list; their login callback and credential-dependent model refresh still execute in the child, while prompts are rendered by the terminal host.
  • streamSimple - Custom streaming implementation for non-standard APIs.
See Custom providers for advanced topics: custom streaming APIs, OAuth details, model definition reference.

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. Like registerProvider, 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 result details for proper branching support:

Custom Tools

Register tools the LLM can call via pi.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

Signaling errors: To mark a tool execution as failed (sets 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. Atomic does not register structured_output in normal agent sessions by default; use createStructuredOutputTool({ schema, capture, output, name }) when an extension, SDK session, workflow stage, or subagent runtime needs a schema-backed final-answer tool. The factory uses the supplied schema as the tool parameters directly, captures the tool arguments as whatever JSON value matches the schema, emits the same pretty-printed JSON as the terminating tool-result text for atomic -p, optionally writes them to the configured output.outputPath, and terminates the turn. In text print mode, a terminating result from a factory-created structured-output tool is emitted to stdout as the final response. Custom factory names are opt-in tools: if you register final_decision, include final_decision in any explicit tools allowlist; if you register the default structured_output name, it is available only to that session/runtime.
Important: Use StringEnum from @bastani/atomic for string enums. It retains Pi’s Google-compatible schema and composes with Atomic’s direct TypeBox types; 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 only when a custom tool must normalize arguments before validation. Return the object you want validated against parameters, keep the public schema strict, and avoid advertising deprecated fields.

Overriding Built-in Tools

Extensions can override built-in tools (read, bash, edit, write, find, search, ask_user_question, todo) by registering a tool with the same name. Interactive mode displays a warning when this happens.
Alternatively, use --no-builtin-tools to start without any built-in tools while keeping extension tools enabled:
See examples/extensions/tool-override.ts for a complete example that overrides 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:

Remote Execution

Built-in tools support pluggable operations for delegating to remote systems (SSH, containers, etc.):
Operations interfaces: 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:
See examples/extensions/ssh.ts for a complete SSH example with --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
The built-in limit is 50KB (~10k tokens) and 2000 lines, whichever is hit first. Use the exported truncation utilities:
Key points:
  • Use truncateHead for content where the beginning matters (search results, file reads)
  • Use truncateTail for 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
See examples/extensions/truncated-tool.ts for a complete example wrapping rg (ripgrep) with proper truncation.

Multiple Tools

One extension can register multiple tools with shared state:

Custom Rendering

Tools can provide renderCall 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 arguments
  • state - shared row-local state across renderCall and renderResult
  • lastComponent - the previously returned component for that slot, if any
  • invalidate() - request a rerender of this tool row
  • toolCallId, cwd, executionStarted, argsComplete, isPartial, expanded, showImages, isError
Use 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:
If a slot intentionally has no visible content, return an empty Component such as an empty Container.

Keybinding Hints

Use keyHintIfBound() when an affordance should disappear if the action has no effective keybinding. Add surrounding punctuation only when the helper returns text:
Available functions:
  • keyHint(keybinding, description) - Formats a configured keybinding id such as "app.tools.expand" or "tui.select.confirm"; use it when the binding is required by the surrounding UI
  • keyHintIfBound(keybinding, description) - Formats the hint only when the action has an effective key list; use it for optional affordances and conditionally compose parentheses or separators
  • keyText(keybinding) - Returns the raw configured key text for a keybinding id
  • rawKeyHint(key, description) - Format a raw key string
Use namespaced keybinding ids:
  • Coding-agent ids use the app.* namespace, for example app.tools.expand, app.editor.external, app.session.rename
  • Shared TUI ids use the tui.* namespace, for example tui.select.confirm, tui.select.cancel, tui.input.tab
For the exhaustive list of keybinding ids and defaults, see Keybindings. 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 Text with padding (0, 0). The default Box handles padding.
  • Use \n for multi-line content.
  • Handle isPartial for streaming progress.
  • Support expanded for detail on demand.
  • Keep default view compact.
  • Read context.args in renderResult instead of copying args into context.state.
  • Use context.state only for data that must be shared across call and result slots.
  • Reuse context.lastComponent when 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 name
  • renderResult: Shows raw text from content

Custom UI

Extensions can interact with users via ctx.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 a timeout option that auto-dismisses with a live countdown display:
Return values on timeout:
  • select() returns undefined
  • confirm() returns false
  • input() returns undefined

Manual Dismissal with AbortSignal

For more control (e.g., to distinguish timeout from user cancel), use AbortSignal:
See examples/extensions/timed-confirm.ts for complete examples.
Custom working-indicator frames are rendered verbatim. If you want colors, add them to the frame strings yourself, for example with ctx.ui.theme.fg(...).

Autocomplete Providers

Use ctx.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
See github-issue-autocomplete.ts for a complete example that preloads the latest open GitHub issues with 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, use ctx.ui.custom(). This temporarily replaces the editor with your component until done() is called:
The callback receives:
  • tui - TUI instance (for screen dimensions, focus management)
  • theme - Current theme for styling
  • keybindings - App keybinding manager (for checking shortcuts)
  • done(value) - Call to close component and return value
Pass { 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:
For advanced positioning (anchors, margins, percentages, responsive visibility), pass overlayOptions. Use onHandle to control visibility programmatically:
See TUI components for the full 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.):
Key points:
  • Extend CustomEditor (not base Editor) to get app keybindings (escape to abort, ctrl+d, model switching)
  • Call super.handleInput(data) for keys you don’t handle
  • Factory receives tui, theme, and keybindings from the app
  • Use ctx.ui.getEditorComponent() before setEditorComponent() to wrap the previously configured custom editor
  • Pass undefined to restore default: ctx.ui.setEditorComponent(undefined)
To compose with another extension that already replaced the editor, capture the previous factory before setting yours:
See TUI components Pattern 7 for a complete example with mode indicator.

Message Rendering

Register a custom renderer for messages with your customType:
Messages are sent via pi.sendMessage():

Theme Colors

All render functions receive a theme object. See Themes for creating custom themes and the full color palette.
For syntax highlighting in custom tool renderers:

Error Handling

  • Extension errors are logged, agent continues
  • tool_call errors block the tool (fail-safe)
  • Tool execute errors must be signaled by throwing; the thrown error is caught, reported to the LLM with isError: true, and execution continues

Mode Behavior

In non-interactive modes, check ctx.hasUI before using UI methods.

Examples Reference

All examples in examples/extensions/.