yetone 72c6b85b0d provider: Claude Code installed off magpie's PATH is found on Windows too, so its sign-in no longer says to install it (EZN7L2C3, #839) — claudeExecutable looked on PATH, then at ~/.local/bin/claude, /usr/local/bin/claude and /opt/homebrew/bin/claude; on Windows the installer's binary is ~/.local/bin/claude.exe, and a magpie started before Claude Code was installed hasn't its folder on PATH, so the Claude sign-in said "install Claude Code first" while the Agents page, which reads ~/.claude, listed it. proc.FindTool now finds a CLI as a terminal would: on PATH, in the folders users' tools go in (UserBinDirs: npm's, ~/.local/bin, bun's, volta's, pnpm's, …) as name.exe, name.cmd or name on Windows, then on the PATH the registry has now; the sign-in and the gateway's Claude runs both use it. TestClaudeFoundInLocalBin fails on the old code on Windows (built for windows/amd64 and run on the Windows 11 test box: claude ""), passes there and here; TestToolIn. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 07:42:57 +08:00

..

find_test.go

provider: Claude Code installed off magpie's PATH is found on Windows too, so its sign-in no longer says to install it (EZN7L2C3, #839) — claudeExecutable looked on PATH, then at ~/.local/bin/claude, /usr/local/bin/claude and /opt/homebrew/bin/claude; on Windows the installer's binary is ~/.local/bin/claude.exe, and a magpie started before Claude Code was installed hasn't its folder on PATH, so the Claude sign-in said "install Claude Code first" while the Agents page, which reads ~/.claude, listed it. proc.FindTool now finds a CLI as a terminal would: on PATH, in the folders users' tools go in (UserBinDirs: npm's, ~/.local/bin, bun's, volta's, pnpm's, …) as name.exe, name.cmd or name on Windows, then on the PATH the registry has now; the sign-in and the gateway's Claude runs both use it. TestClaudeFoundInLocalBin fails on the old code on Windows (built for windows/amd64 and run on the Windows 11 test box: claude ""), passes there and here; TestToolIn. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 07:42:57 +08:00

find.go

provider: Claude Code installed off magpie's PATH is found on Windows too, so its sign-in no longer says to install it (EZN7L2C3, #839) — claudeExecutable looked on PATH, then at ~/.local/bin/claude, /usr/local/bin/claude and /opt/homebrew/bin/claude; on Windows the installer's binary is ~/.local/bin/claude.exe, and a magpie started before Claude Code was installed hasn't its folder on PATH, so the Claude sign-in said "install Claude Code first" while the Agents page, which reads ~/.claude, listed it. proc.FindTool now finds a CLI as a terminal would: on PATH, in the folders users' tools go in (UserBinDirs: npm's, ~/.local/bin, bun's, volta's, pnpm's, …) as name.exe, name.cmd or name on Windows, then on the PATH the registry has now; the sign-in and the gateway's Claude runs both use it. TestClaudeFoundInLocalBin fails on the old code on Windows (built for windows/amd64 and run on the Windows 11 test box: claude ""), passes there and here; TestToolIn. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 07:42:57 +08:00

list_other.go

accounts: after a Codex switch, magpie says when Codex's background service is still on the account before, and restarts it when asked (vincentzhang on Discord) — Codex CLI can keep an app-server running (codex app-server --managed-daemon) that reads the sign-in once, when it starts, so sessions opened after a switch still ran on the account before. When a switch changes the account while such a daemon runs, Codex's account list shows that it is still signed in as the one before, with Later and Restart; Restart runs codex app-server daemon restart for the Codex home magpie signs in through, which ends the Codex sessions on it, so magpie never does it unasked. magpie accounts switch codex prints the same hint and the command. The notice goes when the daemon restarts or stops, or Codex is switched back. Only a codex program's app-server with --managed-daemon counts: the ChatGPT app's codex and other apps' app-servers don't. Tested with a fake codex and a fake daemon in a sandbox magpie web; the real codex 0.155 has the restart command

2026-09-29 11:59:57 +08:00

list_test.go

