yetone cb609d2cb4 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

..

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

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

proc_windows.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

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

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

usemagpie.ai, and a magpie that updates itself

2026-09-24 01:57:50 +08:00

update.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