magpie-image was kept in library.json with one computer's magpie by full
path (os.Executable at install). A WebDAV sync carried
C:\Users\...\Downloads\magpie-windows-amd64.exe to a Mac (and a Mac's app
to Windows), and a magpie moved out of Downloads left its old path behind:
the Library page said it couldn't start, and agents were given a program
that isn't there.
- heal (self_here.go): a server that is magpie's own -- `mcp ...` run by a
program named magpie (magpie, magpie.exe, magpie-<os>-<arch>[.exe]) --
whose program isn't an existing absolute path here is pointed at this
magpie, as the library is read (load) and after every change (so a
bundle Put from another computer is healed before it is written into
the agents). Every agent writer, project MCP files, the WSL side and
CheckServers read through load, so all of them get it. A magpie program
that does exist here (another build) and any server run by another
program are left as they are.
- Collect carries magpie's own server as plain "magpie": two computers
with the same library carry the same bundle, so davsync's library hash
matches and a sync doesn't write one's path over the other's.
- The path given is update.Program (exported cliProgram): the AppImage
rather than its mount, Homebrew's opt link rather than the Cellar.
- TestWSLMagpieImage now says which magpie this (simulated Windows)
computer runs.
Verified:
- New tests: TestOwnServerFromElsewhereRunsThisMagpie (Windows path read
on macOS, a Mac path, an exe moved out of Downloads, a bare "magpie"),
TestUsersOwnServerStaysAsItIs, TestCarriedOwnServerIsEachComputersMagpie.
Broken by hand five ways (heal off; no heal in change; no marker in
Collect; ownServer matching every server; existing magpie builds not
kept) -- each went red with a FAIL naming the behaviour, green restored.
- gofmt -l clean; go vet -tags nogui ./...; GOOS=linux and GOOS=windows
go vet (library, update, davsync); go build, GOOS=linux -tags nogui and
GOOS=windows builds; go test -tags nogui ./... green in a sandbox HOME.
- Sandbox app (own HOME, ports 3561/3562) seeded with a library.json
holding the reporter's Windows path for magpie-image plus a user's own
missing Windows tool: on start library.json, Codex's config.toml and
Claude Code's .claude.json got the running binary; /api/library/mcp/check
answered magpie-image ok with 3 tools, the user's server unchanged and
notfound.
Not verified: on the Windows box, or a real two-computer WebDAV sync.
Add to PATH put the portable download's folder first in the user's PATH, but a terminal looks for magpie by that name only, so the command was never found. cliPlace now writes magpie.cmd beside a program not named magpie.exe: it runs %~dp0<the program's name> %*, which an update keeps, since it replaces the program where it is under its name. ReadCLI reads that magpie.cmd as this app (shimRuns), and the GUI says, in Add's tooltip, the row and the status, that magpie.cmd runs magpie-windows-amd64.exe. Going through cmd also makes PowerShell wait for the GUI-linked program and gives it the console. TestCLIShim and cli-path.test.cjs's new case fail without the change.
yetone