magpie

agent

agent: the Windows-only WSL test builds again — wslList returns the names and whether wsl.exe answered, and the test took it as the names alone

2026-09-28 17:43:10 +08:00

autostart

autostart: on Windows, Open at login switched off in Task Manager's Startup apps reads as off, and switching it on in magpie switches it on there again

2026-09-27 12:53:16 +08:00

backup

agent: on Windows, Codex installed in a WSL distro is an agent of its own, codex@wsl:<distro> ("Codex · WSL Ubuntu") — the distros are listed with wsl.exe -l -q (UTF-16LE, or UTF-8 under WSL_UTF8), each asked once through proc for its $HOME, its ~/.codex, a codex on its PATH and its default route, and shown only where Codex is; its files are Codex's own reading and writing (codexIn, at a place rather than a home) through \\wsl.localhost\<distro> (\\wsl$ before that), with the catalog path written in as the distro spells it and what was there stashed under the distro's agent; the gateway written in is 127.0.0.1 when .wslconfig has networkingMode=mirrored and otherwise the Windows host by the distro's default route, with a notice that NAT needs the gateway beyond loopback and through Windows' firewall and that mirrored is the way; its requests stay counted as Codex's, and a profile key is split at its last dot for distro names like Ubuntu-24.04. Nothing runs off Windows. Kimi CLI isn't an agent magpie has yet, so there is no Kimi in WSL. Tested on a Windows box under NAT with a throwaway Alpine distro: detected (the real distros without Codex left out), a magpie model set and reset from the CLI and a test binary, the catalog read inside WSL at /root/.codex; mirrored networking tested only in unit tests

2026-09-28 17:22:30 +08:00

catalog

