* refactor(usage): remove agent-to-usage wiring
* feat(plugins): screens, sidebar header and footer items
Plugins register screens with addScreen and contribute component-based
sidebar items with addSidebarHeaderItem and addSidebarFooterItem. Items get
currentScreen, openScreen and openPopover, and render the SidebarRow and
SidebarButton kit. The footer shares the header's ordering model through the
new sidebarFooterItems preference, and Settings > Sidebar gains a Footer card.
addSurface, openSurface and addSidebarItem stay as aliases with their
settings keys and routes.
* refactor(plugins): share resolvePluginPlatform and keep header remembered-host key
Consolidate the five resolvePlatform copies into plugins/platform.ts.
Header sidebar items keep the <pluginId>/sidebar/<id> remembered-host key
so existing users keep their remembered host; footer items use
<pluginId>/sidebar-footer/<id>.
* feat(usage): global usage summary, pins and used/remaining display
- Device-local usage preferences (displayAs, pinned windows) in app settings.
- Sidebar footer usage summary: pinned windows in pin order, one per account;
opens the expanded view as a popover on desktop and a sheet on compact.
- Pin checkboxes on window rows and a used/remaining toggle shared by the
summary, popover, Usage screen and Settings usage section.
- Usage screen shows one host with a selector when several are connected.
- Extract HostSwitcher and the sidebar popover host for reuse.
* fix(usage): render each usage report as its own card
* feat(usage): row pinning, one title row for usage controls, even sidebar footer
- Window rows are the pin toggle (checkbox role, checked state); pinned rows
get a surface2 highlight, unpinned rows an interactionHighlight hover.
- Usage screen, Settings section, popover and sheet put the title left and
the host selector, used/remaining toggle and Refresh right (UsageControls).
PageLayout gains an actions slot; the menu sheet header a trailing slot.
- Sidebar footer rows share 28px height, spacing[1] gaps and one leading rail.
* fix(usage): keep row hover lighter than the pinned highlight
Hovering an unpinned window row shows the pinned surface2 at half opacity on
a separate layer, so it never reads stronger than a pinned row. Pinned rows
do not react to hover.
* fix(app): defer sidebar styles and preserve layout exports in timeline test
* fix(usage): open the Usage screen on desktop, drop the Usage footer icon, match git panel refresh
- Desktop presses on the usage summary open the Usage screen; only compact opens the sheet.
- The Usage footer icon is gone; with nothing pinned the summary renders a plain "Usage" row
in the footer row style. A stored `usage` footer preference is ignored.
- Refresh controls use the Changes panel's icon-only ToolbarButton with RotateCw.
* fix(sidebar): keep the footer icon row fixed; footer items are rows only
The footer's icon row (Hosts, Import session, Help and support, Settings) is back to main's
fixed implementation: not in Settings, not reorderable, and plugins can't add to it.
- Footer items are full-width rows between Add project and the icon row: the usage summary
and plugin `addSidebarFooterItem` rows. The Footer card in Settings lists only those rows.
- Stored `sidebarFooterItems` keys for hosts, import, help and usage are ignored.
- `SidebarButton` is removed from the plugin UI kit; a footer item renders `SidebarRow`.
* refactor(usage): call the sidebar footer item Usage
One concept, one word: the footer item is the Usage item, with key `usage`.
- Settings > Sidebar > Footer lists it as "Usage"; its preference key is `usage`.
- `usage/summary-item.tsx` becomes `usage/sidebar-item.tsx` (`UsageSidebarItem`); both states
use testID `sidebar-usage`.
- `usage/summary.ts` becomes `usage/pinned.ts` (`resolvePinnedUsage`, `PinnedUsageWindow`):
it resolves the pinned windows the item shows.
* feat(plugins): screen params, several rows per sidebar item, SidebarSeparator
openScreen takes { screenId, params }; params live in the screen route's
query so reload, history and links keep them. currentScreen carries the
params. A sidebar item may render a fragment or array of rows; a row press
anchors the popover to that row. SidebarSeparator joins the plugin UI kit.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(plugins): any screen param key; trailing presses anchor the row's popover
Screen params go in the query under a param. prefix, so keys like serverId
no longer collide with the route segments Expo Router merges into search
params. A press anywhere inside a SidebarRow, trailing content included,
makes that row the popover anchor.
Co-Authored-By: Claude <noreply@anthropic.com>
* feat(plugins): plugins title their screens
addScreen takes { id, title, Component }. title is a string or a function
of the screen's params; the screen header shows it and follows param
changes. A title function that throws or returns empty falls back to the
screen id. Legacy addSidebarItem screens keep their item's title and icon,
and the addSurface alias titles its screen with the id.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(usage): require discovery and remove unreleased agent resolver
* fix(plugins): restore legacy sidebar rows, share the item runtime, header hint presses its row
- Legacy addSidebarItem rows are their own group kind again: main's row, registered icon in
Settings, /sidebar/<id> route, host remembered per row.
- New-API items follow the host last used on any of the plugin's screens.
- /sidebar/<id> falls back to a same-id screen so pre-migration links resolve.
- params moves to PluginScreenProps; settings screens no longer receive it.
- Sidebar items, buttons and popovers share one runtime per installation, so no empty first frame.
- A header row's hint slot presses the row; labels wrap as on main.
- Skill and docs corrected.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(usage): one host resolver, sheet reuses the screen's controls, name the host
- The Usage row and screen default to the same host.
- The compact sheet carries the screen's controls, host selector included.
- The host selector shows with one host, and unavailable messages name the host.
- The row, sheet title and pinned label use the sidebar.footer.usage translation.
- Window rows read their percent and reset after the pin label.
- Drop the unread per-report cache writes and headline fixture fields.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(plugins): popovers, header buttons and composer pills own their runtime again
Only sidebar item rows use the installation's shared runtime. Popover content
disposes its runtime on unmount, so observations close with the popover.
* fix(plugins): a sidebar item releases its subscriptions when it unmounts
Each mounted sidebar item gets its own API scope over the host's client, created
during render so its first frame has content. The scope closes a microtask after
unmount (StrictMode's remount keeps it), when the item moves to another host, or
when the installation stops. Replaces the installation-wide shared runtime.
* refactor(plugins): one Paseo client per plugin; authors own their subscriptions
usePaseo() in every plugin surface, and client.paseo in setup, is the
installation's client, created with the installation in the registry. Authors
release their subscriptions in their own cleanup; plugin teardown disposes the
client and ends the rest. Nothing is created or disposed per mounted surface:
the per-surface runtimes, their boundaries, and the per-run Command Center and
slash command APIs are gone.
* refactor(plugins): one Paseo client per plugin; authors own their subscriptions
usePaseo() in every plugin surface, and client.paseo in setup, is the
installation's client, created with the installation in the registry. Authors
release their subscriptions in their own cleanup; plugin teardown disposes the
client and ends the rest. Nothing is created or disposed per mounted surface:
the per-surface runtimes, their boundaries, and the per-run Command Center and
slash command APIs are gone.
* fix(usage): show usage from released hosts
Normalize released-host usage responses at the client boundary so existing usage and pins remain available across app and daemon versions. Include account labels in legacy responses for older apps.
* fix(usage): keep the usage capability check out of the public SDK
* test(server): retry transient locks during runtime test cleanup
* test(usage): model hosts without either usage capability
---------
Co-authored-by: Claude <noreply@anthropic.com>
16 KiB
title, description, nav, order, category
| title | description | nav | order | category |
|---|---|---|---|---|
| Migrate a plugin to runtime entries | Mechanical migration from a mixed plugin entry to explicit client and server entries. | Migration | 47 | Plugins |
Migrate a plugin to runtime entries
Use this guide to update plugins written for Paseo 0.7 or earlier to the current client/server entry format, introduced in 0.8.
Give this page to a coding agent with the plugin directory as its working directory. Execute the steps in order. Do not keep a compatibility entry.
1. Classify the existing code
Start from the old shape:
my-plugin/
paseo-plugin.json
package.json
tsconfig.json
index.ts
greeting.client.tsx
greeting.server.ts
greeting.shared.ts
The finished shape is:
my-plugin/
paseo-plugin.json
package.json
tsconfig.json
index.client.tsx
index.server.ts
client/greeting.tsx
server/greeting.ts
shared/greeting.ts
Create only the entries the plugin needs. At least one is required. Components and client callbacks need the client entry. RPC handlers and Node APIs need the server entry.
2. Rename files and directories
Apply these rules exactly:
- Replace the mixed root entry with
index.client.tsx,index.server.ts, or both. - Move every
name.client.tsorname.client.tsxtoclient/name.tsorclient/name.tsx. - Move every
name.server.tsorname.server.tsxtoserver/name.tsorserver/name.tsx. - Move every
name.shared.tsorname.shared.tsxtoshared/name.tsorshared/name.tsx. - Preserve nested feature directories under the matching runtime directory.
- Update relative imports after every move.
- Keep
paseo-plugin.json,package.json, andtsconfig.jsonat the root. - Delete the old root entry. Paseo does not load it.
The directories are the compiler boundaries. A file beneath client/ compiles only into the app
bundle, a file beneath server/ only into the daemon bundle, and shared/ into both. Filename
suffixes such as *.client.tsx no longer mean anything, and a code module left at the plugin root
is a compile error.
3. Move every registration
Use this table as the complete registration checklist.
| Old registration and location | New registration and location |
|---|---|
plugin.handle(contract, handler) in the old root entry |
server.handle(contract, handler) in index.server.ts |
plugin.addSurface(id, Component) in the old root entry |
client.addScreen({ id, title, Component }) in index.client.tsx |
plugin.addSidebarItem({ id, title, icon, surface }) in the old root entry |
client.addSidebarHeaderItem({ id, title, Component }) in index.client.tsx; see sidebar items |
| New sidebar footer contribution | client.addSidebarFooterItem({ id, title, Component }) in index.client.tsx |
plugin.addWorkspacePanel(panel) in the old root entry |
client.addWorkspacePanel(panel) in index.client.tsx |
plugin.addCommandCenterItem(item) in the old root entry |
client.addCommandCenterItem(item) in index.client.tsx |
plugin.addClientSlashCommand(command) in the old root entry |
client.addSlashCommand(command) in index.client.tsx |
plugin.addClientSide(fn) in the old root entry |
Delete the wrapper and move the body of fn into the default client entry function |
client.addComposerPill(pill) inside the old client callback |
client.addComposerPill(pill) inside index.client.tsx or an imported client/ function |
| New header contribution | client.addHeaderButton({ id, workspaceId, button }) |
plugin.addAttachmentSource(source) in the old root entry |
client.addAttachmentSource(source) in index.client.tsx |
| New settings screen contribution | client.addSettingsScreen(screen) in index.client.tsx; see settings screens |
plugin.addTheme(theme) in the old root entry |
client.addTheme(theme) in index.client.tsx |
plugin.addTimelineTransformer(transformer) in the old root entry |
client.addTimelineTransformer(transformer) in index.client.tsx |
plugin.addTimelineRenderer(renderer) in the old root entry |
client.addTimelineRenderer(renderer) in index.client.tsx |
import { defineRpc, defineAttachmentSource } from "@getpaseo/plugin/server" in shared files |
import { defineRpc, defineAttachmentSource } from "@getpaseo/plugin" |
ZodOutput<typeof contract.input> handler parameter types |
RpcInput<typeof contract> from @getpaseo/plugin; RpcOutput for return types |
Register the screen that replaces an addSidebarItem under that item's id to keep saved links
working. A /plugin/<plugin>/sidebar/<id> link, and the older /plugin/<plugin>/<id>, opens the
addSidebarItem with that id, or else the screen with that id.
Import PluginClientContext from @getpaseo/plugin/client and PluginServerContext from
@getpaseo/plugin/server. Remove imports of the old context type. Client registrations return idempotent removal functions, except header buttons and composer pills, which return { update, remove } handles. Preserve any remover the plugin calls before teardown; Paseo removes outstanding
registrations after the entry cleanup runs.
Composer pills
Update the plugin project's @getpaseo/plugin dependency, then run npm run typecheck.
The old contribution is missing the required button field, PluginComposerPillProps is no longer
exported, and calling the new registration as a function is a TypeScript error. A project pinned
to the old SDK still checks against the old contract; installing or reloading a plugin does not
run TypeScript's type checker.
Replace the pill's Component with button.icon and button.label, move title into button,
and move onPress into button.behavior. Cleanup changes from calling the returned function to
calling its .remove() method.
const pill = client.addComposerPill({
id: "review",
workspaceId,
agentId,
button: {
title: "Open review",
icon: "Scan",
label: "Review",
behavior: { kind: "action", onPress: openReview },
},
});
pill.update({ label: "Review · 3", visible: true });
// Client entry cleanup:
pill.remove();
Move dynamic text from the former component into updates from your model or SDK subscription. Custom icon components may still use hooks. Composer pills always show icon and label and never show chevrons. See buttons for menus, popovers, and visibility.
4. Separate imports
Move hooks (usePaseo, useRpc, useSettings, useAgent, useWorkspace) and client contribution
types from @getpaseo/plugin to @getpaseo/plugin/client. Move Icon to
@getpaseo/plugin/client/react-native. Import server contexts and lifecycle contracts from
@getpaseo/plugin/server. Shared helpers (defineRpc, defineSettings, defineAttachmentSource),
schemas, and plain data types stay on the root. These rules include type imports. See
Runtime modules for the complete contract.
Move the remaining SDK subpaths under their runtime owner:
| Old entry | 0.8 entry |
|---|---|
@getpaseo/plugin/react-native |
@getpaseo/plugin/client/react-native |
@getpaseo/plugin/ui |
@getpaseo/plugin/client/ui |
@getpaseo/plugin/provider |
@getpaseo/plugin/server/provider |
@getpaseo/plugin/acp |
@getpaseo/plugin/server/acp |
The old entries and the pre-0.8 @paseo/plugin scope are removed. /client/host is private to
Paseo's app integration and is never a plugin-author import.
The client entry imports only client/, shared/, and client-safe packages. The server entry imports
only server/, shared/, and server-safe packages. A node: import in the client entry or anything
reachable from it is a compile error. Never import a component into the server entry merely to wire
its registration; that registration belongs in the client entry.
5. Recognize half-migration errors
| Compiler or load error | Meaning and fix |
|---|---|
This plugin has no requirements.paseo |
Complete the migration and declare the range in step 7. |
This plugin was made for an older version of Paseo |
The directory still has only the old root entry. Create a runtime entry, move registrations, then delete the old file. |
Plugin entry points are missing: expected index.client.ts or index.client.tsx and/or index.server.ts or index.server.tsx |
No supported entry exists. Add at least one exact filename. |
server-only module cannot be imported into the plugin client bundle: <file> |
A client import reaches server/. Move the call behind an RPC and import its contract from shared/. |
client-only module cannot be imported into the plugin server bundle: <file> |
A server import reaches client/. Move that registration and import to the client entry. |
Plugin modules belong in client/, server/, or shared/: <file> |
A code module is still at the plugin root. Move it into the matching directory and fix its imports. |
Node module cannot be imported into the plugin client bundle: node:<name> imported by <file> |
Client code imports a Node API. Move the operation to server/, expose an RPC in shared/, and call it from the client. |
TypeScript reports that PluginContext, addClientSide, or addClientSlashCommand does not exist |
Replace the old context types and registrations using the table above. |
6. Worked example: plugin-examples/local-plugin
Only the entry files and import paths change. Component and handler bodies move without edits.
Before:
local-plugin/
index.ts
main.client.tsx
increment.server.ts
increment.shared.ts
// index.ts
import type { PluginContext } from "@getpaseo/plugin";
import { contributeClient, ExamplePanel } from "./main.client";
import { increment } from "./increment.server";
import { incrementRpc } from "./increment.shared";
export default function contribute(plugin: PluginContext) {
plugin.handle(incrementRpc, increment);
plugin.addWorkspacePanel({
id: "counter",
title: "Plugin counter",
icon: "Blocks",
context: "workspace",
locations: ["workspace", "explorer"],
Component: ExamplePanel,
});
plugin.addCommandCenterItem({
id: "open-counter",
title: "Open plugin counter",
icon: "Blocks",
context: "workspace",
onSelect({ openPanel }) {
openPanel("counter");
},
});
plugin.addClientSide(contributeClient);
return () => {};
}
After:
local-plugin/
index.client.tsx
index.server.ts
client/main.tsx # was main.client.tsx
server/increment.ts # was increment.server.ts
shared/increment.ts # was increment.shared.ts
// index.client.tsx
import type { PluginClientContext } from "@getpaseo/plugin/client";
import { contributeClient, ExamplePanel } from "./client/main";
export default function contribute(client: PluginClientContext) {
client.addWorkspacePanel({
id: "counter",
title: "Plugin counter",
icon: "Blocks",
context: "workspace",
locations: ["workspace", "explorer"],
Component: ExamplePanel,
});
client.addCommandCenterItem({
id: "open-counter",
title: "Open plugin counter",
icon: "Blocks",
context: "workspace",
onSelect({ openPanel }) {
openPanel("counter");
},
});
return contributeClient(client);
}
// index.server.ts
import type { PluginServerContext } from "@getpaseo/plugin/server";
import { increment } from "./server/increment";
import { incrementRpc } from "./shared/increment";
export default function contribute(server: PluginServerContext) {
server.handle(incrementRpc, increment);
return () => {};
}
Import path changes inside the moved files:
// client/main.tsx
-import { incrementRpc } from "./increment.shared";
+import { incrementRpc } from "../shared/increment";
// server/increment.ts
-import { incrementRpc } from "./increment.shared";
+import { incrementRpc } from "../shared/increment";
contributeClient already took a PluginClientContext and returned cleanup, so the client entry
calls it directly and returns its cleanup. A plugin whose addClientSide callback also registered
pills or subscriptions keeps that code; only the wrapper goes away.
7. Declare the Paseo requirement
After migrating the entries and imports, add the minimum runtime version to paseo-plugin.json:
{
"id": "my-plugin",
"requirements": { "paseo": ">=0.8.0" }
}
Keep your existing ID and build commands. Missing requirements.paseo means <0.8.0, so Paseo 0.8 and later
reject the plugin even if its files have been moved. Adding the field alone does not migrate the
code. Update the local @getpaseo/plugin development dependency to the version you target and
reinstall dependencies before typechecking.
See requirements for range and prerelease semantics.
8. Verify the migration
Run:
npm run typecheck
paseo plugin reload <plugin-id>
paseo plugin ls
Require running with no error. Exercise every contribution. For plugins with RPCs, call the client
action and verify the server result. For client-only plugins, confirm the contribution loads without
a server process. Call any stored registration remover twice and verify the second call is a no-op.