packages/coding-agent/docs/extensions.md
pi can create extensions. Ask it to build one for your use case.
Extensions are TypeScript modules that extend pi'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
~/.pi/agent/extensions/(global) or.pi/extensions/(project-local) for auto-discovery. Usepi -e ./path.tsonly for quick tests. Extensions in auto-discovered locations can be hot-reloaded with/reload.
Key capabilities:
pi.registerTool()ctx.ui (select, confirm, input, notify)ctx.ui.custom() for complex interactions/mycommand via pi.registerCommand()pi.appendEntry()Example use cases:
rm -rf, sudo, etc.).env, node_modules/)summarize.ts example)snake.ts example)See examples/extensions/ for working implementations.
Create ~/.pi/agent/extensions/my-extension.ts:
import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
import { Type } from "typebox";
export default function (pi: ExtensionAPI) {
// React to events
pi.on("session_start", async (_event, ctx) => {
ctx.ui.notify("Extension loaded!", "info");
});
pi.on("tool_call", async (event, ctx) => {
if (event.toolName === "bash" && event.input.command?.includes("rm -rf")) {
const ok = await ctx.ui.confirm("Dangerous!", "Allow rm -rf?");
if (!ok) return { block: true, reason: "Blocked by user" };
}
});
// Register a custom tool
pi.registerTool({
name: "greet",
label: "Greet",
description: "Greet someone by name",
parameters: Type.Object({
name: Type.String({ description: "Name to greet" }),
}),
async execute(toolCallId, params, signal, onUpdate, ctx) {
return {
content: [{ type: "text", text: `Hello, ${params.name}!` }],
details: {},
};
},
});
// Register a command
pi.registerCommand("hello", {
description: "Say hello",
handler: async (args, ctx) => {
ctx.ui.notify(`Hello ${args || "world"}!`, "info");
},
});
}
Test with --extension (or -e) flag:
pi -e ./my-extension.ts
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 |
|---|---|
~/.pi/agent/extensions/*.ts | Global (all projects) |
~/.pi/agent/extensions/*/index.ts | Global (subdirectory) |
.pi/extensions/*.ts | Project-local |
.pi/extensions/*/index.ts | Project-local (subdirectory) |
Additional paths via settings.json:
{
"packages": [
"npm:@foo/[email protected]",
"git:github.com/user/repo@v1"
],
"extensions": [
"/path/to/local/extension.ts",
"/path/to/local/extension/dir"
]
}
To share extensions via npm or git as pi packages, see packages.md.
| Package | Purpose |
|---|---|
@mariozechner/pi-coding-agent | Extension types (ExtensionAPI, ExtensionContext, events) |
typebox | Schema definitions for tool parameters |
@mariozechner/pi-ai | AI utilities (StringEnum for Google-compatible enums) |
@mariozechner/pi-tui | TUI components for custom rendering |
npm dependencies work too. Add a package.json next to your extension (or in a parent directory), run npm install, and imports from node_modules/ are resolved automatically.
For distributed pi packages installed with pi install (npm or git), runtime deps must be in dependencies. Package installation uses production installs (npm install --omit=dev) 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.
An extension exports a default factory function that receives ExtensionAPI. The factory can be synchronous or asynchronous:
import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
export default function (pi: ExtensionAPI) {
// Subscribe to events
pi.on("event_name", async (event, ctx) => {
// ctx.ui for user interaction
const ok = await ctx.ui.confirm("Title", "Are you sure?");
ctx.ui.notify("Done!", "success");
ctx.ui.setStatus("my-ext", "Processing..."); // Footer status
ctx.ui.setWidget("my-ext", ["Line 1", "Line 2"]); // Widget above editor (default)
});
// Register tools, commands, shortcuts, flags
pi.registerTool({ ... });
pi.registerCommand("name", { ... });
pi.registerShortcut("ctrl+x", { ... });
pi.registerFlag("my-flag", { ... });
}
Extensions are loaded via jiti, so TypeScript works without compilation.
If the factory returns a Promise, pi 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.
Use an async factory for one-time startup work such as fetching remote configuration or dynamically discovering available models.
import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
export default async function (pi: ExtensionAPI) {
const response = await fetch("http://localhost:1234/v1/models");
const payload = (await response.json()) as {
data: Array<{
id: string;
name?: string;
context_window?: number;
max_tokens?: number;
}>;
};
pi.registerProvider("local-openai", {
baseUrl: "http://localhost:1234/v1",
apiKey: "LOCAL_OPENAI_API_KEY",
api: "openai-completions",
models: payload.data.map((model) => ({
id: model.id,
name: model.name ?? model.id,
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: model.context_window ?? 128000,
maxTokens: model.max_tokens ?? 4096,
})),
});
}
This pattern makes the fetched models available during normal startup and to pi --list-models.
Single file - simplest, for small extensions:
~/.pi/agent/extensions/
└── my-extension.ts
Directory with index.ts - for multi-file extensions:
~/.pi/agent/extensions/
└── my-extension/
├── index.ts # Entry point (exports default function)
├── tools.ts # Helper module
└── utils.ts # Helper module
Package with dependencies - for extensions that need npm packages:
~/.pi/agent/extensions/
└── my-extension/
├── package.json # Declares dependencies and entry points
├── package-lock.json
├── node_modules/ # After npm install
└── src/
└── index.ts
// package.json
{
"name": "my-extension",
"dependencies": {
"zod": "^3.0.0",
"chalk": "^5.0.0"
},
"pi": {
"extensions": ["./src/index.ts"]
}
}
Run npm install in the extension directory, then imports from node_modules/ work automatically.
pi starts
│
├─► session_start { reason: "startup" }
└─► resources_discover { reason: "startup" }
│
▼
user sends prompt ─────────────────────────────────────────┐
│ │
├─► (extension commands checked first, bypass if found) │
├─► input (can intercept, transform, or handle) │
├─► (skill/template expansion if not handled) │
├─► before_agent_start (can inject message, modify system prompt)
├─► agent_start │
├─► message_start / message_update / message_end │
│ │
│ ┌─── turn (repeats while LLM calls tools) ───┐ │
│ │ │ │
│ ├─► turn_start │ │
│ ├─► context (can modify messages) │ │
│ ├─► before_provider_request (can inspect or replace payload)
│ ├─► after_provider_response (status + headers, before stream consume)
│ │ │ │
│ │ LLM responds, may call tools: │ │
│ │ ├─► tool_execution_start │ │
│ │ ├─► tool_call (can block) │ │
│ │ ├─► tool_execution_update │ │
│ │ ├─► tool_result (can modify) │ │
│ │ └─► tool_execution_end │ │
│ │ │ │
│ └─► turn_end │ │
│ │
└─► agent_end │
│
user sends another prompt ◄────────────────────────────────┘
/new (new session) or /resume (switch session)
├─► session_before_switch (can cancel)
├─► session_shutdown
├─► session_start { reason: "new" | "resume", previousSessionFile? }
└─► resources_discover { reason: "startup" }
/fork or /clone
├─► session_before_fork (can cancel)
├─► session_shutdown
├─► session_start { reason: "fork", previousSessionFile }
└─► resources_discover { reason: "startup" }
/compact or auto-compaction
├─► session_before_compact (can cancel or customize)
└─► session_compact
/tree navigation
├─► session_before_tree (can cancel or customize)
└─► session_tree
/model or Ctrl+P (model selection/cycling)
├─► thinking_level_select (if model change changes/clamps thinking level)
└─► model_select
thinking level changes (settings, keybinding, pi.setThinkingLevel())
└─► thinking_level_select
exit (Ctrl+C, Ctrl+D, SIGHUP, SIGTERM)
└─► session_shutdown
Fired after session_start so extensions can contribute additional skill, prompt, and theme paths.
The startup path uses reason: "startup". Reload uses reason: "reload".
pi.on("resources_discover", async (event, _ctx) => {
// event.cwd - current working directory
// event.reason - "startup" | "reload"
return {
skillPaths: ["/path/to/skills"],
promptPaths: ["/path/to/prompts"],
themePaths: ["/path/to/themes"],
};
});
See Session Format for session storage internals and the SessionManager API.
Fired when a session is started, loaded, or reloaded.
pi.on("session_start", async (event, ctx) => {
// event.reason - "startup" | "reload" | "new" | "resume" | "fork"
// event.previousSessionFile - present for "new", "resume", and "fork"
ctx.ui.notify(`Session: ${ctx.sessionManager.getSessionFile() ?? "ephemeral"}`, "info");
});
Fired before starting a new session (/new) or switching sessions (/resume).
pi.on("session_before_switch", async (event, ctx) => {
// event.reason - "new" or "resume"
// event.targetSessionFile - session we're switching to (only for "resume")
if (event.reason === "new") {
const ok = await ctx.ui.confirm("Clear?", "Delete all messages?");
if (!ok) return { cancel: true };
}
});
After a successful switch or new-session action, pi 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.
Fired when forking via /fork or cloning via /clone.
pi.on("session_before_fork", async (event, ctx) => {
// event.entryId - ID of the selected entry
// event.position - "before" for /fork, "at" for /clone
return { cancel: true }; // Cancel fork/clone
// OR
return { skipConversationRestore: true }; // Reserved for future conversation restore control
});
After a successful fork or clone, pi 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.
Fired on compaction. See compaction.md for details.
pi.on("session_before_compact", async (event, ctx) => {
const { preparation, branchEntries, customInstructions, signal } = event;
// Cancel:
return { cancel: true };
// Custom summary:
return {
compaction: {
summary: "...",
firstKeptEntryId: preparation.firstKeptEntryId,
tokensBefore: preparation.tokensBefore,
}
};
});
pi.on("session_compact", async (event, ctx) => {
// event.compactionEntry - the saved compaction
// event.fromExtension - whether extension provided it
});
Fired on /tree navigation. See Sessions for tree navigation concepts.
pi.on("session_before_tree", async (event, ctx) => {
const { preparation, signal } = event;
return { cancel: true };
// OR provide custom summary:
return { summary: { summary: "...", details: {} } };
});
pi.on("session_tree", async (event, ctx) => {
// event.newLeafId, oldLeafId, summaryEntry, fromExtension
});
Fired before an extension runtime is torn down.
pi.on("session_shutdown", async (event, ctx) => {
// event.reason - "quit" | "reload" | "new" | "resume" | "fork"
// event.targetSessionFile - destination session for session replacement flows
// Cleanup, save state, etc.
});
Fired after user submits prompt, before agent loop. Can inject a message and/or modify the system prompt.
pi.on("before_agent_start", async (event, ctx) => {
// event.prompt - user's prompt text
// event.images - attached images (if any)
// event.systemPrompt - current chained system prompt for this handler
// (includes changes from earlier before_agent_start handlers)
// event.systemPromptOptions - structured options used to build the system prompt
// .customPrompt - any custom system prompt (from --system-prompt, SYSTEM.md, or custom templates)
// .selectedTools - tools currently active in the prompt
// .toolSnippets - one-line descriptions for each tool
// .promptGuidelines - custom guideline bullets
// .appendSystemPrompt - text from --append-system-prompt flags
// .cwd - working directory
// .contextFiles - AGENTS.md files and other loaded context files
// .skills - loaded skills
return {
// Inject a persistent message (stored in session, sent to LLM)
message: {
customType: "my-extension",
content: "Additional context for the LLM",
display: true,
},
// Replace the system prompt for this turn (chained across extensions)
systemPrompt: event.systemPrompt + "\n\nExtra instructions for this turn...",
};
});
The systemPromptOptions field gives extensions access to the same structured data Pi uses to build the system prompt. This lets you inspect what Pi 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.
Fired once per user prompt.
pi.on("agent_start", async (_event, ctx) => {});
pi.on("agent_end", async (event, ctx) => {
// event.messages - messages from this prompt
});
Fired for each turn (one LLM response + tool calls).
pi.on("turn_start", async (event, ctx) => {
// event.turnIndex, event.timestamp
});
pi.on("turn_end", async (event, ctx) => {
// event.turnIndex, event.message, event.toolResults
});
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.pi.on("message_start", async (event, ctx) => {
// event.message
});
pi.on("message_update", async (event, ctx) => {
// event.message
// event.assistantMessageEvent (token-by-token stream event)
});
pi.on("message_end", async (event, ctx) => {
if (event.message.role !== "assistant") return;
return {
message: {
...event.message,
usage: {
...event.message.usage,
cost: {
...event.message.usage.cost,
total: 0.123,
},
},
},
};
});
Fired for tool execution lifecycle updates.
In parallel tool mode:
tool_execution_start is emitted in assistant source order during the preflight phasetool_execution_update events may interleave across toolstool_execution_end is emitted in tool completion order after each tool is finalizedtoolResult message events are still emitted later in assistant source orderpi.on("tool_execution_start", async (event, ctx) => {
// event.toolCallId, event.toolName, event.args
});
pi.on("tool_execution_update", async (event, ctx) => {
// event.toolCallId, event.toolName, event.args, event.partialResult
});
pi.on("tool_execution_end", async (event, ctx) => {
// event.toolCallId, event.toolName, event.result, event.isError
});
Fired before each LLM call. Modify messages non-destructively. See Session Format for message types.
pi.on("context", async (event, ctx) => {
// event.messages - deep copy, safe to modify
const filtered = event.messages.filter(m => !shouldPrune(m));
return { messages: filtered };
});
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 Pi's system prompt string rather than the final serialized provider payload.
pi.on("before_provider_request", (event, ctx) => {
console.log(JSON.stringify(event.payload, null, 2));
// Optional: replace payload
// return { ...event.payload, temperature: 0 };
});
This is mainly useful for debugging provider serialization and cache behavior.
Fired after an HTTP response is received and before its stream body is consumed. Handlers run in extension load order.
pi.on("after_provider_response", (event, ctx) => {
// event.status - HTTP status code
// event.headers - normalized response headers
if (event.status === 429) {
console.log("rate limited", event.headers["retry-after"]);
}
});
Header availability depends on provider and transport. Providers that abstract HTTP responses may not expose headers.
Fired when the model changes via /model command, model cycling (Ctrl+P), or session restore.
pi.on("model_select", async (event, ctx) => {
// event.model - newly selected model
// event.previousModel - previous model (undefined if first selection)
// event.source - "set" | "cycle" | "restore"
const prev = event.previousModel
? `${event.previousModel.provider}/${event.previousModel.id}`
: "none";
const next = `${event.model.provider}/${event.model.id}`;
ctx.ui.notify(`Model changed (${event.source}): ${prev} -> ${next}`, "info");
});
Use this to update UI elements (status bars, footers) or perform model-specific initialization when the active model changes.
Fired when the thinking level changes. This is notification-only; handler return values are ignored.
pi.on("thinking_level_select", async (event, ctx) => {
// event.level - newly selected thinking level
// event.previousLevel - previous thinking level
ctx.ui.setStatus("thinking", `thinking: ${event.level}`);
});
Use this to update extension UI when pi.setThinkingLevel(), model changes, or built-in thinking-level controls change the active thinking level.
Fired after tool_execution_start, before the tool executes. Can block. Use isToolCallEventType to narrow and get typed inputs.
Before tool_call runs, pi 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:
event.input affect the actual tool executiontool_call handlers see mutations made by earlier handlerstool_call only control blocking via { block: true, reason?: string }import { isToolCallEventType } from "@mariozechner/pi-coding-agent";
pi.on("tool_call", async (event, ctx) => {
// event.toolName - "bash", "read", "write", "edit", etc.
// event.toolCallId
// event.input - tool parameters (mutable)
// Built-in tools: no type params needed
if (isToolCallEventType("bash", event)) {
// event.input is { command: string; timeout?: number }
event.input.command = `source ~/.profile\n${event.input.command}`;
if (event.input.command.includes("rm -rf")) {
return { block: true, reason: "Dangerous command" };
}
}
if (isToolCallEventType("read", event)) {
// event.input is { path: string; offset?: number; limit?: number }
console.log(`Reading: ${event.input.path}`);
}
});
Custom tools should export their input type:
// my-extension.ts
export type MyToolInput = Static<typeof myToolSchema>;
Use isToolCallEventType with explicit type parameters:
import { isToolCallEventType } from "@mariozechner/pi-coding-agent";
import type { MyToolInput } from "my-extension";
pi.on("tool_call", (event) => {
if (isToolCallEventType<"my_tool", MyToolInput>("my_tool", event)) {
event.input.action; // typed
}
});
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:
content, details, or isError); omitted fields keep their current valuesUse ctx.signal for nested async work inside the handler. This lets Esc cancel model calls, fetch(), and other abort-aware operations started by the extension.
import { isBashToolResult } from "@mariozechner/pi-coding-agent";
pi.on("tool_result", async (event, ctx) => {
// event.toolName, event.toolCallId, event.input
// event.content, event.details, event.isError
if (isBashToolResult(event)) {
// event.details is typed as BashToolDetails
}
const response = await fetch("https://example.com/summarize", {
method: "POST",
body: JSON.stringify({ content: event.content }),
signal: ctx.signal,
});
// Modify result:
return { content: [...], details: {...}, isError: false };
});
Fired when user executes ! or !! commands. Can intercept.
import { createLocalBashOperations } from "@mariozechner/pi-coding-agent";
pi.on("user_bash", (event, ctx) => {
// event.command - the bash command
// event.excludeFromContext - true if !! prefix
// event.cwd - working directory
// Option 1: Provide custom operations (e.g., SSH)
return { operations: remoteBashOps };
// Option 2: Wrap pi's built-in local bash backend
const local = createLocalBashOperations();
return {
operations: {
exec(command, cwd, options) {
return local.exec(`source ~/.profile\n${command}`, cwd, options);
}
}
};
// Option 3: Full replacement - return result directly
return { result: { output: "...", exitCode: 0, cancelled: false, truncated: false } };
});
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:
/cmd) checked first - if found, handler runs and input event is skippedinput event fires - can intercept, transform, or handle/skill:name) expanded to skill content/template) expanded to template contentbefore_agent_start, etc.)pi.on("input", async (event, ctx) => {
// event.text - raw input (before skill/template expansion)
// event.images - attached images, if any
// event.source - "interactive" (typed), "rpc" (API), or "extension" (via sendUserMessage)
// Transform: rewrite input before expansion
if (event.text.startsWith("?quick "))
return { action: "transform", text: `Respond briefly: ${event.text.slice(7)}` };
// Handle: respond without LLM (extension shows its own feedback)
if (event.text === "ping") {
ctx.ui.notify("pong", "info");
return { action: "handled" };
}
// Route by source: skip processing for extension-injected messages
if (event.source === "extension") return { action: "continue" };
// Intercept skill commands before expansion
if (event.text.startsWith("/skill:")) {
// Could transform, block, or let pass through
}
return { action: "continue" }; // Default: pass through to expansion
});
Results:
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)Transforms chain across handlers. See input-transform.ts.
All handlers receive ctx: ExtensionContext.
UI methods for user interaction. See Custom UI for full details.
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.md).
Current working directory.
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.sessionManager.getEntries() // All entries
ctx.sessionManager.getBranch() // Current branch
ctx.sessionManager.getLeafId() // Current leaf entry ID
Access to models and API keys.
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 })signalAbortSignalctx.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 pi is idle.
pi.on("tool_result", async (event, ctx) => {
const response = await fetch("https://example.com/api", {
method: "POST",
body: JSON.stringify(event),
signal: ctx.signal,
});
const data = await response.json();
return { details: data };
});
Control flow helpers.
Request a graceful shutdown of pi.
Emits session_shutdown event to all extensions before exiting. Available in all contexts (event handlers, tools, commands, shortcuts).
pi.on("tool_call", (event, ctx) => {
if (isFatal(event.input)) {
ctx.shutdown();
}
});
Returns current context usage for the active model. Uses last assistant usage when available, then estimates tokens for trailing messages.
const usage = ctx.getContextUsage();
if (usage && usage.tokens > 100_000) {
// ...
}
Trigger compaction without awaiting completion. Use onComplete and onError for follow-up actions.
ctx.compact({
customInstructions: "Focus on recent changes",
onComplete: (result) => {
ctx.ui.notify("Compaction completed", "info");
},
onError: (error) => {
ctx.ui.notify(`Compaction failed: ${error.message}`, "error");
},
});
Returns Pi's current system prompt string.
before_agent_start, this reflects chained system-prompt changes made so far for the current turn.context message mutations.before_provider_request payload rewrites.pi.on("before_agent_start", (event, ctx) => {
const prompt = ctx.getSystemPrompt();
console.log(`System prompt length: ${prompt.length}`);
});
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.
Wait for the agent to finish streaming:
pi.registerCommand("my-cmd", {
handler: async (args, ctx) => {
await ctx.waitForIdle();
// Agent is now idle, safe to modify session
},
});
Create a new session:
const parentSession = ctx.sessionManager.getSessionFile();
const kickoff = "Continue in the replacement session";
const result = await ctx.newSession({
parentSession,
setup: async (sm) => {
sm.appendMessage({
role: "user",
content: [{ type: "text", text: "Context from previous session..." }],
timestamp: Date.now(),
});
},
withSession: async (ctx) => {
// Use only the replacement-session ctx here.
await ctx.sendUserMessage(kickoff);
},
});
if (result.cancelled) {
// An extension cancelled the new session
}
Options:
parentSession: parent session file to record in the new session headersetup: mutate the new session's SessionManager before withSession runswithSession: run post-switch work against a fresh replacement-session context. Do not use captured old pi / command ctx; see Session replacement lifecycle and footguns.Fork from a specific entry, creating a new session file:
const result = await ctx.fork("entry-id-123", {
withSession: async (ctx) => {
// Use only the replacement-session ctx here.
ctx.ui.notify("Now in the forked session", "info");
},
});
if (result.cancelled) {
// An extension cancelled the fork
}
const cloneResult = await ctx.fork("entry-id-456", { position: "at" });
if (cloneResult.cancelled) {
// An extension cancelled the clone
}
Options:
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 old pi / command ctx; see Session replacement lifecycle and footguns.Navigate to a different point in the session tree:
const result = await ctx.navigateTree("entry-id-456", {
summarize: true,
customInstructions: "Focus on error handling changes",
replaceInstructions: false, // true = replace default prompt entirely
label: "review-checkpoint",
});
Options:
summarize: Whether to generate a summary of the abandoned branchcustomInstructions: Custom instructions for the summarizerreplaceInstructions: If true, customInstructions replaces the default prompt instead of being appendedlabel: Label to attach to the branch summary entry (or target entry if not summarizing)Switch to a different session file:
const result = await ctx.switchSession("/path/to/session.jsonl", {
withSession: async (ctx) => {
await ctx.sendUserMessage("Resume work in the replacement session");
},
});
if (result.cancelled) {
// An extension cancelled the switch via session_before_switch
}
Options:
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.To discover available sessions, use the static SessionManager.list() or SessionManager.listAll() methods:
import { SessionManager } from "@mariozechner/pi-coding-agent";
pi.registerCommand("switch", {
description: "Switch to another session",
handler: async (args, ctx) => {
const sessions = await SessionManager.list(ctx.cwd);
if (sessions.length === 0) return;
const choice = await ctx.ui.select(
"Pick session:",
sessions.map(s => s.file),
);
if (choice) {
await ctx.switchSession(choice, {
withSession: async (ctx) => {
ctx.ui.notify("Switched session", "info");
},
});
}
},
});
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.withSession starts.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.const sm = ctx.sessionManager before replacement, sm is still the old SessionManager object. Do not reuse it after replacement.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:
pi.registerCommand("handoff", {
handler: async (_args, ctx) => {
const kickoff = "Continue from the replacement session";
await ctx.newSession({
withSession: async (ctx) => {
await ctx.sendUserMessage(kickoff);
},
});
},
});
Unsafe pattern:
pi.registerCommand("handoff", {
handler: async (_args, ctx) => {
const oldSessionManager = ctx.sessionManager;
await ctx.newSession({
withSession: async (_ctx) => {
// stale old objects: do not do this
oldSessionManager.getSessionFile();
pi.sendUserMessage("wrong");
},
});
},
});
Run the same reload flow as /reload.
pi.registerCommand("reload-runtime", {
description: "Reload extensions, skills, prompts, and themes",
handler: async (_args, ctx) => {
await ctx.reload();
return;
},
});
Important behavior:
await ctx.reload() emits session_shutdown for the current extension runtimesession_start with reason: "reload" and resources_discover with reason "reload"await ctx.reload() still runs from the pre-reload versionawait ctx.reload() must not assume old in-memory extension state is still validFor 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:
import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
import { Type } from "typebox";
export default function (pi: ExtensionAPI) {
pi.registerCommand("reload-runtime", {
description: "Reload extensions, skills, prompts, and themes",
handler: async (_args, ctx) => {
await ctx.reload();
return;
},
});
pi.registerTool({
name: "reload_runtime",
label: "Reload Runtime",
description: "Reload extensions, skills, prompts, and themes",
parameters: Type.Object({}),
async execute() {
pi.sendUserMessage("/reload-runtime", { deliverAs: "followUp" });
return {
content: [{ type: "text", text: "Queued /reload-runtime as a follow-up command." }],
};
},
});
}
Subscribe to events. See Events for event types and return values.
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.
import { Type } from "typebox";
import { StringEnum } from "@mariozechner/pi-ai";
pi.registerTool({
name: "my_tool",
label: "My Tool",
description: "What this tool does",
promptSnippet: "Summarize or transform text according to action",
promptGuidelines: ["Use my_tool when the user asks to summarize previously generated text."],
parameters: Type.Object({
action: StringEnum(["list", "add"] as const),
text: Type.Optional(Type.String()),
}),
prepareArguments(args) {
// Optional compatibility shim. Runs before schema validation.
// Return the current schema shape, for example to fold legacy fields
// into the modern parameter object.
return args;
},
async execute(toolCallId, params, signal, onUpdate, ctx) {
// Stream progress
onUpdate?.({ content: [{ type: "text", text: "Working..." }] });
return {
content: [{ type: "text", text: "Done" }],
details: { result: "..." },
};
},
// Optional: Custom rendering
renderCall(args, theme, context) { ... },
renderResult(result, options, theme, context) { ... },
});
Inject a custom message into the session.
pi.sendMessage({
customType: "my-extension",
content: "Message text",
display: true,
details: { ... },
}, {
triggerTurn: true,
deliverAs: "steer",
});
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.triggerTurn: true - If agent is idle, trigger an LLM response immediately. Only applies to "steer" and "followUp" modes (ignored for "nextTurn").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.
// Simple text message
pi.sendUserMessage("What is 2+2?");
// With content array (text + images)
pi.sendUserMessage([
{ type: "text", text: "Describe this image:" },
{ type: "image", source: { type: "base64", mediaType: "image/png", data: "..." } },
]);
// During streaming - must specify delivery mode
pi.sendUserMessage("Focus on error handling", { deliverAs: "steer" });
pi.sendUserMessage("And then summarize", { deliverAs: "followUp" });
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 toolsWhen 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.
Persist extension state (does NOT participate in LLM context).
pi.appendEntry("my-state", { count: 42 });
// Restore on reload
pi.on("session_start", async (_event, ctx) => {
for (const entry of ctx.sessionManager.getEntries()) {
if (entry.type === "custom" && entry.customType === "my-state") {
// Reconstruct from entry.data
}
}
});
Set the session display name (shown in session selector instead of first message).
pi.setSessionName("Refactor auth module");
Get the current session name, if set.
const name = pi.getSessionName();
if (name) {
console.log(`Session: ${name}`);
}
Set or clear a label on an entry. Labels are user-defined markers for bookmarking and navigation (shown in /tree selector).
// Set a label
pi.setLabel(entryId, "checkpoint-before-refactor");
// Clear a label
pi.setLabel(entryId, undefined);
// Read labels via sessionManager
const label = ctx.sessionManager.getLabel(entryId);
Labels persist in the session and survive restarts. Use them to mark important points (turns, checkpoints) in the conversation tree.
Register a command.
If multiple extensions register the same command name, pi keeps them all and assigns numeric invocation suffixes in load order, for example /review:1 and /review:2.
pi.registerCommand("stats", {
description: "Show session statistics",
handler: async (args, ctx) => {
const count = ctx.sessionManager.getEntries().length;
ctx.ui.notify(`${count} entries`, "info");
}
});
Optional: add argument auto-completion for /command ...:
import type { AutocompleteItem } from "@mariozechner/pi-tui";
pi.registerCommand("deploy", {
description: "Deploy to an environment",
getArgumentCompletions: (prefix: string): AutocompleteItem[] | null => {
const envs = ["dev", "staging", "prod"];
const items = envs.map((e) => ({ value: e, label: e }));
const filtered = items.filter((i) => i.value.startsWith(prefix));
return filtered.length > 0 ? filtered : null;
},
handler: async (args, ctx) => {
ctx.ui.notify(`Deploying: ${args}`, "info");
},
});
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.
const commands = pi.getCommands();
const bySource = commands.filter((command) => command.source === "extension");
const userScoped = commands.filter((command) => command.sourceInfo.scope === "user");
Each entry has this shape:
{
name: string; // Invokable command name without the leading slash. May be suffixed like "review:1"
description?: string;
source: "extension" | "prompt" | "skill";
sourceInfo: {
path: string;
source: string;
scope: "user" | "project" | "temporary";
origin: "package" | "top-level";
baseDir?: string;
};
}
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.
Register a custom TUI renderer for messages with your customType. See Custom UI.
Register a keyboard shortcut. See keybindings.md for the shortcut format and built-in keybindings.
pi.registerShortcut("ctrl+shift+p", {
description: "Toggle plan mode",
handler: async (ctx) => {
ctx.ui.notify("Toggled!");
},
});
Register a CLI flag.
pi.registerFlag("plan", {
description: "Start in plan mode",
type: "boolean",
default: false,
});
// Check value
if (pi.getFlag("plan")) {
// Plan mode enabled
}
Execute a shell command.
const result = await pi.exec("git", ["status"], { signal, timeout: 5000 });
// result.stdout, result.stderr, result.code, result.killed
Manage active tools. This works for both built-in tools and dynamically registered tools.
const active = pi.getActiveTools();
const all = pi.getAllTools();
// [{
// name: "read",
// description: "Read file contents...",
// parameters: ...,
// sourceInfo: { path: "<builtin:read>", source: "builtin", scope: "temporary", origin: "top-level" }
// }, ...]
const names = all.map(t => t.name);
const builtinTools = all.filter((t) => t.sourceInfo.source === "builtin");
const extensionTools = all.filter((t) => t.sourceInfo.source !== "builtin" && t.sourceInfo.source !== "sdk");
pi.setActiveTools(["read", "bash"]); // Switch to read-only
pi.getAllTools() returns name, description, parameters, and sourceInfo.
Typical sourceInfo.source values:
builtin for built-in toolssdk for tools passed via createAgentSession({ customTools })Set the current model. Returns false if no API key is available for the model. See models.md for configuring custom models.
const model = ctx.modelRegistry.find("anthropic", "claude-sonnet-4-5");
if (model) {
const success = await pi.setModel(model);
if (!success) {
ctx.ui.notify("No API key for this model", "error");
}
}
Get or set the thinking level. Level is clamped to model capabilities (non-reasoning models always use "off"). Changes emit thinking_level_select.
const current = pi.getThinkingLevel(); // "off" | "minimal" | "low" | "medium" | "high" | "xhigh"
pi.setThinkingLevel("high");
Shared event bus for communication between extensions:
pi.events.on("my:event", (data) => { ... });
pi.events.emit("my:event", { ... });
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. pi waits for the factory before startup continues, so the registered models are available immediately, including to pi --list-models.
// Register a new provider with custom models
pi.registerProvider("my-proxy", {
name: "My Proxy",
baseUrl: "https://proxy.example.com",
apiKey: "PROXY_API_KEY", // env var name or literal
api: "anthropic-messages",
models: [
{
id: "claude-sonnet-4-20250514",
name: "Claude 4 Sonnet (proxy)",
reasoning: false,
input: ["text", "image"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 200000,
maxTokens: 16384
}
]
});
// Override baseUrl for an existing provider (keeps all models)
pi.registerProvider("anthropic", {
baseUrl: "https://proxy.example.com"
});
// Register provider with OAuth support for /login
pi.registerProvider("corporate-ai", {
baseUrl: "https://ai.corp.com",
api: "openai-responses",
models: [...],
oauth: {
name: "Corporate AI (SSO)",
async login(callbacks) {
// Custom OAuth flow
callbacks.onAuth({ url: "https://sso.corp.com/..." });
const code = await callbacks.onPrompt({ message: "Enter code:" });
return { refresh: code, access: code, expires: Date.now() + 3600000 };
},
async refreshToken(credentials) {
// Refresh logic
return credentials;
},
getApiKey(credentials) {
return credentials.access;
}
}
});
Config options:
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 (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.streamSimple - Custom streaming implementation for non-standard APIs.See custom-provider.md for advanced topics: custom streaming APIs, OAuth details, model definition reference.
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.
pi.registerCommand("my-setup-teardown", {
description: "Remove the custom proxy provider",
handler: async (_args, _ctx) => {
pi.unregisterProvider("my-proxy");
},
});
Extensions with state should store it in tool result details for proper branching support:
export default function (pi: ExtensionAPI) {
let items: string[] = [];
// Reconstruct state from session
pi.on("session_start", async (_event, ctx) => {
items = [];
for (const entry of ctx.sessionManager.getBranch()) {
if (entry.type === "message" && entry.message.role === "toolResult") {
if (entry.message.toolName === "my_tool") {
items = entry.message.details?.items ?? [];
}
}
}
});
pi.registerTool({
name: "my_tool",
// ...
async execute(toolCallId, params, signal, onUpdate, ctx) {
items.push("new item");
return {
content: [{ type: "text", text: "Added" }],
details: { items: [...items] }, // Store for reconstruction
};
},
});
}
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.
import { withFileMutationQueue } from "@mariozechner/pi-coding-agent";
import { mkdir, readFile, writeFile } from "node:fs/promises";
import { dirname, resolve } from "node:path";
async execute(_toolCallId, params, _signal, _onUpdate, ctx) {
const absolutePath = resolve(ctx.cwd, params.path);
return withFileMutationQueue(absolutePath, async () => {
await mkdir(dirname(absolutePath), { recursive: true });
const current = await readFile(absolutePath, "utf8");
const next = current.replace(params.oldText, params.newText);
await writeFile(absolutePath, next, "utf8");
return {
content: [{ type: "text", text: `Updated ${params.path}` }],
details: {},
};
});
}
import { Type } from "typebox";
import { StringEnum } from "@mariozechner/pi-ai";
import { Text } from "@mariozechner/pi-tui";
pi.registerTool({
name: "my_tool",
label: "My Tool",
description: "What this tool does (shown to LLM)",
promptSnippet: "List or add items in the project todo list",
promptGuidelines: [
"Use my_tool for todo planning instead of direct file edits when the user asks for a task list."
],
parameters: Type.Object({
action: StringEnum(["list", "add"] as const), // Use StringEnum for Google compatibility
text: Type.Optional(Type.String()),
}),
prepareArguments(args) {
if (!args || typeof args !== "object") return args;
const input = args as { action?: string; oldAction?: string };
if (typeof input.oldAction === "string" && input.action === undefined) {
return { ...input, action: input.oldAction };
}
return args;
},
async execute(toolCallId, params, signal, onUpdate, ctx) {
// Check for cancellation
if (signal?.aborted) {
return { content: [{ type: "text", text: "Cancelled" }] };
}
// Stream progress updates
onUpdate?.({
content: [{ type: "text", text: "Working..." }],
details: { progress: 50 },
});
// Run commands via pi.exec (captured from extension closure)
const result = await pi.exec("some-command", [], { signal });
// Return result
return {
content: [{ type: "text", text: "Done" }], // Sent to LLM
details: { data: result }, // For rendering & state
// Optional: stop after this tool batch when every finalized tool result
// in the batch also returns terminate: true.
terminate: true,
};
},
// Optional: Custom rendering
renderCall(args, theme, context) { ... },
renderResult(result, options, theme, context) { ... },
});
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. See examples/extensions/structured-output.ts for a minimal example where the agent ends on a final structured-output tool call.
// Correct: throw to signal an error
async execute(toolCallId, params) {
if (!isValid(params.input)) {
throw new Error(`Invalid input: ${params.input}`);
}
return { content: [{ type: "text", text: "OK" }], details: {} };
}
Important: Use StringEnum from @mariozechner/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 pi 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 }].
pi.registerTool({
name: "edit",
label: "Edit",
description: "Edit a single file using exact text replacement",
parameters: Type.Object({
path: Type.String(),
edits: Type.Array(
Type.Object({
oldText: Type.String(),
newText: Type.String(),
}),
),
}),
prepareArguments(args) {
if (!args || typeof args !== "object") return args;
const input = args as {
path?: string;
edits?: Array<{ oldText: string; newText: string }>;
oldText?: unknown;
newText?: unknown;
};
if (typeof input.oldText !== "string" || typeof input.newText !== "string") {
return args;
}
return {
...input,
edits: [...(input.edits ?? []), { oldText: input.oldText, newText: input.newText }],
};
},
async execute(toolCallId, params, signal, onUpdate, ctx) {
// params now matches the current schema
return {
content: [{ type: "text", text: `Applying ${params.edits.length} edit block(s)` }],
details: {},
};
},
});
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.
# Extension's read tool replaces built-in read
pi -e ./tool-override.ts
Alternatively, use --no-builtin-tools to start without any built-in tools while keeping extension tools enabled:
# No built-in tools, only extension tools
pi --no-builtin-tools -e ./my-extension.ts
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:
ReadToolDetailsBashToolDetailsGrepToolDetailsFindToolDetailsLsToolDetailsBuilt-in tools support pluggable operations for delegating to remote systems (SSH, containers, etc.):
import { createReadTool, createBashTool, type ReadOperations } from "@mariozechner/pi-coding-agent";
// Create tool with custom operations
const remoteRead = createReadTool(cwd, {
operations: {
readFile: (path) => sshExec(remote, `cat ${path}`),
access: (path) => sshExec(remote, `test -r ${path}`).then(() => {}),
}
});
// Register, checking flag at execution time
pi.registerTool({
...remoteRead,
async execute(id, params, signal, onUpdate, _ctx) {
const ssh = getSshConfig();
if (ssh) {
const tool = createReadTool(cwd, { operations: createRemoteOps(ssh) });
return tool.execute(id, params, signal, onUpdate);
}
return localRead.execute(id, params, signal, onUpdate);
},
});
Operations interfaces: ReadOperations, WriteOperations, EditOperations, BashOperations, LsOperations, GrepOperations, FindOperations
For user_bash, extensions can reuse pi'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:
import { createBashTool } from "@mariozechner/pi-coding-agent";
const bashTool = createBashTool(cwd, {
spawnHook: ({ command, cwd, env }) => ({
command: `source ~/.profile\n${command}`,
cwd: `/mnt/sandbox${cwd}`,
env: { ...env, CI: "1" },
}),
});
See examples/extensions/ssh.ts for a complete SSH example with --ssh flag.
Tools MUST truncate their output to avoid overwhelming the LLM context. Large outputs can cause:
The built-in limit is 50KB (~10k tokens) and 2000 lines, whichever is hit first. Use the exported truncation utilities:
import {
truncateHead, // Keep first N lines/bytes (good for file reads, search results)
truncateTail, // Keep last N lines/bytes (good for logs, command output)
truncateLine, // Truncate a single line to maxBytes with ellipsis
formatSize, // Human-readable size (e.g., "50KB", "1.5MB")
DEFAULT_MAX_BYTES, // 50KB
DEFAULT_MAX_LINES, // 2000
} from "@mariozechner/pi-coding-agent";
async execute(toolCallId, params, signal, onUpdate, ctx) {
const output = await runCommand();
// Apply truncation
const truncation = truncateHead(output, {
maxLines: DEFAULT_MAX_LINES,
maxBytes: DEFAULT_MAX_BYTES,
});
let result = truncation.content;
if (truncation.truncated) {
// Write full output to temp file
const tempFile = writeTempFile(output);
// Inform the LLM where to find complete output
result += `\n\n[Output truncated: ${truncation.outputLines} of ${truncation.totalLines} lines`;
result += ` (${formatSize(truncation.outputBytes)} of ${formatSize(truncation.totalBytes)}).`;
result += ` Full output saved to: ${tempFile}]`;
}
return { content: [{ type: "text", text: result }] };
}
Key points:
truncateHead for content where the beginning matters (search results, file reads)truncateTail for content where the end matters (logs, command output)See examples/extensions/truncated-tool.ts for a complete example wrapping rg (ripgrep) with proper truncation.
One extension can register multiple tools with shared state:
export default function (pi: ExtensionAPI) {
let connection = null;
pi.registerTool({ name: "db_connect", ... });
pi.registerTool({ name: "db_query", ... });
pi.registerTool({ name: "db_close", ... });
pi.on("session_shutdown", async () => {
connection?.close();
});
}
Tools can provide renderCall and renderResult for custom TUI display. See tui.md 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.
pi.registerTool({
name: "my_tool",
label: "My Tool",
description: "Custom shell example",
parameters: Type.Object({}),
renderShell: "self",
async execute() {
return { content: [{ type: "text", text: "ok" }], details: undefined };
},
renderCall(args, theme, context) {
return new Text(theme.fg("accent", "my custom shell"), 0, 0);
},
});
renderCall and renderResult each receive a context object with:
args - the current tool call argumentsstate - shared row-local state across renderCall and renderResultlastComponent - the previously returned component for that slot, if anyinvalidate() - request a rerender of this tool rowtoolCallId, cwd, executionStarted, argsComplete, isPartial, expanded, showImages, isErrorUse 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.
Renders the tool call or header:
import { Text } from "@mariozechner/pi-tui";
renderCall(args, theme, context) {
const text = (context.lastComponent as Text | undefined) ?? new Text("", 0, 0);
let content = theme.fg("toolTitle", theme.bold("my_tool "));
content += theme.fg("muted", args.action);
if (args.text) {
content += " " + theme.fg("dim", `"${args.text}"`);
}
text.setText(content);
return text;
}
Renders the tool result or output:
renderResult(result, { expanded, isPartial }, theme, context) {
if (isPartial) {
return new Text(theme.fg("warning", "Processing..."), 0, 0);
}
if (result.details?.error) {
return new Text(theme.fg("error", `Error: ${result.details.error}`), 0, 0);
}
let text = theme.fg("success", "✓ Done");
if (expanded && result.details?.items) {
for (const item of result.details.items) {
text += "\n " + theme.fg("dim", item);
}
}
return new Text(text, 0, 0);
}
If a slot intentionally has no visible content, return an empty Component such as an empty Container.
Use keyHint() to display keybinding hints that respect the active keybinding configuration:
import { keyHint } from "@mariozechner/pi-coding-agent";
renderResult(result, { expanded }, theme, context) {
let text = theme.fg("success", "✓ Done");
if (!expanded) {
text += ` (${keyHint("app.tools.expand", "to expand")})`;
}
return new Text(text, 0, 0);
}
Available functions:
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 stringUse namespaced keybinding ids:
app.* namespace, for example app.tools.expand, app.editor.external, app.session.renametui.* namespace, for example tui.select.confirm, tui.select.cancel, tui.input.tabFor the exhaustive list of keybinding ids and defaults, see keybindings.md. 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().
Text with padding (0, 0). The default Box handles padding.\n for multi-line content.isPartial for streaming progress.expanded for detail on demand.context.args in renderResult instead of copying args into context.state.context.state only for data that must be shared across call and result slots.context.lastComponent when the same component instance can be updated in place.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.If a slot renderer is not defined or throws:
renderCall: Shows the tool namerenderResult: Shows raw text from contentExtensions can interact with users via ctx.ui methods and customize how messages/tools render.
For custom components, see tui.md which has copy-paste patterns for:
setWorkingMessage, setWorkingVisible, setWorkingIndicator)// Select from options
const choice = await ctx.ui.select("Pick one:", ["A", "B", "C"]);
// Confirm dialog
const ok = await ctx.ui.confirm("Delete?", "This cannot be undone");
// Text input
const name = await ctx.ui.input("Name:", "placeholder");
// Multi-line editor
const text = await ctx.ui.editor("Edit:", "prefilled text");
// Notification (non-blocking)
ctx.ui.notify("Done!", "info"); // "info" | "warning" | "error"
Dialogs support a timeout option that auto-dismisses with a live countdown display:
// Dialog shows "Title (5s)" → "Title (4s)" → ... → auto-dismisses at 0
const confirmed = await ctx.ui.confirm(
"Timed Confirmation",
"This dialog will auto-cancel in 5 seconds. Confirm?",
{ timeout: 5000 }
);
if (confirmed) {
// User confirmed
} else {
// User cancelled or timed out
}
Return values on timeout:
select() returns undefinedconfirm() returns falseinput() returns undefinedFor more control (e.g., to distinguish timeout from user cancel), use AbortSignal:
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 5000);
const confirmed = await ctx.ui.confirm(
"Timed Confirmation",
"This dialog will auto-cancel in 5 seconds. Confirm?",
{ signal: controller.signal }
);
clearTimeout(timeoutId);
if (confirmed) {
// User confirmed
} else if (controller.signal.aborted) {
// Dialog timed out
} else {
// User cancelled (pressed Escape or selected "No")
}
See examples/extensions/timed-confirm.ts for complete examples.
// Status in footer (persistent until cleared)
ctx.ui.setStatus("my-ext", "Processing...");
ctx.ui.setStatus("my-ext", undefined); // Clear
// Working loader (shown during streaming)
ctx.ui.setWorkingMessage("Thinking deeply...");
ctx.ui.setWorkingMessage(); // Restore default
ctx.ui.setWorkingVisible(false); // Hide the built-in working loader row entirely
ctx.ui.setWorkingVisible(true); // Show the built-in working loader row
// Working indicator (shown during streaming)
ctx.ui.setWorkingIndicator({ frames: [ctx.ui.theme.fg("accent", "●")] }); // Static dot
ctx.ui.setWorkingIndicator({
frames: [
ctx.ui.theme.fg("dim", "·"),
ctx.ui.theme.fg("muted", "•"),
ctx.ui.theme.fg("accent", "●"),
ctx.ui.theme.fg("muted", "•"),
],
intervalMs: 120,
});
ctx.ui.setWorkingIndicator({ frames: [] }); // Hide indicator
ctx.ui.setWorkingIndicator(); // Restore default spinner
// Widget above editor (default)
ctx.ui.setWidget("my-widget", ["Line 1", "Line 2"]);
// Widget below editor
ctx.ui.setWidget("my-widget", ["Line 1", "Line 2"], { placement: "belowEditor" });
ctx.ui.setWidget("my-widget", (tui, theme) => new Text(theme.fg("accent", "Custom"), 0, 0));
ctx.ui.setWidget("my-widget", undefined); // Clear
// Custom footer (replaces built-in footer entirely)
ctx.ui.setFooter((tui, theme) => ({
render(width) { return [theme.fg("dim", "Custom footer")]; },
invalidate() {},
}));
ctx.ui.setFooter(undefined); // Restore built-in footer
// Terminal title
ctx.ui.setTitle("pi - my-project");
// Editor text
ctx.ui.setEditorText("Prefill text");
const current = ctx.ui.getEditorText();
// Paste into editor (triggers paste handling, including collapse for large content)
ctx.ui.pasteToEditor("pasted content");
// Stack custom autocomplete behavior on top of the built-in provider
ctx.ui.addAutocompleteProvider((current) => ({
async getSuggestions(lines, line, col, options) {
const beforeCursor = (lines[line] ?? "").slice(0, col);
const match = beforeCursor.match(/(?:^|[ \t])#([^\s#]*)$/);
if (!match) {
return current.getSuggestions(lines, line, col, options);
}
return {
prefix: `#${match[1] ?? ""}`,
items: [{ value: "#2983", label: "#2983", description: "Extension API for autocomplete" }],
};
},
applyCompletion(lines, line, col, item, prefix) {
return current.applyCompletion(lines, line, col, item, prefix);
},
shouldTriggerFileCompletion(lines, line, col) {
return current.shouldTriggerFileCompletion?.(lines, line, col) ?? true;
},
}));
// Tool output expansion
const wasExpanded = ctx.ui.getToolsExpanded();
ctx.ui.setToolsExpanded(true);
ctx.ui.setToolsExpanded(wasExpanded);
// Custom editor (vim mode, emacs mode, etc.)
ctx.ui.setEditorComponent((tui, theme, keybindings) => new VimEditor(tui, theme, keybindings));
const currentEditor = ctx.ui.getEditorComponent();
ctx.ui.setEditorComponent((tui, theme, keybindings) =>
new WrappedEditor(tui, theme, keybindings, currentEditor?.(tui, theme, keybindings))
);
ctx.ui.setEditorComponent(undefined); // Restore default editor
// Theme management (see themes.md for creating themes)
const themes = ctx.ui.getAllThemes(); // [{ name: "dark", path: "/..." | undefined }, ...]
const lightTheme = ctx.ui.getTheme("light"); // Load without switching
const result = ctx.ui.setTheme("light"); // Switch by name
if (!result.success) {
ctx.ui.notify(`Failed: ${result.error}`, "error");
}
ctx.ui.setTheme(lightTheme!); // Or switch by Theme object
ctx.ui.theme.fg("accent", "styled text"); // Access current theme
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(...).
Use ctx.ui.addAutocompleteProvider() to stack custom autocomplete logic on top of the built-in slash-command and path provider.
Typical pattern:
current.getSuggestions(...)applyCompletion(...) unless you need custom insertion behaviorpi.on("session_start", (_event, ctx) => {
ctx.ui.addAutocompleteProvider((current) => ({
async getSuggestions(lines, cursorLine, cursorCol, options) {
const line = lines[cursorLine] ?? "";
const beforeCursor = line.slice(0, cursorCol);
const match = beforeCursor.match(/(?:^|[ \t])#([^\s#]*)$/);
if (!match) {
return current.getSuggestions(lines, cursorLine, cursorCol, options);
}
return {
prefix: `#${match[1] ?? ""}`,
items: [
{ value: "#2983", label: "#2983", description: "Extension API for registering custom @ autocomplete providers" },
{ value: "#2753", label: "#2753", description: "Reload stale resource settings" },
],
};
},
applyCompletion(lines, cursorLine, cursorCol, item, prefix) {
return current.applyCompletion(lines, cursorLine, cursorCol, item, prefix);
},
shouldTriggerFileCompletion(lines, cursorLine, cursorCol) {
return current.shouldTriggerFileCompletion?.(lines, cursorLine, cursorCol) ?? true;
},
}));
});
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.
For complex UI, use ctx.ui.custom(). This temporarily replaces the editor with your component until done() is called:
import { Text, Component } from "@mariozechner/pi-tui";
const result = await ctx.ui.custom<boolean>((tui, theme, keybindings, done) => {
const text = new Text("Press Enter to confirm, Escape to cancel", 1, 1);
text.onKey = (key) => {
if (key === "return") done(true);
if (key === "escape") done(false);
return true;
};
return text;
});
if (result) {
// User pressed Enter
}
The callback receives:
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 valueSee tui.md for the full component API.
Pass { overlay: true } to render the component as a floating modal on top of existing content, without clearing the screen:
const result = await ctx.ui.custom<string | null>(
(tui, theme, keybindings, done) => new MyOverlayComponent({ onClose: done }),
{ overlay: true }
);
For advanced positioning (anchors, margins, percentages, responsive visibility), pass overlayOptions. Use onHandle to control visibility programmatically:
const result = await ctx.ui.custom<string | null>(
(tui, theme, keybindings, done) => new MyOverlayComponent({ onClose: done }),
{
overlay: true,
overlayOptions: { anchor: "top-right", width: "50%", margin: 2 },
onHandle: (handle) => { /* handle.setHidden(true/false) */ }
}
);
See tui.md for the full OverlayOptions API and overlay-qa-tests.ts for examples.
Replace the main input editor with a custom implementation (vim mode, emacs mode, etc.):
import { CustomEditor, type ExtensionAPI } from "@mariozechner/pi-coding-agent";
import { matchesKey } from "@mariozechner/pi-tui";
class VimEditor extends CustomEditor {
private mode: "normal" | "insert" = "insert";
handleInput(data: string): void {
if (matchesKey(data, "escape") && this.mode === "insert") {
this.mode = "normal";
return;
}
if (this.mode === "normal" && data === "i") {
this.mode = "insert";
return;
}
super.handleInput(data); // App keybindings + text editing
}
}
export default function (pi: ExtensionAPI) {
pi.on("session_start", (_event, ctx) => {
ctx.ui.setEditorComponent((_tui, theme, keybindings) =>
new VimEditor(theme, keybindings)
);
});
}
Key points:
CustomEditor (not base Editor) to get app keybindings (escape to abort, ctrl+d, model switching)super.handleInput(data) for keys you don't handletheme and keybindings from the appctx.ui.getEditorComponent() before setEditorComponent() to wrap the previously configured custom editorundefined to restore default: ctx.ui.setEditorComponent(undefined)To compose with another extension that already replaced the editor, capture the previous factory before setting yours:
const previous = ctx.ui.getEditorComponent();
ctx.ui.setEditorComponent((tui, theme, keybindings) =>
new MyEditor(tui, theme, keybindings, { base: previous?.(tui, theme, keybindings) })
);
See tui.md Pattern 7 for a complete example with mode indicator.
Register a custom renderer for messages with your customType:
import { Text } from "@mariozechner/pi-tui";
pi.registerMessageRenderer("my-extension", (message, options, theme) => {
const { expanded } = options;
let text = theme.fg("accent", `[${message.customType}] `);
text += message.content;
if (expanded && message.details) {
text += "\n" + theme.fg("dim", JSON.stringify(message.details, null, 2));
}
return new Text(text, 0, 0);
});
Messages are sent via pi.sendMessage():
pi.sendMessage({
customType: "my-extension", // Matches registerMessageRenderer
content: "Status update",
display: true, // Show in TUI
details: { ... }, // Available in renderer
});
All render functions receive a theme object. See themes.md for creating custom themes and the full color palette.
// Foreground colors
theme.fg("toolTitle", text) // Tool names
theme.fg("accent", text) // Highlights
theme.fg("success", text) // Success (green)
theme.fg("error", text) // Errors (red)
theme.fg("warning", text) // Warnings (yellow)
theme.fg("muted", text) // Secondary text
theme.fg("dim", text) // Tertiary text
// Text styles
theme.bold(text)
theme.italic(text)
theme.strikethrough(text)
For syntax highlighting in custom tool renderers:
import { highlightCode, getLanguageFromPath } from "@mariozechner/pi-coding-agent";
// Highlight code with explicit language
const highlighted = highlightCode("const x = 1;", "typescript", theme);
// Auto-detect language from file path
const lang = getLanguageFromPath("/path/to/file.rs"); // "rust"
const highlighted = highlightCode(code, lang, theme);
tool_call errors block the tool (fail-safe)execute errors must be signaled by throwing; the thrown error is caught, reported to the LLM with isError: true, and execution continues| Mode | UI Methods | Notes |
|---|---|---|
| Interactive | Full TUI | Normal operation |
RPC (--mode rpc) | JSON protocol | Host handles UI, see rpc.md |
JSON (--mode json) | No-op | Event stream to stdout, see json.md |
Print (-p) | No-op | Extensions run but can't prompt |
In non-interactive modes, check ctx.hasUI before using UI methods.
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 |