accounts: after a Codex switch, magpie says when Codex's background service is still on the account before, and restarts it when asked (vincentzhang on Discord) — Codex CLI can keep an app-server running (codex app-server --managed-daemon) that reads the sign-in once, when it starts, so sessions opened after a switch still ran on the account before. When a switch changes the account while such a daemon runs, Codex's account list shows that it is still signed in as the one before, with Later and Restart; Restart runs codex app-server daemon restart for the Codex home magpie signs in through, which ends the Codex sessions on it, so magpie never does it unasked. magpie accounts switch codex prints the same hint and the command. The notice goes when the daemon restarts or stops, or Codex is switched back. Only a codex program's app-server with --managed-daemon counts: the ChatGPT app's codex and other apps' app-servers don't. Tested with a fake codex and a fake daemon in a sandbox magpie web; the real codex 0.155 has the restart command

2026-09-29 11:59:57 +08:00

list_windows.go

accounts: after a Codex switch, magpie says when Codex's background service is still on the account before, and restarts it when asked (vincentzhang on Discord) — Codex CLI can keep an app-server running (codex app-server --managed-daemon) that reads the sign-in once, when it starts, so sessions opened after a switch still ran on the account before. When a switch changes the account while such a daemon runs, Codex's account list shows that it is still signed in as the one before, with Later and Restart; Restart runs codex app-server daemon restart for the Codex home magpie signs in through, which ends the Codex sessions on it, so magpie never does it unasked. magpie accounts switch codex prints the same hint and the command. The notice goes when the daemon restarts or stops, or Codex is switched back. Only a codex program's app-server with --managed-daemon counts: the ChatGPT app's codex and other apps' app-servers don't. Tested with a fake codex and a fake daemon in a sandbox magpie web; the real codex 0.155 has the restart command

2026-09-29 11:59:57 +08:00

list.go

accounts: after a Codex switch, magpie says when Codex's background service is still on the account before, and restarts it when asked (vincentzhang on Discord) — Codex CLI can keep an app-server running (codex app-server --managed-daemon) that reads the sign-in once, when it starts, so sessions opened after a switch still ran on the account before. When a switch changes the account while such a daemon runs, Codex's account list shows that it is still signed in as the one before, with Later and Restart; Restart runs codex app-server daemon restart for the Codex home magpie signs in through, which ends the Codex sessions on it, so magpie never does it unasked. magpie accounts switch codex prints the same hint and the command. The notice goes when the daemon restarts or stops, or Codex is switched back. Only a codex program's app-server with --managed-daemon counts: the ChatGPT app's codex and other apps' app-servers don't. Tested with a fake codex and a fake daemon in a sandbox magpie web; the real codex 0.155 has the restart command

2026-09-29 11:59:57 +08:00

main_test.go

