Rafał Lindemann
1f5b6143d6
* fix(plugins): keep React out of the server plugin host * fix(plugins): align SDK guidance and tests with runtime boundaries * fix(plugin): loosen the react peer to ~19.1.0 The plugin SDK pins its react peer to exactly 19.1.0, and that pin is what a downstream `npm i -g @getpaseo/cli` resolves against. So every user ends up with react 19.1.0 in their global node_modules, where corporate dependency scanners flag it: the CVE-2025-55182 advisory range covers 19.1.0 even though the vulnerability itself lives in react-server-dom-webpack/-parcel/-turbopack, none of which the CLI installs. The user is then left hand-patching node_modules or uninstalling Paseo. Widening the peer to ~19.1.0 lets a downstream install pick the latest 19.1.x patch (19.1.9 today) while this repo stays on 19.1.0, which the root override still pins. Keeping the repo itself on 19.1.0 is deliberate. react-native 0.81.5 embeds a 19.1.0 Paper renderer that hard-throws "Incompatible React versions" on any exact mismatch, and it is reachable from Fabric builds too: RendererImplementation.js requires the Paper shim unconditionally in findNodeHandle, unstable_batchedUpdates, sendAccessibilityEvent and three other entry points, and react-native-gesture-handler re-exports findNodeHandle. Bumping the app's react is therefore not safe until react-native moves. The published CLI tree contains no react-native, so downstream installs are not subject to that constraint. Supersedes the earlier 19.1.5/19.1.9 version-bump approach on this branch, which would have broken the mobile app. * Enforce example import ownership including client types * Update Nix dependency hash for plugin peer metadata * Group plugin APIs under client and server entry trees * Resolve plugin type dependencies through declarations * Validate declarations for implicit plugin type imports * Preserve optional imports and validate declaration references * Refresh Nix hash for plugin declaration resolver * Canonicalize plugin paths consistently on Windows * Normalize plugin ownership paths across resolver boundaries --------- Co-authored-by: liujin0506 <liujin0506@qq.com> Co-authored-by: Mohamed Boudra <boudra.moha@gmail.com>
Agent configuration
Changes new Codex agents through server.before("agent.create", ...):
- Sets
config.providerOptions.sandbox_modetoworkspace-write. - Sets
config.providerOptions.approval_policytoon-request. - Adds the
companyserver toconfig.mcpServers. - Preserves other configuration, provider options, MCP servers, and environment overrides.
Replace https://tools.example.com/mcp in index.server.ts with your MCP server URL before using
this example. The URL is a placeholder. The company entry replaces an existing server with that name.
Install on a daemon with plugins enabled:
paseo plugin install /absolute/path/to/plugin-examples/agent-configuration
The callback receives the request after earlier plugins have transformed it. The nested spreads preserve their settings; the explicit values replace only the named fields. Paseo validates and saves the resulting configuration before starting the agent. Existing agents are unchanged.
See the lifecycle reference for ordering and callback shapes. Lifecycle actions demonstrates provider switching and environment injection. Its provider-switch callback clears provider options when changing Codex to Claude, so use these examples separately when trying the Codex-specific settings.