Files
yetone
be4298b294
library: Pi 0.99's own MCP — with Pi 0.99 or later on PATH and no MCP extension replacing it, MCP servers go in the mcp.json Pi reads itself, in its shape (command/args/env, url/headers, no adapter transport keys; SSE refused, which it has none of) (Discord feedback, 何似在人间: Pi now has native MCP) — Pi 0.99 (extensions/mcp/config.ts) reads mcpServers from <agent dir>/mcp.json, unless pi-mcp-adapter or pi-mcp-extension is installed (now also found in Pi's extensions folder) or settings.json has -builtin:mcp; then the files are as before. Servers magpie or the user had in mcp-adapter.json, which nothing reads now, are moved into mcp.json, the adapter's settings and anything mcp.json has differently left where they are and still found, both files backed up and written together (edit.Atomically). Without an adapter found, mcp.json is no longer moved to mcp-adapter.json, since it may be Pi's own. agent.InstalledVersion asks the CLI on PATH, once per binary. Tested with TestPiMCPNative in a sandbox HOME with a fake pi on PATH: 0.98 writes mcp-adapter.json, 0.99 moves the servers over with the user's fields kept, writes and removes in Pi's shape, SSE refused, the adapter (listed or in extensions) or -builtin:mcp keeps the old file; TestPiNativeVersions, TestInstalledVersion. go vet ./internal/..., go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried with a real Pi 0.99.
library: DeepSeek Harness (dsh) gets the library — its MCP servers as marked inserts of the dsh-mcp-client plugin in every profile's cordis.patch.yml (id magpie-mcp-<name>), a row the user inserted read like any other agent's and one holding a !!js value left alone; AGENTS.md and skills in its folder. SSE servers and names dsh can't take are refused with a reason (#107)
library: DeepSeek Harness (dsh) gets the library — its MCP servers as marked inserts of the dsh-mcp-client plugin in every profile's cordis.patch.yml (id magpie-mcp-<name>), a row the user inserted read like any other agent's and one holding a !!js value left alone; AGENTS.md and skills in its folder. SSE servers and names dsh can't take are refused with a reason (#107)
library: instructions come in sets — Default and any others named, each its own text, one of them the one the agents read; a set is added, renamed, switched to and removed (after a confirm, never the one in use or Default) in Library → Instructions, and a setup snapshot keeps which was in use. Providers: each protocol keeps its own URL, so a saved chat URL no longer shows as the Anthropic one; a URL typed and not saved yet moves to the protocol picked after it, spelled as that one wants it (/v1 dropped for Anthropic, added for OpenAI). Settings: an open WebDAV, export or import form is no longer emptied when the window regains focus. Tested in the browser from a sandbox. Issues #104 #105 #106
agent: Pi's MCP servers go where pi-mcp-adapter reads them now (xiaozhu1337 on #58: pi-mcp-adapter no longer reads …\.pi\agent\mcp.json) — pi-mcp-adapter 3 (3.0.0 2026-09-26, 3.1.0 now) reads <agent dir>/mcp-adapter.json, same format, after ~/.config/mcp/mcp.json and ~/.agents/mcp.json (.mcp.json and .pi/mcp-adapter.json per project), and no longer <agent dir>/mcp.json; at every session start it warns while that file has any server, settings, imports or claudePlugins, whether or not mcp-adapter.json is there too (config.ts getLegacyMcpMigrationNotices, index.ts session_start). magpie only looked for the adapter in <agent dir>/npm/node_modules, so one Pi installed the older way (npm -g: %APPDATA%\npm\node_modules and the like, which Pi 0.87's package manager still resolves), from git, or from a folder counted as none and mcp.json kept being written; and with mcp-adapter.json already there (the adapter's own setup writes it) mcp.json's servers were left behind. Now which extension Pi has comes from settings.json's packages (a pin like npm:pi-mcp-adapter@2.9.1 counts) and the folders Pi installs them in: adapter 3, or listed with no version found, or mcp-adapter.json there → mcp-adapter.json; mcp.json is renamed to it when there is none, else each server and setting it lacks is merged in (backed up first), one the two have differently left in mcp.json for the user, and mcp.json removed once empty. pi-mcp-extension 1.5 reads only ~/.pi/agent/mcp.json (its home's, not PI_CODING_AGENT_DIR's; transport field, zod schema): with it alone that file, with both each file gets the servers (user fields in each entry kept) and mcp.json isn't moved — the adapter's warning can't be avoided then. Adapter before 3 → mcp.json; nothing found → mcp.json if there, else mcp-adapter.json. Servers in either file are found for bringing into the library. Tested in sandbox homes, and against the real 3.1.0 loader: the reporter's shape (adapter under npm's global folder, mcp.json from magpie, mcp-adapter.json from setup) warned before, and after one magpie write it gives no notice and loads all three servers
library: MCP servers, skills and instructions are kept once in magpie and given to any agent from one place, with a market to find and add them (#29). Each agent reads MCP servers and skills from files of its own and in a format of its own, so one server was set up again in Claude Code, Codex, Gemini CLI, OpenCode, Pi, Goose, Cursor, Copilot CLI and Crush. The Library view keeps each once: a server is added (stdio, http or sse, its env and headers) and switched on per agent with its icon, and magpie writes it into each agent's config in that agent's format, leaving what the agent has of its own as it is; a server or skill an agent already has is shown, to bring into the library. A skill is a folder with a SKILL.md, kept in the library from GitHub (owner/repo, or a link to a folder in one; updated from it later) or linked from a folder on this machine, and linked into each agent's skills folder. The instructions every agent reads (CLAUDE.md, AGENTS.md, GEMINI.md…) can be kept as one too. The market offers checked MCP servers first, then the official MCP Registry's, filled in from what the registry says each needs (keys asked for in a form, never guessed), and skills.sh's most installed skills with what each says it is for; each shows its real icon (the vendor's own, else its GitHub owner's), fetched through magpie only for the icons the market or the library gave out, and an added server or skill keeps its icon in the library. What magpie changes in an agent's files is backed up first
library: a skill whose folder is gone can be removed (#151) — its folder was moved aside with the backups on removal, and with no folder the move failed (rename …: The system cannot find the file specified), so a skill marked as no longer in the library stayed listed for good. Now only its entry is taken out when its folder isn't there
profiles: a saved profile keeps the Library's setup too, and switching to it switches that as well (#29) — which agents get each MCP server and skill, and the instructions (the shared text, the agents it is written to, what each gets besides), so moving from one profile to another left the tools and the instructions as they were and only the models followed. A profile keeps them under "library" beside its agent.field keys; the servers and skills themselves stay in the library, a profile only names them. Applying one sets the models as before, then gives each server and skill to the agents it names and puts the instructions back, written into the agents as any Library change is, their files and the library's own instructions kept aside first; one removed from the library since is skipped and said so, one added since keeps its agents (the profile knows nothing of it, and switching it off would lose it for good). A profile saved before, or while the library was empty, carries none and leaves the library as it is. magpie profiles, the TUI and the panel's chips say what a profile gives out (+ library: 2 servers, 1 skill, instructions)
library: instructions come in sets — Default and any others named, each its own text, one of them the one the agents read; a set is added, renamed, switched to and removed (after a confirm, never the one in use or Default) in Library → Instructions, and a setup snapshot keeps which was in use. Providers: each protocol keeps its own URL, so a saved chat URL no longer shows as the Anthropic one; a URL typed and not saved yet moves to the protocol picked after it, spelled as that one wants it (/v1 dropped for Anthropic, added for OpenAI). Settings: an open WebDAV, export or import form is no longer emptied when the window regains focus. Tested in the browser from a sandbox. Issues #104 #105 #106
library: skills in the user-wide ~/.agents/skills are found, one row with the agents that link or junction to them, and brought in by a link that leaves the shared folder as it is (#227 Aimer779: the Library's "In your agents" never looked in ~/.agents/skills, the shared folder many agents read and where the user keeps skills, many as symlinks to D:\aimer-skills; a skill junctioned from there into Pi and ZCode showed as Pi's with "differs in ZCode") — foundSkills walked only each target's own skills folder, and realDir used filepath.EvalSymlinks, which since Go 1.23 leaves a Windows junction (a mount point, reported as irregular, not a symlink) as it is, so two junctions to one folder were two skills, and the Link check (ModeSymlink) took a junction for a folder of its own, one ImportSkill would move. Now foundSkills reads ~/.agents/skills first (hidden entries, ones without a SKILL.md, ones the library has or linked, skipped as for the agents' folders), a skill there carrying shared (its entry) and the agents whose entry resolves to the very same folder; a byte copy in an agent's folder is still another ("differs in"), as copies were. realDir follows links a part at a time itself (symlinks, and on Windows junctions through os.Readlink, relative targets, links to links, a loop or a missing part giving the path back), and a new linked() (symlink, or junction on Windows) replaces the ModeSymlink checks in foundSkills and ImportSkill. ImportSkill links the library to a skill in the shared folder (Source folder), real folder or link alike, and never moves it; the agents' links to it are replaced by the library's as before; an agent's own folder still moves in. No target writes to ~/.agents/skills: targets.go gives no agent a user-wide ~/.agents/skills (only projects.go's project .agents/skills), so it stays a place skills are found in. The page: a found skill in the shared folder says "shared in ~/.agents/skills/<name>" (共享于) above any "linked from", its Bring in title says it stays where it is and can be given to any agent; the shared path is revealable. Tested with TestSharedAgentsSkills (sandbox HOME/USERPROFILE: a symlink in the shared folder to a folder elsewhere, real folders there, Pi and Codex links to one of them, absolute and relative, Gemini's link to the shared link, a Codex copy, a folder with no SKILL.md and a hidden one; one row each with the right agents, shared, link and others; importing all three leaves the shared folder and the folder elsewhere as they were, the library's entries links to them, the agents' links now the library's, Codex's copy untouched, nothing found after), TestRealDir (absolute, relative, a linked parent, .., a loop, a missing path, linked, within) and TestJunction (mklink /J, Windows only, skipped here), and a new internal/gui/tests/shared-skills.test.cjs in Chromium and WebKit, en and zh. go build -tags nogui (and GOOS=linux, GOOS=windows), go vet for windows and go test -tags nogui ./... pass (TestClaudeSignedOut flaked once, passes alone); the GUI suite passes but for login-import (passes alone) and panel-profiles in WebKit, which fails on main the same under this load. Not tried on real Windows, with real junctions, or in the real window.
library: skills in the user-wide ~/.agents/skills are found, one row with the agents that link or junction to them, and brought in by a link that leaves the shared folder as it is (#227 Aimer779: the Library's "In your agents" never looked in ~/.agents/skills, the shared folder many agents read and where the user keeps skills, many as symlinks to D:\aimer-skills; a skill junctioned from there into Pi and ZCode showed as Pi's with "differs in ZCode") — foundSkills walked only each target's own skills folder, and realDir used filepath.EvalSymlinks, which since Go 1.23 leaves a Windows junction (a mount point, reported as irregular, not a symlink) as it is, so two junctions to one folder were two skills, and the Link check (ModeSymlink) took a junction for a folder of its own, one ImportSkill would move. Now foundSkills reads ~/.agents/skills first (hidden entries, ones without a SKILL.md, ones the library has or linked, skipped as for the agents' folders), a skill there carrying shared (its entry) and the agents whose entry resolves to the very same folder; a byte copy in an agent's folder is still another ("differs in"), as copies were. realDir follows links a part at a time itself (symlinks, and on Windows junctions through os.Readlink, relative targets, links to links, a loop or a missing part giving the path back), and a new linked() (symlink, or junction on Windows) replaces the ModeSymlink checks in foundSkills and ImportSkill. ImportSkill links the library to a skill in the shared folder (Source folder), real folder or link alike, and never moves it; the agents' links to it are replaced by the library's as before; an agent's own folder still moves in. No target writes to ~/.agents/skills: targets.go gives no agent a user-wide ~/.agents/skills (only projects.go's project .agents/skills), so it stays a place skills are found in. The page: a found skill in the shared folder says "shared in ~/.agents/skills/<name>" (共享于) above any "linked from", its Bring in title says it stays where it is and can be given to any agent; the shared path is revealable. Tested with TestSharedAgentsSkills (sandbox HOME/USERPROFILE: a symlink in the shared folder to a folder elsewhere, real folders there, Pi and Codex links to one of them, absolute and relative, Gemini's link to the shared link, a Codex copy, a folder with no SKILL.md and a hidden one; one row each with the right agents, shared, link and others; importing all three leaves the shared folder and the folder elsewhere as they were, the library's entries links to them, the agents' links now the library's, Codex's copy untouched, nothing found after), TestRealDir (absolute, relative, a linked parent, .., a loop, a missing path, linked, within) and TestJunction (mklink /J, Windows only, skipped here), and a new internal/gui/tests/shared-skills.test.cjs in Chromium and WebKit, en and zh. go build -tags nogui (and GOOS=linux, GOOS=windows), go vet for windows and go test -tags nogui ./... pass (TestClaudeSignedOut flaked once, passes alone); the GUI suite passes but for login-import (passes alone) and panel-profiles in WebKit, which fails on main the same under this load. Not tried on real Windows, with real junctions, or in the real window.
agent: Pi's MCP servers go where pi-mcp-adapter reads them now (xiaozhu1337 on #58: pi-mcp-adapter no longer reads …\.pi\agent\mcp.json) — pi-mcp-adapter 3 (3.0.0 2026-09-26, 3.1.0 now) reads <agent dir>/mcp-adapter.json, same format, after ~/.config/mcp/mcp.json and ~/.agents/mcp.json (.mcp.json and .pi/mcp-adapter.json per project), and no longer <agent dir>/mcp.json; at every session start it warns while that file has any server, settings, imports or claudePlugins, whether or not mcp-adapter.json is there too (config.ts getLegacyMcpMigrationNotices, index.ts session_start). magpie only looked for the adapter in <agent dir>/npm/node_modules, so one Pi installed the older way (npm -g: %APPDATA%\npm\node_modules and the like, which Pi 0.87's package manager still resolves), from git, or from a folder counted as none and mcp.json kept being written; and with mcp-adapter.json already there (the adapter's own setup writes it) mcp.json's servers were left behind. Now which extension Pi has comes from settings.json's packages (a pin like npm:pi-mcp-adapter@2.9.1 counts) and the folders Pi installs them in: adapter 3, or listed with no version found, or mcp-adapter.json there → mcp-adapter.json; mcp.json is renamed to it when there is none, else each server and setting it lacks is merged in (backed up first), one the two have differently left in mcp.json for the user, and mcp.json removed once empty. pi-mcp-extension 1.5 reads only ~/.pi/agent/mcp.json (its home's, not PI_CODING_AGENT_DIR's; transport field, zod schema): with it alone that file, with both each file gets the servers (user fields in each entry kept) and mcp.json isn't moved — the adapter's warning can't be avoided then. Adapter before 3 → mcp.json; nothing found → mcp.json if there, else mcp-adapter.json. Servers in either file are found for bringing into the library. Tested in sandbox homes, and against the real 3.1.0 loader: the reporter's shape (adapter under npm's global folder, mcp.json from magpie, mcp-adapter.json from setup) warned before, and after one magpie write it gives no notice and loads all three servers