Add German translation; harden paths against unset env vars (#770)

2026-10-04 23:30:56 +08:00

path_other_test.go

proc: the login-shell probe asks nushell through /bin/sh, and a value the shell printed instead of expanding counts as unset (#738: with nushell as the login shell, shellEnv's printf '…' "$PATH" "$CLAUDE_CONFIG_DIR" … came back as the text "$PATH", "$CLAUDE_CONFIG_DIR", … — a double-quoted string is literal in nushell — and setUnset exported every one of agentenv.Vars with its own name as the value; Claude sign-in then failed with "mkdir $CLAUDE_CONFIG_DIR: read-only file system" (putClaudeLogin's MkdirAll of that relative name under the GUI's cwd /), and the account lapsed minutes later as "Claude Code is no longer signed in", its sign-in looked for under that folder; Codex, Pi, omp and the rest were pointed at "$CODEX_HOME", "$PI_CODING_AGENT_DIR", "$OMP_PROFILE" the same way, in the GUI alone, which is the one caller of UserPath) — shellProbe builds the command: for a shell named nu it is ^/bin/sh -c '<the same printf>' (nushell has no POSIX quoting to ask with and its PATH is a list, while a child of it gets the environment as any child does, PATH joined back into one string, and sh expands the references; the outer string in nushell's single quotes where a backslash is a backslash, the format in sh's double quotes where \0 reaches printf), any other shell keeps the printf it had; and parseShellEnv takes a value that is the variable's own reference ("$CODEX_HOME", or "$PATH" for PATH) for unset, so a login shell with other quoting than POSIX leaves a variable alone rather than setting it to its name. TestShellEnvNushell runs the probe through a nushell on the machine (skipped where there is none) and checks the command's shape anyway; TestParseShellEnvUnexpanded feeds the unexpanded answer. Verified against nushell 0.116.0: PATH comes back, CODEX_HOME from the environment reaches sh, unset variables are "". (#739)

2026-10-04 11:13:50 +08:00

path_other.go

Add German translation; harden paths against unset env vars (#770)

2026-10-04 23:30:56 +08:00

path_windows.go

Add German translation; harden paths against unset env vars (#770)

2026-10-04 23:30:56 +08:00

probe_other.go

fix(proc): end what a CLI probe started, on its timeout and when magpie exits (#414)

2026-10-02 00:42:48 +08:00

probe_test.go

fix(proc): end what a CLI probe started, on its timeout and when magpie exits (#414)

2026-10-02 00:42:48 +08:00

probe_windows.go

fix(proc): end what a CLI probe started, on its timeout and when magpie exits (#414)

2026-10-02 00:42:48 +08:00

probe.go

fix(proc): end what a CLI probe started, on its timeout and when magpie exits (#414)

2026-10-02 00:42:48 +08:00

proc_other.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_test.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_test.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

proc.go

accounts: a slow or hanging agent CLI no longer holds the providers page (#123) — its timeout now ends the call (a CLI that is a script running node left node holding the output, and the call waited for it however long, the 10s timeouts notwithstanding: a CLI's pipes are closed 2s after); a CLI never answered before is waited for 3s, once, then served as nobody signed in until its answer comes behind; and a CLI saying nobody is signed in is kept like any answer, where before it wasn't and every start waited for it again. Tried with cursor-agent and devin hanging 20s and the network black-holed: the first providers call went from 40.6s to 6s on a first start, and to 13ms on the next

2026-09-28 11:20:14 +08:00

tree_other_test.go

grok, cursor: a run ends with its caller — one whose client left mid-reply (Esc, /clear, Claude Code quit) is stopped at once instead of answering no one, one waiting on tool results that never come is let go after 5 minutes, not 30, and a stop kills what the CLI started too (its own session on Mac and Linux, a job on Windows). A tool that runs longer still gets its answer, from a run told the whole conversation. Runs are stopped with the gateway

2026-09-27 17:42:01 +08:00

tree_other.go

grok, cursor: a run ends with its caller — one whose client left mid-reply (Esc, /clear, Claude Code quit) is stopped at once instead of answering no one, one waiting on tool results that never come is let go after 5 minutes, not 30, and a stop kills what the CLI started too (its own session on Mac and Linux, a job on Windows). A tool that runs longer still gets its answer, from a run told the whole conversation. Runs are stopped with the gateway

2026-09-27 17:42:01 +08:00

tree_windows.go

grok, cursor: a run ends with its caller — one whose client left mid-reply (Esc, /clear, Claude Code quit) is stopped at once instead of answering no one, one waiting on tool results that never come is let go after 5 minutes, not 30, and a stop kills what the CLI started too (its own session on Mac and Linux, a job on Windows). A tool that runs longer still gets its answer, from a run told the whole conversation. Runs are stopped with the gateway

2026-09-27 17:42:01 +08:00

tree.go

grok, cursor: a run ends with its caller — one whose client left mid-reply (Esc, /clear, Claude Code quit) is stopped at once instead of answering no one, one waiting on tool results that never come is let go after 5 minutes, not 30, and a stop kills what the CLI started too (its own session on Mac and Linux, a job on Windows). A tool that runs longer still gets its answer, from a run told the whole conversation. Runs are stopped with the gateway

2026-09-27 17:42:01 +08:00

wait_test.go

accounts: a slow or hanging agent CLI no longer holds the providers page (#123) — its timeout now ends the call (a CLI that is a script running node left node holding the output, and the call waited for it however long, the 10s timeouts notwithstanding: a CLI's pipes are closed 2s after); a CLI never answered before is waited for 3s, once, then served as nobody signed in until its answer comes behind; and a CLI saying nobody is signed in is kept like any answer, where before it wasn't and every start waited for it again. Tried with cursor-agent and devin hanging 20s and the network black-holed: the first providers call went from 40.6s to 6s on a first start, and to 13ms on the next

2026-09-28 11:20:14 +08:00