Add AgentTool.prepareArguments and ToolDefinition.prepareArguments hook
that runs before schema validation in the agent loop. This lets tools
silently accept legacy argument shapes from resumed old sessions without
polluting the public schema.
The built-in edit tool uses this to fold legacy top-level oldText/newText
into edits[] when resuming sessions that predate the edits-only schema.
- AgentTool/ToolDefinition: typed prepareArguments returning Static<TParameters>
- agent-loop: prepareToolCallArguments() runs before validateToolArguments()
- edit tool: prepareEditArguments folds legacy fields, validateEditInput is strict
- Documented in extensions.md with edit-tool example
Adds a session_directory extension event that fires before session manager
creation, allowing extensions to customize the session directory path based
on cwd, git branch, or other context.
- Extensions can return a custom sessionDir in the event handler
- CLI --session-dir flag takes precedence over extension-provided paths
- If multiple extensions return a sessionDir, the last one wins
- Enables implementing branch-based sessions as an extension instead of core feature
This provides the extension point needed to implement git branch-based
session directories without adding the complexity to core.
Closes#1729
The previous fix (83b57924) replaced require.resolve() with bare
specifier fallbacks to avoid ERR_PACKAGE_PATH_NOT_EXPORTED for ESM-only
packages like pi-ai. However, bare specifiers are not valid jiti alias
targets, breaking extension loading in global npm installs.
Use import.meta.resolve() as the fallback instead. It respects the
"import" exports condition and returns a real file path.
The extension system currently only forwards agent_start, agent_end,
turn_start, and turn_end events. This means extensions cannot access
streaming text (token-by-token), message lifecycle, or tool execution
progress — all of which are available to internal subscribers.
This adds forwarding for the remaining 6 agent event types:
- message_start, message_update, message_end
- tool_execution_start, tool_execution_update, tool_execution_end
These follow the exact same pattern as the existing forwarded events:
new interfaces in types.ts, exports in index.ts, and else-if blocks
in _emitExtensionEvent(). The new types are included in ExtensionEvent
and automatically flow through RunnerEmitEvent (they're not in the
exclusion list).
This enables extensions to build real-time UIs, streaming WebSocket
bridges, and other integrations that need fine-grained event access.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Mario Zechner <badlogicgames@gmail.com>
After compaction, context token count is unknown until the next LLM
response. Instead of showing stale pre-compaction values or heuristic
estimates, the footer now shows ?/200k.
ContextUsage.tokens and ContextUsage.percent are now number | null
(breaking change). Removed usageTokens, trailingTokens, lastUsageIndex
from ContextUsage (internal details).
Also fixed _checkCompaction() using .find() (first compaction) instead
of getLatestCompactionEntry() (latest), which caused incorrect overflow
detection with multiple compactions.
Closes#1382
Include tool parameter names, types, descriptions in a collapsible
section under each tool in the export HTML. Also adds parameters to
pi.getAllTools() return value.
closes#1407, closes#1416
Add pasteToEditor(text) method that pastes text into the editor via
bracketed paste sequences, triggering paste handling (including collapse
for large content). Unlike setEditorText which directly replaces content,
pasteToEditor routes through handleInput on the active editor component.
- Add pasteToEditor to ExtensionUIContext interface
- Add handleInput to EditorComponent interface (was missing, all
concrete implementations already had it)
- Implement in interactive mode via bracketed paste sequence
- Add fallback in RPC mode (delegates to setEditorText)
- Document in extensions.md
BREAKING CHANGE: ToolDefinition.execute parameter order changed from
(id, params, onUpdate, ctx, signal) to (id, params, signal, onUpdate, ctx).
This aligns with AgentTool.execute so wrapping built-in tools no longer
requires parameter reordering. Update extensions by swapping signal and
onUpdate parameters.
Matches ToolResultEvent pattern with typed inputs via discriminated union.
- Export *ToolInput types from tool schemas
- Add *ToolCallEvent interfaces for each built-in tool
- Add isToolCallEventType() guard with overloads for built-ins
Direct narrowing (event.toolName === "bash") doesn't work due to
CustomToolCallEvent.toolName: string overlapping with literals.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Adds a method to access the effective system prompt (after any per-turn
extension modifications) from the extension context.
Implementation:
- Add systemPrompt getter to AgentSession reading from agent.state.systemPrompt
- Wire getSystemPrompt through ExtensionContextActions to ExtensionRunner
- Add getSystemPrompt to interactive-mode's shortcut context
- Update docs with ctx.getSystemPrompt() section
- Add system-prompt-header.ts example
- Add example to docs reference table
Closes#1098
* Add get_commands RPC for headless clients
Headless clients like Emacs can now query which commands are available.
Previously they could only discover file-based prompt templates by
scanning the filesystem; extension commands and skills were invisible.
The response includes each command's name, description, and source
(extension, template, or skill). Commands appear in the same order
as the TUI's autocomplete: extension commands first, then templates,
then skills.
Built-in TUI commands (/settings, /fork, etc.) are excluded since
they require the interactive UI. Commands like /compact have dedicated
RPC equivalents instead.
* Add location and path to get_commands response
Clients can show where commands come from (user/project/path) and
display file paths in tooltips. The data is already available on
templates and skills - just exposing it.
Mario Zechner