magpie

backup.go

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 )

2026-09-27 17:22:03 +08:00

carry_test.go

backup: the library goes with a backup and a WebDAV sync — the instructions, MCP servers and skills with their files, a fifth part, ticked by default (magpie backup/restore --no-library). A backup without keys leaves the servers' secret env and headers empty and a restore fills them from the servers kept here; a skill's file over 2 MB, or past 32 MB in all, stays behind; a path that climbs out of its skill is refused. What it replaces is kept with the library's backups. Tested from a sandbox: exported without keys, changed and removed things, imported — the server back with the local key kept, the skill back as files, run.sh still executable

2026-09-27 17:24:53 +08:00

carry.go

backup: the library goes with a backup and a WebDAV sync — the instructions, MCP servers and skills with their files, a fifth part, ticked by default (magpie backup/restore --no-library). A backup without keys leaves the servers' secret env and headers empty and a restore fills them from the servers kept here; a skill's file over 2 MB, or past 32 MB in all, stays behind; a path that climbs out of its skill is refused. What it replaces is kept with the library's backups. Tested from a sandbox: exported without keys, changed and removed things, imported — the server back with the local key kept, the skill back as files, run.sh still executable

2026-09-27 17:24:53 +08:00

ccswitch_test.go

library: a skill CC Switch installed can be updated from GitHub — linked from ~/.cc-switch/skills it had no source, so it showed no update button; the repository and branch CC Switch recorded for it are read (read-only) from its database, and updating fetches the skill from there and makes it the library's own copy, leaving CC Switch's folder as it was

2026-09-25 21:34:02 +08:00

ccswitch.go

library: a skill CC Switch installed can be updated from GitHub — linked from ~/.cc-switch/skills it had no source, so it showed no update button; the repository and branch CC Switch recorded for it are read (read-only) from its database, and updating fetches the skill from there and makes it the library's own copy, leaving CC Switch's folder as it was

2026-09-25 21:34:02 +08:00

dsh.go

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 )

2026-09-27 17:22:03 +08:00

instructions.go

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

2026-09-27 17:05:59 +08:00

library_test.go

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

2026-09-29 00:44:43 +08:00

library.go

library: a project's agents can have some of the library's skills as the project's own — under Skills, In projects takes a folder (the system's picker in the app, a typed path anywhere) and each of its skills gets agents' chips; magpie links the skill into <project>/.claude/skills for Claude Code and <project>/.agents/skills for Codex, Gemini CLI, OpenCode, Pi, Cursor and Copilot (the agents documented to read it; MiMo Code, Crush, ZCode, DeepSeek Harness and oh-my-pi aren't, so they're left out), or copies it when the project asks for copies, a copy made again whenever the library's skill changes (updates included). What it places is listed between magpie's marks in the project's .gitignore, made if there was none; taking a skill or the project away removes only what magpie placed, its lines and the folders it made once empty, and a folder of the same name that isn't magpie's is left as it is and said so. The home folder, or one whose project skills folder is an agent's own, can't be added

2026-09-28 13:34:17 +08:00

market_skills.json

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

2026-09-25 14:11:17 +08:00

market_test.go

