Codex's install.ps1 puts %LOCALAPPDATA%\Programs\OpenAI\Codex\bin on PATH.
That folder is a junction to ~\.codex\packages\standalone\current\bin, and
current is a junction to releases\<version>-<target>, retargeted by each
update. filepath.EvalSymlinks leaves junctions alone since Go 1.23, so
magpie saw the binary only as ...\Programs\OpenAI\Codex\bin\codex.exe:
- howInstalled didn't find .codex/packages/standalone in its path, so the
Agents page showed the version with no newest version and no update.
- installedVersion's stamp was that unchanged path plus size and mtime.
npm's archive, which install.ps1's legacy layout copies from, gives every
version's codex.exe the same 1985 mtime. So a new release was asked again
only if its size happened to differ, else after the 24h memo.
proc.RealPath is now the path Windows opens (GetFinalPathNameByHandle),
junctions followed, and filepath.EvalSymlinks elsewhere. cliupdate's
howInstalled and installedVersion and proc.Version use it.
TestCodexInstallPs1Junctions (Windows) builds install.ps1's layout with
mklink /J, two releases whose codex.exe have the same bytes and mtime. It
checks that codex is recognized as self-updated (codex update) and that
retargeting current makes the version asked again. On the Windows box
(10.0.0.132, sandboxed USERPROFILE/APPDATA/LOCALAPPDATA) it fails on the old
code (howInstalled nil; "0.161.0" after the update) and passes on the new.
The rest of the agent package fails on Windows with the same 17 tests
before and after (TestFolderVarsAreListed, TestAside*, TestVSCodium, ...),
which CI never runs there. `codex update` on Windows is in codex.exe 0.162.0
(win32-x64): it runs install.ps1. The layout was read from
https://chatgpt.com/codex/install.ps1.
Not tried with a real install.ps1 install (it rewrites the user's PATH in
the registry). go test -tags nogui ./internal/agent ./internal/proc
./internal/provider ./internal/library (macOS), gofmt, and go vet for
GOOS=linux and windows pass.
An old ~/.local/bin/cursor-agent that runs `cursor agent`, which (Cursor's
own bin/cursor) first runs ~/.local/bin/cursor-agent --min-version=... status,
calls itself without end. magpie asks cursor-agent who is signed in (about,
10s timeout) and kills the probe's session on the timeout with one SIGKILL
to the group. On macOS that one signal can miss a process being forked as it
goes out; the miss lives on, in the same group, adopted by init, and keeps
calling itself until the user can start no process (JJ-Lin: ~4800 bash
processes in one chain whose root's parent is PID 1). group.kill now sends
SIGKILL to the group again every 5ms, behind the caller, until the group is
gone (ESRCH) or 10s pass. The group keeps its id while any of it lives, so
nothing else is signalled. It covers ProbeContext's timeout and EndProbes,
and StartTree's Kill and sweep.
Verified:
- red without the change: TestProbeKillEndsWhatTheSignalMissed (the first
group signal is made to miss, as the race does) fails with
"what the probe started (pid 95576) outlived a kill that missed it once";
passes with it (-count=5).
- reproduced the leak with the real Cursor 3.12.6 launcher script
(/Applications/Cursor.app/.../bin/cursor, read only) and JJ-Lin's 87-byte
wrapper in a sandbox HOME, under ulimit -u: ProbeContext(cursor-agent about)
with a 10s timeout peaked at 311-700 processes; before the change 1 of 3
runs left a chain behind (root ppid 1, same pgid, args
"agent --min-version=2025.10.01 status"), after it 0 of 6. A fake
launcher (60 parallel self-calling chains, killed at 500ms) left survivors
4 of 30 runs before, 0 of 30 after.
- the same through provider.askCursorStatus with the real launcher, 5 runs:
no cursor process left after each.
- go test -tags nogui ./internal/proc/ in a sandbox HOME; go vet -tags nogui
of proc for darwin, linux and windows.
Windows starts a batch file as `cmd.exe /c <line>`, and Go builds that
line for a program's parser: with more than two quotes cmd.exe drops the
first and last, so `"C:\Program Files\nodejs\npm.cmd" install -g --prefix
"C:\Program Files\nodejs" …` ran C:\Program. An argument with & or | was
also left unquoted and split into a second command. Every command magpie
runs is made by proc.Command/CommandContext, so the fix is there:
cmd.exe /d /e:ON /v:OFF /s /c "<script> <args>", each argument quoted as
Rust's std does for batch files (doubled ", % broken up).
TestBatchFileInFolderWithSpace (windows) runs npm.cmd, a .bat and npm via
PATH under "Program Files" with the reporter's arguments plus & | % ^ and
trailing-\ cases, through a script that hands %* to a real program. On the
old code it fails on the Windows box with "'…\Program' 不是内部或外部命令".
On the Windows box (Windows 11, zh-CN) magpie's own updater
(howInstalled + runUpdate) on a real npm install of Claude Code 2.0.50
under "…\Program Files\nodejs": old code failed with the reporter's error,
new code updated it to 2.1.293.
bbf99143's test called syscall.Getsid, which Go's syscall package has on
macOS and the BSDs but not on Linux: go vet ./... (and every test run) on
Linux stopped at "undefined: syscall.Getsid", so the ubuntu Test job failed
at Vet on main and on every PR. golang.org/x/sys/unix, already required,
has Getsid on every Unix.
Verified: GOOS=linux, darwin, freebsd and android go vet ./internal/proc;
go test -run TestAskShellOwnSession ./internal/proc on macOS. Linux is run
by this PR's ubuntu job; there is no Linux machine here.
askShell ran `$SHELL -ilc` (and ReadCLI's zsh, bash and fish, for Settings › Command line; LoginPath for Library › RTK) in magpie's own session and process group. An interactive zsh puts itself in the terminal's foreground, so while it ran, magpie's group was in the background of the terminal it was started from: Ctrl-C no longer reached `magpie web`, and anything left in magpie's group that touched the terminal — the bash asked beside it, whose profile runs in magpie's group without job control, or another child — had the kernel send SIGTTIN to the whole group, stopping magpie ("zsh: suspended (tty input)"). Run with `&`, the user's own shell then got EIO reading the terminal and exited. A timeout also killed only the shell, leaving what its profile started holding the terminal.
The shell is now a probe (ProbeContext): it leads a session with no controlling terminal, and its timeout and EndProbes end its whole group. It still answers with its PATH and variables.
TestAskShellOwnSession (a fake shell answering with its process group; a real zsh still gives a PATH) fails without the change: "the login shell ran in magpie's process group …". Reproduced on a pty under an interactive zsh -f, temp HOME, MAGPIE_ADDR 127.0.0.1:47811, magpie web on 47812, ~/.zshrc `sleep 2`, ~/.bash_profile reading /dev/tty, GET /api/cli: the old build prints "zsh: suspended (tty input) magpie web" in the foreground and "[1] + suspended (tty input)" with `&` (then "zsh: error on TTY read"); with a plain profile it loses the foreground (ps S+ → S). The fixed build stays S+ / running in both, and /api/cli still says zsh and bash are known. go vet -tags nogui ./..., GOOS=linux go build -tags nogui, GOOS=windows go build, and go test -tags nogui of internal/proc, internal/update, internal/library and internal/gui under a temp HOME pass; -race -count=10 of the new test passes. Not tried with DD's own profile, or on Linux.
macOS checks a newly written executable before its first exec: 0.27s
alone, 2-5s while other new programs start (a go test ./... starting its
test binaries). The same file again takes 0.009s, and the pass is kept
across a rename and an in-place rewrite. 108852b4 worked round this for one
test with /bin/sh -c; the class was every test that writes a `#!/bin/sh`
fake and times its answer.
testenv.Program(t, path, script) replaces os.WriteFile(path, script, 0o755)
for fakes. On macOS it renames a file that has run once from a pool to path
and writes the script into it in place; at the test's cleanup the file goes
back to the pool (only a path the test created; a stand-in it wrote over
stays). Fakes still end with their tests: nothing about how they are
started or waited on changed. Run (and gateway's TestMain) remove the pool
at the end. TestMain's PATH stand-ins are run once in the background
(testenv.StandIns). Other systems write the file as before.
Converted every `#!/bin/sh` fake written by tests under internal/ (agent,
gateway, gui, library, plugin, proc, provider, update). Windows, binary
and node/bun fakes are unchanged.
Under the same load (3 loops each starting 8 freshly written scripts at a
time), 4 rounds each, before (108852b4 / origin/main) vs after:
- provider TestSavedButSignedOutClaudeServed: 4/4 fail (8.01s) -> 4/4 pass
- provider TestClaudeSignInOverStaleCredentials: 4/4 fail (5.00s) -> 4/4 pass
- provider TestDevinSignedInOnlyInMagpie: 3/4 fail ("CLI's own []") -> 4/4 pass
- gateway TestClaudeRunEndsWhenTheClientLeaves: 4/4 fail -> 4/4 pass
(and 3/3 fail -> 3/3 pass at a third of that load)
- gateway TestClientGoneRecordedAsCanceled: 4/4 fail -> 4/4 pass
- gui TestProvidersAnswerWhileListsComeIn ("cursor found false" at 3.03s):
4/4 fail -> 4/4 pass. The same class, not bfe8bcaf's test order.
- proc TestUserPath (login shell's PATH never came, 7.01s): 4/4 fail ->
4/4 pass
Unloaded, every touched package passes; no pool directory or process is
left after a run.
An update moves the running exe aside to exe.old, and when that name is still
held to exe.old-2, -3 (internal/update/update.go, oldName; two of the Windows
install tests assert .old-2 is where the running exe ended up). IsMagpie stripped
".old" and then ".exe", in that order, which unwraps exe.old but not exe.old-2:
".old" is not a suffix of "magpie.exe.old-2", so nothing came off and the name
matched neither magpie nor dial.
So the Gateway card's "Quit magpie and take over" refused to end the user's own
magpie: quitMagpieOnPort takes the "not-magpie" reason and the window says
"which isn't magpie, so magpie leaves it alone", with no way to end it from
there. startHere reads the same function, so it also misreports a magpie that
took the port back as something else.
The tail is now recognised as the count an update appends. Another program's
own name is still left alone: ".old-2" without a number is not ours, and
"magpie.old-backup" is not an update's.
Unchanged: every name IsMagpie already accepted, and the rule that only magpie's
own programs are ended — nothing else is ever touched.
TestIsMagpie's four new paths fail without the change (magpie.exe.old-2,
magpie.exe.old-3, magpie.old-2, dial.old-4 all read as not magpie) and pass
with it; the two negatives are checked in the same table. go vet ./... and the
builds for darwin, GOOS=linux and GOOS=windows pass, and internal/proc passes
-race -count=20.
An old magpie (v0.1.552) running in OrbStack held 3425, forwarded on the
Mac by OrbStack Helper. The Gateway card's take-over named OrbStack Helper
as a program that isn't magpie and said to move the gateway to another
port in Settings, and Settings refused the move because another magpie
served the gateway, so there was no way out. proc.IsForwarder tells the
programs that hold a port for a container or a VM (OrbStack, Docker
Desktop, docker-proxy, vpnkit, gvproxy, Lima, WSL's relay); the take-over
then answers reason container, said as the magpie inside it to stop (docker
ps, docker stop, or OrbStack / Docker Desktop) or this magpie's port to
move. setPort refuses only when a magpie program of this user's listens on
the port (magpieOnPort): one in a container, or one this user can't see,
is left on its port and this magpie serves on the new one, the agents it
connected moved with it. The take-over/restart button is text action, a
bordered button, as a plain text button read as words on the dark card.
TestGatewayHeldByAContainer runs a copy of the test binary named OrbStack
Helper answering as magpie on a port of the test's own: the take-over says
container and leaves it running, and setPort moves the gateway to a new
port where it answers as this one's; a copy named magpie still has its
port set there. TestIsForwarder covers the names. gateway-takeover.test.cjs
checks the container message in English and Chinese and the button's
border in dark mode. Both fail without the change. go vet, go build
(GOOS=linux nogui, GOOS=windows) and go test -tags nogui ./... under a temp
HOME pass.
* Add German translation and harden paths against unset env vars
Add a German locale to the GUI, tray menu, usage alerts and website home page, and refuse to start when the home folder is unset or relative so nothing is written under the working folder; the pi plugin no longer adopts the user's PI_CODING_AGENT_DIR, and an inherited APPIMAGE no longer selects portable mode. Scripts refuse to run from the wrong folder or empty a shared out folder, and a new internal/testenv sandboxes every test package from the user's real files, which also fixes the Claude picker and Termux installer tests on Windows.
* Makefile: know magpie's folder by its go.mod, so paths with spaces work
The check compared $(CURDIR) with $(dir $(abspath …)), which make splits on spaces, so a checkout under 'My Projects' or 'John Doe' refused every target. It now reads go.mod relative to the working folder and wants magpie's module there: make -C and a symlinked Makefile work, make -f from another folder still stops before any recipe runs.
* i18n: German for the strings main added since, with a parity test
75 strings main added (group order, patterns, slow-start wait, usage caps, RTK savings …) get their German, and two that main dropped go. gui-de.test.cjs checks, as gui-ja does, that de has every zh string with its placeholders and tags, and that the window reads in German when picked or on a German system.
* appdir: ignore relative folder variables when reading, keep them for children
CheckEnv no longer unsets anything. magpie reads the XDG folders, APPDATA/LOCALAPPDATA and every agent's folder variable through appdir.Getenv/LookupEnv, which pass over a relative value; the environment stays as it is, so the agents magpie starts get the variable as the user set it. That covers what proc.UserPath lends from the login shell too, which is set after main's check and reached the desktop app unchecked. On Windows a path rooted on the current drive (\Users\x, Git Bash's /c/x) counts as usable, and magpie version and help answer without a home, before run makes any folder.
* Sandbox the tests main added since
internal/wslrun gets testenv's TestMain, and four tests main added that set HOME alone set their home with testenv.SetHome, so on Windows they don't read the runner's profile through USERPROFILE.
* agentenv: PI_CONFIG_DIR and OPENCODE_DB take relative names on purpose
omp puts $PI_CONFIG_DIR under the home and OpenCode a relative $OPENCODE_DB in its data folder, so neither depends on the working folder: appdir no longer passes them over.
* i18n: German for the Library's multi-select and System One's decision API
The 19 strings main added since (#791's skill multi-select, the decision API snippets) get their German; the one main replaced (four APIs → five APIs) goes.
* appdir: tidy the import into magpie's group; say what Go makes of /c/x
The appdir import joins the group of magpie's own imports where a file has one. rooted's comment now says that Go takes a Git Bash path like /c/x as \c\x on the current drive, not C:\x.
* fix(proc): end what a CLI probe started, on its timeout and when magpie exits
The probes that ask an agent's CLI something (claude auth status,
cursor-agent about/models/status, the --version checks) ran through
proc.CommandContext, which on its timeout kills only the command itself.
A CLI that is a script (a version manager's wrapper, a shim) left what it
had started running, adopted by init; and a probe still asking when magpie
exited (a one-shot command, an update, a restart) was left whole, with
nothing to end it. With Omarchy's mise wrappers stuck in their exec loop
(omacom/omarchy#7234) that was five processes holding about half a core
each for up to six hours.
proc.ProbeContext gives such a probe a session of its own on Unix, as
StartTree does, and its context ending kills the whole group. Probes still
running are listed, and proc.EndProbes kills them when magpie exits (after
run in main) or puts a new version in its place (update.Reexec). On
Windows a probe is killed alone, as before, a job being joined only once
the command has started.
TestProbeTimeoutEndsWhatItStarted and TestEndProbes fail without the
change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(proc): end probes on a terminal's signals and on a Mac's quit
Review of the first change: a probe leading its own session no longer
gets the Ctrl+C, hang-up or SIGTERM sent to magpie's terminal or service,
and magpie ending on the signal never reached EndProbes, so the probe was
left to init where before it died with magpie. main now catches SIGINT,
SIGTERM and SIGHUP, ends the probes and exits as the signal would have
(128+n). A signal magpie was started ignoring (nohup, a background job)
stays ignored. The account sign-in and plugin commands, which end
themselves on Ctrl+C, go through interruptContext and are left to do so.
On a Mac the desktop app's quit ([NSApp terminate:], also the restart to
update) exits without returning to main, so OnShutdown ends the probes.
TestProbeTimeoutEndsWhatItStarted ended its probe on a 500ms timeout,
which on a Mac could come before the script had written its child's pid
(6 of 10 runs failed in review). It now ends the context once that pid is
read, the same Cancel path.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix: let the app and the TUI quit on a signal their own way
Review of the signal handling: endProbesOnSignal exited ahead of Wails
and bubbletea, which quit on SIGINT and SIGTERM themselves. `magpie tray`
exited 143 without OnShutdown (no downloaded update installed, and
sessions.Saved skipped in main), and `magpie tui` left the terminal on its
alternate screen with the cursor hidden. The app's and the TUI's entry
points now hand the signals back (ownSignals): the app's OnShutdown ends
the probes, and the TUI comes back to main, which ends them too. A
one-shot command keeps the handler.
TestOwnSignalsHandsThemBack fails without the change (magpie exited 143
before the command could quit its own way); TestSignalExits keeps the
one-shot behavior.
childPid waited 3s for a script just written to start its child, which a
busy Mac can exceed (2 of 3 full runs failed in review). It waits 30s now
and, should the probe end first, says the probe's error rather than "the
script started nothing".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix: keep SIGHUP for the app and the TUI, and die of the signal
ownSignals handed SIGHUP back along with SIGINT and SIGTERM, but neither
Wails nor bubbletea handles it: the terminal closing under the TUI or an
app started from a shell ended magpie on the spot, and its probes, in a
session of their own, out of the hang-up's reach, kept running (before
this PR they were in the terminal's group and ended with it). SIGHUP now
stays with endProbesOnSignal. A tray under a pty whose terminal closes
left 2 processes before, none now.
The handler asked whether a command was ending itself on Ctrl+C only
after EndProbes, which can take up to a second; a sign-in done in the
meantime got magpie ended in the middle of its own cleanup. It is asked
first.
It exited 128+n, which a shell takes for a child that handled the signal:
a loop running magpie went on to the next run on Ctrl+C. It now dies of
the signal (handling reset, the signal sent again); Windows, which can't
send one, still exits with the code.
agentProbe and agentCommand share withProxy; the Windows probeGroup
comment no longer says EndProbes ends what a shim started.
TestOwnSignalsKeepsHangUp and TestInterruptWhileEndingProbes fail without
the change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix: hand signals to the TUI and the app only once they listen
Review: runTUI handed SIGINT and SIGTERM back before tui.Run, whose
newModel asks agents' CLIs (claude auth status, up to 5s) before
bubbletea listens for signals. Ctrl+C, SIGTERM or SIGINT while it loaded
ended magpie by Go's default and left the probe and its child running.
tui.Run now takes ready, called once the model is made, and runTUI passes
ownSignals.
The app had the same window: runGUI handed them back before gui.Run,
which starts the backend (probes included) before Wails' Run starts
listening. ownSignals is now gui.Started, called on ApplicationStarted,
which Wails emits after its signal handler is set up. A tray sent SIGTERM
0.05s after starting, a probe under way, left 2 processes before and
none now; one sent it once started still quits through OnShutdown
(exit 0).
TestTUIKeepsSignalsWhileLoading fails without the change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
yetone