yetone 599d784f59 library: magpie-image runs this computer's magpie, whatever path another computer or an old install saved (#1439, dawn1095) ...

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.

2026-10-10 01:30:40 +08:00

..

screenshots

gui: let users choose installed interface and code fonts (#1007)

2026-10-06 19:32:56 +08:00

subsystems

library: magpie-image runs this computer's magpie, whatever path another computer or an old install saved (#1439, dawn1095)

2026-10-10 01:30:40 +08:00

code-standards.md

docs: the 10-08 review moves real use and GUI-in-both-engines into the code standards, adds gofmt and a Linux/Windows go vet to the checks, and adds lessons on Windows CI, telemetry disclosure, timing tests, guarantee tests, real vendor pages, CI's Go version and large commits without a body

2026-10-09 03:48:15 +08:00

contributors.md

docs: contributors.md lists lunar-me under authors reviewed with extra care (the maintainer chose not to block), with the evidence and what the extra care is

2026-10-06 04:52:27 +08:00

integrating.md

docs, site: Integrating your app or agent with magpie, at docs/integrating.md and usemagpie.ai/docs/integrate (#918, Magixyne)

2026-10-05 22:46:35 +08:00

reference.md

plugins: two plugins that sign in to one provider are both listed, each row says which serves it, and Use for picks the other (neiko on Discord)

2026-10-10 00:55:38 +08:00