images: agents can generate and edit images with a model set in Magpie (让Magpie支持配置图像识别模型以及生图模型, part 2) — the gateway answers /v1/images/generations and /v1/images/edits for any model that draws: an images-API model (gpt-image-1, dall-e, imagen, a relay's) is sent the vendor's own images request (an edit as multipart, image[] per reference); a chat model that answers with images (OpenRouter's Nano Banana and GPT-5 Image, gpt-5-image) is asked with modalities ["image","text"], the size given as an aspect ratio, once per image asked for; Gemini's own image models over generateContent. Either way the answer is the images API's (b64_json with its mime_type, the model's text, usage), recorded in usage like any request. The model is Settings → Images → Image generation: Automatic (a model that draws among the providers set up, from the catalog's image-output models), Off, or any model; a request that names none is drawn by it, and with it Off is refused saying where to set one. Subscriptions draw nothing yet. magpie mcp image is a stdio MCP server with one tool, generate_image (prompt, size, n, path, reference_images): it asks the agent for its roots, saves each image in the project (assets/ by default, a name from the prompt, never over a file, the extension of what came back — a JPEG asked for as hero.png is hero.jpg), and says where; reference images are read from the project and sent as an edit. Its requests carry the agent's own name (claude-code/… magpie-image/1) so usage says which agent drew. Library → MCP servers → Discover has it as Magpie Image, opt-in: no agent is given it until picked, since every image costs what the model charges. Checked in a sandbox HOME against real vendors: OpenRouter's gemini-3.1-flash-lite-image drew a 3:2 magpie over MCP as Claude Code and edited it from the saved file as Codex (usage: claude, codex), AIHubMix's gpt-image-1 answered /v1/images/generations with a 1024² PNG; the Settings row and picker in light and dark, the Library card and its opt-in sheet

2026-09-29 01:52:53 +08:00

market.go

images: agents can generate and edit images with a model set in Magpie (让Magpie支持配置图像识别模型以及生图模型, part 2) — the gateway answers /v1/images/generations and /v1/images/edits for any model that draws: an images-API model (gpt-image-1, dall-e, imagen, a relay's) is sent the vendor's own images request (an edit as multipart, image[] per reference); a chat model that answers with images (OpenRouter's Nano Banana and GPT-5 Image, gpt-5-image) is asked with modalities ["image","text"], the size given as an aspect ratio, once per image asked for; Gemini's own image models over generateContent. Either way the answer is the images API's (b64_json with its mime_type, the model's text, usage), recorded in usage like any request. The model is Settings → Images → Image generation: Automatic (a model that draws among the providers set up, from the catalog's image-output models), Off, or any model; a request that names none is drawn by it, and with it Off is refused saying where to set one. Subscriptions draw nothing yet. magpie mcp image is a stdio MCP server with one tool, generate_image (prompt, size, n, path, reference_images): it asks the agent for its roots, saves each image in the project (assets/ by default, a name from the prompt, never over a file, the extension of what came back — a JPEG asked for as hero.png is hero.jpg), and says where; reference images are read from the project and sent as an edit. Its requests carry the agent's own name (claude-code/… magpie-image/1) so usage says which agent drew. Library → MCP servers → Discover has it as Magpie Image, opt-in: no agent is given it until picked, since every image costs what the model charges. Checked in a sandbox HOME against real vendors: OpenRouter's gemini-3.1-flash-lite-image drew a 3:2 magpie over MCP as Claude Code and edited it from the saved file as Codex (usage: claude, codex), AIHubMix's gpt-image-1 answered /v1/images/generations with a 1024² PNG; the Settings row and picker in light and dark, the Library card and its opt-in sheet

2026-09-29 01:52:53 +08:00

mcp.go

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

2026-09-29 00:44:43 +08:00

pimcp_test.go

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

2026-09-29 00:44:43 +08:00

pimcp.go

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

2026-09-29 00:44:43 +08:00

projects_test.go

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

2026-09-28 20:01:48 +08:00

projects.go

library: a project's agents can have some of the library's skills as the project's own — under Skills, In projects takes a folder (the system's picker in the app, a typed path anywhere) and each of its skills gets agents' chips; magpie links the skill into <project>/.claude/skills for Claude Code and <project>/.agents/skills for Codex, Gemini CLI, OpenCode, Pi, Cursor and Copilot (the agents documented to read it; MiMo Code, Crush, ZCode, DeepSeek Harness and oh-my-pi aren't, so they're left out), or copies it when the project asks for copies, a copy made again whenever the library's skill changes (updates included). What it places is listed between magpie's marks in the project's .gitignore, made if there was none; taking a skill or the project away removes only what magpie placed, its lines and the folders it made once empty, and a folder of the same name that isn't magpie's is left as it is and said so. The home folder, or one whose project skills folder is an agent's own, can't be added

2026-09-28 13:34:17 +08:00

rtk_test.go

rtk: Codex isn't given an rtk older than 0.50 (LeeHom: rtk's installer didn't add its hook to Codex) — rtk has a hook for Codex (rtk hook codex in hooks.json) from 0.50.0 on; an older rtk init -g --codex only puts @RTK.md in AGENTS.md, which rewrites no command, so switching Codex on ran it and then said the hook wasn't there. With an rtk before 0.50 the Library shows Codex with "Update RTK" (需更新 RTK), its switch off, the tooltip and magpie library rtk saying to update it (brew upgrade rtk, or its installer again) first

2026-09-28 19:02:23 +08:00

rtk_upgrade_test.go

library: RTK's version is kept up to date from magpie, and what it saved is drawn day by day (这里要能够管理RTK的版本，比如给它升级，以及能够看到RTK省token的趋势) — the RTK card shows its latest release beside the installed one (read from where github.com/rtk-ai/rtk/releases/latest redirects, as RTK's install.sh does, the API as fallback; kept six hours) and, when newer, an Upgrade button that brings it up the way it was installed: brew upgrade rtk for Homebrew's (in a Cellar; Homebrew updated first), winget upgrade on Windows, cargo install --git again for cargo's, and RTK's own script again, into the same folder (RTK_INSTALL_DIR), for one it put elsewhere; when Homebrew's formula is still behind the release, that is said. Also magpie library rtk upgrade. Under the totals, a chart of what RTK saved each day (week by week past 92 days) over 30 days, 90 days or all it has recorded: each bar the commands' whole output, the part saved above what still went to the model, the range's own total beside it — from rtk gain --daily --format json (RTK 0.28 on), which carries the summary too. Tested with a fake Homebrew rtk behind its release and a fake script install, and against the real rtk 0.28.2 and its history in a sandbox magpie (GitHub says 0.50.0); the upgrade itself not run on this machine

2026-09-29 01:01:25 +08:00

rtk_upgrade.go

library: RTK's version is kept up to date from magpie, and what it saved is drawn day by day (这里要能够管理RTK的版本，比如给它升级，以及能够看到RTK省token的趋势) — the RTK card shows its latest release beside the installed one (read from where github.com/rtk-ai/rtk/releases/latest redirects, as RTK's install.sh does, the API as fallback; kept six hours) and, when newer, an Upgrade button that brings it up the way it was installed: brew upgrade rtk for Homebrew's (in a Cellar; Homebrew updated first), winget upgrade on Windows, cargo install --git again for cargo's, and RTK's own script again, into the same folder (RTK_INSTALL_DIR), for one it put elsewhere; when Homebrew's formula is still behind the release, that is said. Also magpie library rtk upgrade. Under the totals, a chart of what RTK saved each day (week by week past 92 days) over 30 days, 90 days or all it has recorded: each bar the commands' whole output, the part saved above what still went to the model, the range's own total beside it — from rtk gain --daily --format json (RTK 0.28 on), which carries the summary too. Tested with a fake Homebrew rtk behind its release and a fake script install, and against the real rtk 0.28.2 and its history in a sandbox magpie (GitHub says 0.50.0); the upgrade itself not run on this machine

2026-09-29 01:01:25 +08:00

rtk.go

library: RTK's version is kept up to date from magpie, and what it saved is drawn day by day (这里要能够管理RTK的版本，比如给它升级，以及能够看到RTK省token的趋势) — the RTK card shows its latest release beside the installed one (read from where github.com/rtk-ai/rtk/releases/latest redirects, as RTK's install.sh does, the API as fallback; kept six hours) and, when newer, an Upgrade button that brings it up the way it was installed: brew upgrade rtk for Homebrew's (in a Cellar; Homebrew updated first), winget upgrade on Windows, cargo install --git again for cargo's, and RTK's own script again, into the same folder (RTK_INSTALL_DIR), for one it put elsewhere; when Homebrew's formula is still behind the release, that is said. Also magpie library rtk upgrade. Under the totals, a chart of what RTK saved each day (week by week past 92 days) over 30 days, 90 days or all it has recorded: each bar the commands' whole output, the part saved above what still went to the model, the range's own total beside it — from rtk gain --daily --format json (RTK 0.28 on), which carries the summary too. Tested with a fake Homebrew rtk behind its release and a fake script install, and against the real rtk 0.28.2 and its history in a sandbox magpie (GitHub says 0.50.0); the upgrade itself not run on this machine

