pi-config-manager
Manage Pi presets, tools, skills, context files, and extensions from one package.
Package details
Install pi-config-manager from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:pi-config-manager- Package
pi-config-manager- Version
0.2.0- Published
- Aug 2, 2026
- Downloads
- 686/mo · 36/wk
- Author
- hor1zonz
- License
- MIT
- Types
- extension, skill
- Size
- 116.3 KB
- Dependencies
- 0 dependencies · 2 peers
Pi manifest JSON
{
"extensions": [
"./src/index.ts"
],
"skills": [
"./skills"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
Pi Config Manager
Manage Pi tools, skills, context files, and extensions from one searchable TUI overlay.
English | 简体中文
Pi Config Manager is a resource-policy extension for Pi Coding Agent. Pi remains the source of truth for resource discovery, loading, deduplication, and provenance; Config Manager only decides which discovered resources are enabled.
Highlights
- One UI for Tools, Skills, Context Files, and Extensions
- Effective-state resource display showing what is currently available to the model
- Searchable, keyboard-driven overlay that keeps the current conversation visible
- Persistent Global resource settings, with presets isolated to the current session
- Context Monitor showing how the selected resource contributes to the model-visible prompt
- A compact resource HUD above the editor
- Source-aware extension toggles saved through Pi's public settings APIs
- Built-in named presets for model, thinking level, tools, skills, and instructions
- Optional runtime-layer event API for read-only modes and other policy extensions
- No telemetry and no network requests
Requirements
- Pi Coding Agent 0.83.x
- Interactive TUI mode for the visual manager
The current release is tested against Pi 0.83.0. Later Pi releases may work, but Pi's extension and TUI APIs can change; check this project's release notes before upgrading.
Install
Install globally for all projects:
pi install npm:pi-config-manager
Or install for the current project:
pi install -l npm:pi-config-manager
Try it for one run without changing settings:
pi -e npm:pi-config-manager
Start Pi, then run:
/config-manager
Quick start
- Run
/config-manager. - Press
Tabto move between resource tabs. - Type to filter the current list.
- Press
SpaceorEnterto toggle the selected resource in the automatically selected target. - In Extensions, press
Sto save staged changes and reload Pi.
Keyboard controls
| Key | Action |
|---|---|
Tab |
Next resource tab |
| Type text | Filter the current resource list |
↑ / ↓ |
Move through resources, or scroll the focused monitor |
← / → |
Focus the resource list or Context Monitor |
Space / Enter |
Toggle the selected resource in the active target |
S |
Save staged extension changes and reload Pi |
Esc |
Close the manager |
Keybinding-aware actions follow Pi's configured TUI keybindings.
Commands
| Command | Description |
|---|---|
/config-manager |
Open the unified overview |
/tools |
Open the Tools tab |
/skills |
Open the Skills tab |
/contexts |
Open the Context Files tab |
/extensions |
Open the Extensions tab |
/preset |
Select or clear a named preset |
/preset <name> |
Activate a named preset directly |
Global defaults can also be changed directly:
/tools global enable|disable <tool-name>
/skills global enable|disable <skill-name>
/contexts global enable|disable <absolute-path>
Effective view and automatic edit target
The visual manager always displays the Effective resource state: the result after Pi defaults, Global/project settings, the active preset, Session overrides, external activation, and runtime constraints have been composed. This is the state available to the model on the next provider request.
Editing remains automatic; there is no manual target-switching key:
- With no active preset, the header shows View: Effective · Edit: Global. Tool, skill, and context changes are written to
~/.pi/agent/resource-settings.jsonfor new sessions to inherit. - With a named preset active, the header shows View: Effective · Edit: Session · preset-name. Resource changes are stored only in the current session branch as overrides of that preset. They do not modify Global settings or
presets.json.
Runtime constraints have the highest tool precedence. A constrained row is marked with a visible lock and its owning layer, for example 🔒 edit · blocked by plan-mode or 🔒 grep · required by plan-mode. Locked tools cannot be toggled from the manager; clear the owning runtime constraint first. This prevents an edit that cannot change the Effective state.
A trusted project's .pi/resource-settings.json can also disable resources that the Global edit target cannot re-enable. These rows are marked blocked by project settings and locked while no preset is active; edit the project file directly. View, edit target, and constraints render on separate lines so they remain visible at the manager's minimum supported width.
Activating or clearing a preset changes the current session's model, thinking level, resources, and instructions. Session resume and tree navigation restore both the active preset and its session overrides.
Trusted projects may add repository-specific defaults in .pi/resource-settings.json. The visual Global edit target changes only Global settings; project files stay source-controlled and are edited separately.
Extension changes are independent of the Effective resource view. The Extensions tab therefore displays View/Edit: Pi settings. Changes are staged in the UI and then written to the appropriate global or project Pi settings when you press S and confirm reload.
Resource behavior
Tools
Unconstrained tool changes apply immediately through pi.setActiveTools(). Config Manager uses Pi's discovered tool inventory and preserves tools added by other extensions when it can observe them. Global defaults store both explicit enables and disables, so tools that Pi registered as initially inactive can still be enabled persistently.
Skills
Disabled skills are removed from Pi's standard system-prompt skill catalog. Invoking a disabled /skill:<name> command is also blocked with a notification.
Context Files
Disabled context files are removed from Pi's standard project_context prompt block. This controls model-visible prompt content; it does not prevent tools from reading a known file path.
Extensions
Extension toggles are staged until saved. Config Manager writes Pi's native extension/package filters through the public SettingsManager, then asks Pi to reload.
Pi cannot apply a per-extension filter when a local package source directly names a single extension file. Config Manager reports this case instead of saving an ineffective toggle. It also prevents disabling itself from its active UI.
Context Monitor
On wide terminals, the overlay displays resources on the left and a Context Monitor on the right. Selecting a resource shows:
- Tools: description, parameter schema, prompt snippet, and prompt guidelines
- Skills: the skill's system-prompt catalog entry
- Context Files: the complete
project_contextblock - Extensions: source, scope, package origin, and path details
Before the first agent run, the monitor uses Pi's current prompt preview. After a run starts, it shows the effective system prompt captured at agent_start and highlights the selected resource when present. Policy changes made while the manager is open appear in the captured prompt after the next agent run.
On narrow terminals, Config Manager falls back to the resource list without the monitor pane.
Configuration
Global defaults:
~/.pi/agent/resource-settings.json
Trusted project defaults:
.pi/resource-settings.json
Schema:
{
"version": 1,
"enabledTools": ["ast_grep_search"],
"disabledTools": ["write"],
"disabledSkills": ["deploy"],
"disabledContexts": ["/absolute/path/to/AGENTS.md"]
}
The active preset, its restoration state, and preset-specific session overrides are stored as version 2 pi-config-manager-state entries in Pi's session tree, so /tree, resume, and branch navigation restore the correct session policy.
Version 2 is an intentional breaking reset. Version 1 pi-config-manager-state, standalone preset-state, tools-config, and skills-manager-state entries are not imported.
Presets
Config Manager loads named presets from:
~/.pi/agent/presets.json
.pi/presets.json
Project-local presets are loaded only for trusted projects and override global presets with the same name. Each preset may configure:
{
"review": {
"provider": "openai-codex",
"model": "gpt-5.6-sol",
"thinkingLevel": "high",
"tools": ["read", "bash"],
"skills": ["preset-settings"],
"instructions": "Review carefully before making changes."
}
}
Use /preset, /preset <name>, pi --preset <name>, or Ctrl+Shift+U. Selecting (none) restores the model and thinking level captured before the first preset was activated, clears preset-specific resource overrides, and returns resources to the current Global/project policy. An explicit empty tools or skills array enables none; omitting either field preserves the corresponding normal policy. Preset instructions are appended to the system prompt while the preset is active.
The package includes the preset-settings skill for safely editing these files.
Policy precedence
runtime constraint > preset session override > preset > project/global setting > Pi default
Runtime constraints currently apply to tools. They are intended for integrations such as read-only or sandbox modes.
Policy architecture
Config Manager has one extension entrypoint and one PolicyManager. Pi defaults, Global/project settings, the first-party session-scoped Preset feature and its session overrides, and external runtime layers all submit policy to that core; only the core resolves and applies the effective resource state. Presets therefore use an internal typed profile-policy interface rather than a compatibility event bridge. External plugins retain the defensive runtime-layer event API below because they cannot share the package's internal controller.
Integration events
Config Manager works standalone. Other extensions can optionally coordinate policy through pi.events.
Runtime tool layer
pi.events.emit("config-manager:layer-set", {
id: "read-only-mode",
disableTools: ["edit", "write"],
requireTools: ["read"],
});
pi.events.emit("config-manager:layer-clear", {
id: "read-only-mode",
});
Layers compose by ID. Required tools are added after disabled tools for each layer, and only discovered tools can be activated. Callers may set or clear layers at any time, including before Config Manager's session_start; early events are stored and applied only after the default tool inventory is initialized.
To observe resource counts, listen for config-manager:state-changed. Emit config-manager:request-snapshot to request an immediate snapshot.
The former preset:tools-changed, preset:skills-changed, and config-manager:preset-state integration events have been removed. Presets are now owned directly by Config Manager.
Limitations and security
- Pi extensions run with the user's full system permissions. Review third-party packages before installing them.
- Config Manager is a prompt/resource policy tool, not a filesystem or process sandbox.
- Skill and context filtering expects Pi's standard prompt sections. If a custom system prompt removes or rewrites those sections, Config Manager leaves the prompt unchanged and warns the user.
- The visual manager requires TUI mode. In RPC, JSON, and print modes, the overlay is unavailable.
- Extension changes require a Pi reload.
Development
Requirements: Node.js 22.19+, Bun, and Pi 0.83.0+.
git clone https://github.com/Hor1zonZzz/pi-config-manager.git
cd pi-config-manager
npm install
npm run check
Run the local extension directly:
pi --no-extensions -e ./src/index.ts
Publishing releases
Stable GitHub Releases automatically publish the matching package version to npm through .github/workflows/publish.yml. The workflow checks out the release tag, verifies that v<package.json version> exactly matches the tag, runs the full check suite, and publishes with npm trusted publishing. Prereleases are intentionally skipped.
Before the first automated publish, configure the package on npmjs.com under Settings → Trusted Publisher → GitHub Actions:
- Organization or user:
Hor1zonZzz - Repository:
pi-config-manager - Workflow filename:
publish.yml - Allowed action:
npm publish
Then update package.json and package-lock.json, finalize CHANGELOG.md, commit and push, create the matching tag (for example v0.1.1), and publish a GitHub Release for that tag. The workflow uses OIDC, so no long-lived NPM_TOKEN secret is required. The npm configuration and workflow filename are case-sensitive.