yetone 831df8579e update: a restart to update from the open window (Windows, Linux) opens the window again, on the tab it was asked from, instead of the tray icon alone (#275 Aimer779: 设置页更新重启后主窗口消失，只剩托盘) — RelaunchBinary always started magpie tray, autostart's argument, so the new version came up as a tray icon however the update was asked for; the Mac reopens its .app and was fine. The window's Update pill and Settings' "Restart to update" send the tab they're on, the new process starts as magpie gui <tab>; the tray menu's Restart to Update brings the window back if it was open and keeps to the tray if not; autostart stays tray. magpie gui <tab> / magpie app <tab> open the window on that tab, and hand it to a magpie already running. The MAGPIE_REPLACES handover is unchanged: the new process waits for the old one before its single-instance lock. Tested with TestRelaunchArgs and TestRelaunchBinaryArgs (a script in magpie's place is started with gui settings <pid> / tray <pid>); go vet, go build (GUI and -tags nogui, GOOS=linux, GOOS=windows), go test -tags nogui ./... pass. Not tried: a real restart to update on Windows or Linux.

2026-09-30 12:33:36 +08:00

..

admin_test.go

update: Update updates magpie in place — a click downloads the new version and restarts into it, asking for the password when magpie can't replace itself, instead of opening the release page; only a magpie running from its disk image or a temporary copy is sent to the download page, with why

2026-09-25 01:35:24 +08:00

admin.go

windows: the desktop app no longer opens a console window for every command it runs (#54) — it is linked as a GUI program and has no console, so each console CLI it started (devin auth status and models list, devin acp for every Devin turn, claude, codex, cursor-agent and grok probes and runs, grok login) was given a new console by Windows, and a Windows Terminal window with it, some every few seconds while the app sat idle. Every command magpie runs is now made through internal/proc, which starts it with CREATE_NO_WINDOW when magpie has no console of its own: the child gets a console without a window, and its output, which magpie always pipes back, arrives as before. A magpie run in a terminal (magpie serve, the TUI, the desktop app started from one with a command) has one, and its children share it as they did, so Ctrl+C there still reaches them. The relaunch after an update keeps its DETACHED_PROCESS, added to rather than replacing the flags it was made with, and a test fails on any command made with os/exec directly, so a new one can't bring the windows back

2026-09-25 14:04:44 +08:00

download_test.go

update: the download shows how far along it is — percent and megabytes in Settings — a dropped connection is tried twice more, and a failure says why instead of only that it failed (#21)

2026-09-24 15:07:35 +08:00

install_windows_test.go

update: on Windows an update goes in while what the last one moved aside still runs — a magpie serve started before an update runs from magpie.exe.old, which then can't be removed, and moving the running exe onto it failed with "Access is denied"; it now goes beside it (magpie.exe.old-2…), the leftovers are removed once free, the download is kept for another try, and the Update button says Update failed (the error in its tooltip) instead of seeming to do nothing. Reproduced on Windows 11 with a running .old: the old swap fails, the new one passes

2026-09-26 01:38:37 +08:00

proc_unix.go

web: magpie web knows its version and updates itself as the app does — the badge's restart puts the new version in and runs it in the old one's place with the same arguments and key, so the open page reloads onto it (#111); routing: a gateway served by magpie serve, which has no window, is told apart from another magpie's window, and the routing view says to stop it so this magpie serves the gateway and shows routing live (#110)

2026-09-27 19:39:45 +08:00

proc_windows.go

web: magpie web knows its version and updates itself as the app does — the badge's restart puts the new version in and runs it in the old one's place with the same arguments and key, so the open page reloads onto it (#111); routing: a gateway served by magpie serve, which has no window, is told apart from another magpie's window, and the routing view says to stop it so this magpie serves the gateway and shows routing live (#110)

2026-09-27 19:39:45 +08:00

readonly_darwin.go

update: Update updates magpie in place — a click downloads the new version and restarts into it, asking for the password when magpie can't replace itself, instead of opening the release page; only a magpie running from its disk image or a temporary copy is sent to the download page, with why

2026-09-25 01:35:24 +08:00

readonly_other.go

update: Update updates magpie in place — a click downloads the new version and restarts into it, asking for the password when magpie can't replace itself, instead of opening the release page; only a magpie running from its disk image or a temporary copy is sent to the download page, with why

2026-09-25 01:35:24 +08:00

relaunch_args_test.go

update: a restart to update from the open window (Windows, Linux) opens the window again, on the tab it was asked from, instead of the tray icon alone (#275 Aimer779: 设置页更新重启后主窗口消失，只剩托盘) — RelaunchBinary always started magpie tray, autostart's argument, so the new version came up as a tray icon however the update was asked for; the Mac reopens its .app and was fine. The window's Update pill and Settings' "Restart to update" send the tab they're on, the new process starts as magpie gui <tab>; the tray menu's Restart to Update brings the window back if it was open and keeps to the tray if not; autostart stays tray. magpie gui <tab> / magpie app <tab> open the window on that tab, and hand it to a magpie already running. The MAGPIE_REPLACES handover is unchanged: the new process waits for the old one before its single-instance lock. Tested with TestRelaunchArgs and TestRelaunchBinaryArgs (a script in magpie's place is started with gui settings <pid> / tray <pid>); go vet, go build (GUI and -tags nogui, GOOS=linux, GOOS=windows), go test -tags nogui ./... pass. Not tried: a real restart to update on Windows or Linux.

2026-09-30 12:33:36 +08:00

replaced_test.go

update: after an update on Windows one magpie is left, not two — a magpie running when another updated the binary (it runs on from magpie.exe.old) no longer downloads the update again to magpie.exe.new and swaps it in when it quits; it says a restart is all that is left. A magpie.exe.new that is magpie.exe over again is removed at start. The tray that found the gateway taken serves it once the magpie that had it is gone, checked every 15 s

2026-09-26 14:30:16 +08:00

update_test.go

update: magpie update in a Homebrew install (brew install magpie, from the new tap in magpie-releases) says to brew upgrade magpie instead of replacing the binary in brew's Cellar, which would leave brew thinking the old version is there

2026-09-26 20:50:26 +08:00

update.go

update: a restart to update from the open window (Windows, Linux) opens the window again, on the tab it was asked from, instead of the tray icon alone (#275 Aimer779: 设置页更新重启后主窗口消失，只剩托盘) — RelaunchBinary always started magpie tray, autostart's argument, so the new version came up as a tray icon however the update was asked for; the Mac reopens its .app and was fine. The window's Update pill and Settings' "Restart to update" send the tab they're on, the new process starts as magpie gui <tab>; the tray menu's Restart to Update brings the window back if it was open and keeps to the tray if not; autostart stays tray. magpie gui <tab> / magpie app <tab> open the window on that tab, and hand it to a magpie already running. The MAGPIE_REPLACES handover is unchanged: the new process waits for the old one before its single-instance lock. Tested with TestRelaunchArgs and TestRelaunchBinaryArgs (a script in magpie's place is started with gui settings <pid> / tray <pid>); go vet, go build (GUI and -tags nogui, GOOS=linux, GOOS=windows), go test -tags nogui ./... pass. Not tried: a real restart to update on Windows or Linux.

2026-09-30 12:33:36 +08:00