2026-09-29 01:01:25 +08:00

setup_test.go

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)

2026-09-25 14:23:56 +08:00

setup.go

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

2026-09-27 17:05:59 +08:00

shared_skills_test.go

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.

2026-09-30 02:15:47 +08:00

skillcheck_test.go

library: which skills from GitHub have changed there can be checked — Check for updates asks GitHub for the last commit to each skill's folder (one request per folder, a repository's skills together; once GitHub limits requests the rest are left unknown, each skill's trouble its own) and a changed one carries an Update available pill whose tooltip has the commit's summary and date, a click opening the changes on GitHub; Update N fetches just those. The library keeps a hash of a skill's files as fetched and, once a check finds GitHub's files to be the same, the commit they're at, so a later check needs only the API; a skill installed before this is compared by its files, the repository fetched once

2026-09-28 13:11:25 +08:00

skillcheck.go

library: which skills from GitHub have changed there can be checked — Check for updates asks GitHub for the last commit to each skill's folder (one request per folder, a repository's skills together; once GitHub limits requests the rest are left unknown, each skill's trouble its own) and a changed one carries an Update available pill whose tooltip has the commit's summary and date, a click opening the changes on GitHub; Update N fetches just those. The library keeps a hash of a skill's files as fetched and, once a check finds GitHub's files to be the same, the commit they're at, so a later check needs only the API; a skill installed before this is compared by its files, the repository fetched once

2026-09-28 13:11:25 +08:00

skills.go

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.

2026-09-30 02:15:47 +08:00

sync.go

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

2026-09-29 00:44:43 +08:00

targets.go

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

2026-09-29 00:44:43 +08:00