providers: the context window field offers its usual sizes under it, one click each — 128K, 200K, 256K, 1M — and, where models take more than they are said to, each one's own most: Codex's GPT-6 and GPT-5.6 are said to hold 272K and take 872K when asked, a size nobody remembers, so one chip sets it for every such model (#120 ). The most is read from max_context_window in the list ChatGPT gives and in Codex CLI's cache

2026-09-28 01:53:08 +08:00

claudebridge

gateway: a Grok subscription (SuperGrok, X Premium+) works like a Cursor one — magpie runs the signed-in Grok Build CLI in a home of its own (none of the user's hooks, skills, rules or MCP servers; only search_tool/use_tool, reaching magpie's MCP tools), borrowing the user's token through magpie grok-token without touching their sign-in; the add sheet has a Grok tile that signs in with grok login's device code

2026-09-24 17:35:36 +08:00

codexcat

codex: /fast works on a routing group too — a group with a ChatGPT account's GPT model in it is listed to Codex with the Fast tier, and the service_tier Codex then sends is kept through the group's routing and passed on to OpenAI's own backends (a ChatGPT account, api.openai.com) only; before, the request was rebuilt without it and Fast did nothing

2026-09-27 17:51:38 +08:00

davsync

cli: 新增 magpie webdav，在终端里开启、修改和触发 WebDAV 同步 / add magpie webdav to turn on, change and run WebDAV sync from the terminal (#127 )

2026-09-28 14:54:04 +08:00

edit

gui: the Agents and Providers pages open at once again — the Providers page worked out each agent's model and routing group again for every provider (every provider's models read again each time, Alma asked over HTTP each time), so it took 25s with many providers; now once per page. What is parsed from a file is kept until the file changes (Codex's models cache, the vendors' model lists, ~/.claude.json's account, and an agent's TOML config — Codex's can run to megabytes of trusted projects, and was parsed again for every field); and what Alma answers when magpie only shows what it is on is reused for five seconds, as its providers take most of a second each time, while a change and what it reads first still ask Alma. /api/providers 25s → 0.02s, /api/state 7s → 0.1s

2026-09-26 22:25:28 +08:00

filememo

gui: the Agents and Providers pages open at once again — the Providers page worked out each agent's model and routing group again for every provider (every provider's models read again each time, Alma asked over HTTP each time), so it took 25s with many providers; now once per page. What is parsed from a file is kept until the file changes (Codex's models cache, the vendors' model lists, ~/.claude.json's account, and an agent's TOML config — Codex's can run to megabytes of trusted projects, and was parsed again for every field); and what Alma answers when magpie only shows what it is on is reused for five seconds, as its providers take most of a second each time, while a change and what it reads first still ask Alma. /api/providers 25s → 0.02s, /api/state 7s → 0.1s

2026-09-26 22:25:28 +08:00

gateway

cursor: the Run goes to the agent API Cursor's server config names for the account — ServerConfigService/GetServerConfig on api2.cursor.sh, whose agentUrlConfig cursor-agent reads to pick agentUrl in privacy mode (which the Run always asks for) and agentnUrl otherwise — asked once a token, kept by the token's hash so another account asks again, asked afresh and the Run tried once more after a region error, and the global agentn.global.api5.cursor.sh while the config can't be had (retried after a minute), as a team served in one region only was turned away by the global API with 'This region is not yet available for your team'; Cursor's errors have words of their own, no longer Devin's: an unauthenticated or expired sign-in says to sign in to Cursor again in magpie, a region or team restriction says so plainly with a 403 and doesn't ask for a sign-in; and Cursor's expanded ids (grok-4.7-low … grok-4.7-xhigh-fast, Claude with and without thinking, gpt-5.5-extra-high) are offered as one model a family, with the efforts it really has, named as Cursor names its default without the effort and holding what the least of its variants holds, fast and thinking families of their own (GPT-5.5 is 1M, GPT-5.5 Fast isn't said to be) and a family of one kept as Cursor's id — the list saved stays Cursor's own, and the gateway turns model and effort (and Codex's Fast) back into the variant at that effort, Cursor's default for one between those it has, else the nearest, while any of Cursor's own ids still goes as it is

2026-09-28 17:14:07 +08:00

gui

fix(gui): align provider status dots on providers page (#146 )

2026-09-28 17:49:50 +08:00

library

agent: RTK isn't given to OpenCode 2 — rtk init --opencode writes a plugin shaped for OpenCode 1 (a named export, no default {id, effect|setup}), which OpenCode 2 refuses to load with 'Plugin must export a default definition with an id and an effect or setup function' (rtk-ai/rtk#4311 , still so in rtk 0.50.0); with opencode --version at 2 or later the Library shows 'Not for OpenCode 2' and won't switch it on, while a plugin already there can still be switched off and taken out (ARNO)

2026-09-28 16:36:01 +08:00

netproxy

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

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

profile

agent: on Windows, Codex installed in a WSL distro is an agent of its own, codex@wsl:<distro> ("Codex · WSL Ubuntu") — the distros are listed with wsl.exe -l -q (UTF-16LE, or UTF-8 under WSL_UTF8), each asked once through proc for its $HOME, its ~/.codex, a codex on its PATH and its default route, and shown only where Codex is; its files are Codex's own reading and writing (codexIn, at a place rather than a home) through \\wsl.localhost\<distro> (\\wsl$ before that), with the catalog path written in as the distro spells it and what was there stashed under the distro's agent; the gateway written in is 127.0.0.1 when .wslconfig has networkingMode=mirrored and otherwise the Windows host by the distro's default route, with a notice that NAT needs the gateway beyond loopback and through Windows' firewall and that mirrored is the way; its requests stay counted as Codex's, and a profile key is split at its last dot for distro names like Ubuntu-24.04. Nothing runs off Windows. Kimi CLI isn't an agent magpie has yet, so there is no Kimi in WSL. Tested on a Windows box under NAT with a throwaway Alpine distro: detected (the real distros without Codex left out), a magpie model set and reset from the CLI and a test binary, the catalog read inside WSL at /root/.codex; mirrored networking tested only in unit tests

2026-09-28 17:22:30 +08:00

provider

provider: WorkBuddy usage shows up — send a WorkBuddy User-Agent and read string capacities (workbuddy 订阅的usage能显示出来吗)

2026-09-28 17:40:12 +08:00

redact

gateway: count_tokens counts the masked prompt, and a count that cannot be had is told apart — the count Claude Code asks for before every turn went to the vendor as the conversation was written, so Mask secrets was defeated on every one; it now goes masked, the same prompt the turn it counts sends. An endpoint that doesn't implement counting (404/405/501, or a 400 that says so, in English or Chinese) falls back to the local estimate as before; a limited key or a broken connection yields to the next checked key and rests the one that failed, as a generation would, while a client's own cancellation rests nothing; and a real error — a wrong key, a prompt past the model's context, an image it won't take — reaches the agent. The gateway tests are isolated from the machine now (a temp HOME, inert stubs for the sign-in CLIs and the keychain) so a cache that outlives a test can't reach a real login, and the redaction tests' cold starts run in parallel. (#103 )

2026-09-27 18:58:23 +08:00

sessions

sessions: history by day in the CLI and the TUI — magpie sessions lists the latest Claude Code and Codex sessions (when, agent, folder, first prompt, tokens, cost; --limit, --json with the resume commands), and with --days N|today|all (stats alone is 7) prints the range's totals (tokens, list-price cost, cache read and hit rate, active time and on how many days), a line a day with its tokens, cost, cache read, active time and a bar, then the top models and folders; --model and --folder narrow either, matched exactly, by base name or by a unique part, an unknown one naming those there are. The TUI gets a sessions page after usage (5; the library is 6 now) with the ranges today, 7, 30, 90 days and all (←→, t w m A), M and f to pick a model or a folder from those the range has, x to clear them, the totals, and a chart of the days in block characters, a week a column when the days don't fit, of tokens or, with c, cost. Both sum sessions.StatsFor as GET /api/sessions/stats does, through Stats.Sum, which rolls the days up under a model and a folder as the app's view does — active time not kept by model, so none under one

2026-09-28 17:06:33 +08:00

settings

stats: magpie counts its users — once a day a running app or magpie serve sends PostHog (the Magpie project) one "magpie active" event under a random id made up on this computer (~/.config/magpie/install-id), with the version, the system and the architecture and nothing else, no person profile kept; off in Settings → Privacy → Count me as a user, or with DO_NOT_TRACK=1 or MAGPIE_NO_STATS=1, and never from a build from source; the README says what goes

2026-09-28 17:23:41 +08:00

stats

stats: magpie counts its users — once a day a running app or magpie serve sends PostHog (the Magpie project) one "magpie active" event under a random id made up on this computer (~/.config/magpie/install-id), with the version, the system and the architecture and nothing else, no person profile kept; off in Settings → Privacy → Count me as a user, or with DO_NOT_TRACK=1 or MAGPIE_NO_STATS=1, and never from a build from source; the README says what goes

2026-09-28 17:23:41 +08:00

tui

sessions: history by day in the CLI and the TUI — magpie sessions lists the latest Claude Code and Codex sessions (when, agent, folder, first prompt, tokens, cost; --limit, --json with the resume commands), and with --days N|today|all (stats alone is 7) prints the range's totals (tokens, list-price cost, cache read and hit rate, active time and on how many days), a line a day with its tokens, cost, cache read, active time and a bar, then the top models and folders; --model and --folder narrow either, matched exactly, by base name or by a unique part, an unknown one naming those there are. The TUI gets a sessions page after usage (5; the library is 6 now) with the ranges today, 7, 30, 90 days and all (←→, t w m A), M and f to pick a model or a folder from those the range has, x to clear them, the totals, and a chart of the days in block characters, a week a column when the days don't fit, of tokens or, with c, cost. Both sum sessions.StatsFor as GET /api/sessions/stats does, through Stats.Sum, which rolls the days up under a model and a folder as the app's view does — active time not kept by model, so none under one

2026-09-28 17:06:33 +08:00

update

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

usage

usage: each call is kept with the session it was part of — the X-Magpie-Session header when the caller sends one, else the session its agent names itself (Claude Code's x-claude-code-session-id, Codex's session_id, OpenCode's) — as "session" in usage.jsonl, and magpie usage lists the sessions that used the most, so several sessions on one model can be told apart

2026-09-27 23:02:36 +08:00