What do you want to change?
I'd like to request exporting RpcExtensionUIRequest / RpcExtensionUIResponse from the public API
The RPC protocol's extension-UI types are the only part of the protocol that isn't reachable from @earendil-works/pi-coding-agent's public surface. AgentSessionEvent, RpcCommand, RpcResponse, and RpcSessionState are all exported from the root — but RpcExtensionUIRequest and RpcExtensionUIResponse defined right alongside them in rpc-types.ts are not
Why?
The extension-UI dialog methods (select, confirm, input, editor, notify, setStatus, setWidget, setTitle, set_editor_text) are a documented part of the RPC protocol. Any tool that re-transports that protocol over a different channel needs these shapes as part of its own contract.
Concretely: we run pi in-process via AgentSession and forward its protocol to browser clients over HTTP + SSE, generating our wire schema straight from pi's TypeScript types. That works cleanly everywhere pi exports the relevant type — AgentSessionEvent for events, RpcCommand / RpcResponse for commands. The extension-UI pair is the lone exception, so we currently maintain a hand-copy of those unions.
The problem with the copy is that it has no type-level link back to pi. When the extension-UI protocol changes (a new method, a renamed field), our mirror keeps compiling and drifts silently until it fails at runtime. Exporting these two types removes the last gap and lets the whole protocol surface be derived from pi as the single source of truth.
Deep-importing the module isn't an option: the exports map only exposes . and ./hooks, so @earendil-works/pi-coding-agent/dist/modes/rpc/rpc-types is rejected at runtime.
How? (optional)
Add the two types to the existing re-export in src/modes/index.ts, so they flow through the root export next to the other RPC types:
export type {
RpcCommand,
RpcExtensionUIRequest,
RpcExtensionUIResponse,
RpcResponse,
RpcSessionState,
} from "./rpc/rpc-types.ts";
This is purely additive — no new subpath, no behavior change
What do you want to change?
I'd like to request exporting
RpcExtensionUIRequest/RpcExtensionUIResponsefrom the public APIThe RPC protocol's extension-UI types are the only part of the protocol that isn't reachable from @earendil-works/pi-coding-agent's public surface.
AgentSessionEvent, RpcCommand, RpcResponse, and RpcSessionStateare all exported from the root — butRpcExtensionUIRequestandRpcExtensionUIResponsedefined right alongside them inrpc-types.tsare notWhy?
The extension-UI dialog methods (
select, confirm, input, editor, notify, setStatus, setWidget, setTitle, set_editor_text) are a documented part of the RPC protocol. Any tool that re-transports that protocol over a different channel needs these shapes as part of its own contract.Concretely: we run pi in-process via AgentSession and forward its protocol to browser clients over HTTP + SSE, generating our wire schema straight from pi's TypeScript types. That works cleanly everywhere pi exports the relevant type — AgentSessionEvent for events, RpcCommand / RpcResponse for commands. The extension-UI pair is the lone exception, so we currently maintain a hand-copy of those unions.
The problem with the copy is that it has no type-level link back to pi. When the extension-UI protocol changes (a new method, a renamed field), our mirror keeps compiling and drifts silently until it fails at runtime. Exporting these two types removes the last gap and lets the whole protocol surface be derived from pi as the single source of truth.
Deep-importing the module isn't an option: the exports map only exposes . and ./hooks, so @earendil-works/pi-coding-agent/dist/modes/rpc/rpc-types is rejected at runtime.
How? (optional)
Add the two types to the existing re-export in src/modes/index.ts, so they flow through the root export next to the other RPC types: