magpie

access

gateway: a gateway key can be held to some accounts (#905 , LCorleone) — a key could burn any account a provider had: two coding plans of one vendor, and a key given to someone had them both. A key now keeps an optional list of accounts and keys (caller-keys.json "accounts", none = every account, so older files read as before): "<provider>/<account>", an account by its stable id — the login's, set once it is written and kept through renames (logins.json's savedLogin id, written by every write and stood in for by one made of the name until then, so an entry made before stands), a key by its fingerprint — every one a provider has when the list is set, and one gone later (a key rotated, an account signed out) kept as it is, matching nothing, holding the key closer, never wider. The command line and the menu name an account by who is signed in and keep its id. Routing holds a plan to the key's accounts beside its models: a candidate whose account the key may not use is left out — through a routing group the key names no less, for naming a group is not naming its accounts — the plan's order keeping step and its left-out list marking what the key held out (Weighed's held); magpie's own calls for the key — a web search, a picture described, a Codex title — are of the models the user picked, so the models don't hold them, but their spend lands on an account all the same, and the accounts hold them too. When every account or key a model has is one the key may not use, the request is refused with a 403 in the API's own error shape naming the model and the accounts the key may use, logged as a rejected call: after a usage cap's 429 and before an account barred for the model's, itself before the no-member 404. /v1/models and the Anthropic and Gemini lists show the key only the models an account or key it may use serves (a provider's account set not to serve one, #474 , is none of the key's); a provider with no account and no key (a local ollama) is one the key names no account of — its models stay listed and its asks pass — while an entry kept after its provider lost its last account or key serves none, holding the key closer. The embeddings, images and videos endpoints hold their candidate to the key's accounts the same way, and counting tokens counts on those alone (the local estimate where it may use none). System One asks its decision model of an account or key the key may use — and sends on that key, of those in use, not the provider's first, which a key held to a later one was spent on; the videos and images keyed paths send on one the key may use too, held to a later key no longer refused for the first alone. Set it in the app's menu the models are picked in — the accounts after the models, an account by who is signed in with their plan in the note, a key by its fingerprint, what the CLI kept that no provider has now kept as "Not signed in now" — or magpie gateway-key accounts <id> codex/me@example.com openai/<key id> (all takes it off); gateway-key list has an ACCOUNTS column. en/zh/ja/de, the German "{n} accounts" main already had left to it rather than written twice. The images API's fan-out over a subscription's accounts is held to the key's accounts as one: one of the key's whose plan refuses to draw no longer hands the pen to an account it may not use, and the second in the order, when it is the key's, draws what the first may not (drawOnAccounts filters the candidates, the account pinned to with the account header told plainly when the key may not use it). The Routing view's left-out list says an account the key held out for what it is, not that its plan lacks the model, in Chinese, Japanese and German too; the key's badge names its accounts by who is signed in, not by the stable ids it keeps. (#932 )

2026-10-06 10:51:50 +08:00

agent

agent test: OpenHanako's magpie provider names relay/glm-4.6 GLM-4.6, as the catalog names it — e0bf3e61 names a model its provider's list gives only by id as the other providers name it, and the sandbox catalog has zai's glm-4.6 as "GLM-4.6", so TestHanakoFiles and TestHanakoLive (macOS and ubuntu CI on 85fd35ab) still expected "glm-4.6 · Relay". Their expectation and the plugin fixture of a current provider now say "GLM-4.6 · Relay". No app change. go test ./internal/agent/ passes.

2026-10-06 13:48:18 +08:00

agentenv

feat: configure Zed-compatible Agent paths (#922 )

2026-10-06 01:04:26 +08:00

appdir

feat: configure Zed-compatible Agent paths (#922 )

2026-10-06 01:04:26 +08:00

autostart

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

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

awake

awake, gateway, gui: Settings › General › Keep awake while agents work keeps the computer from sleeping by itself while agents work through magpie (xiao_wang24004 on X) — the computer went to sleep in the middle of an agent's task. With the new setting on (off by default, this computer's own: KeepOwn), the magpie serving the gateway holds the system's idle sleep off while a request is in flight or a Claude Code turn waits on its tool results, and for ten minutes after the last request ended (an agent running a build or the tests between requests), looking every 5 s, and lets go once idle or turned off. On a Mac it runs caffeinate -i -w <magpie's pid> (PreventUserIdleSystemSleep, gone with magpie), on Windows SetThreadExecutionState(ES_CONTINUOUS|ES_SYSTEM_REQUIRED) from a thread of its own, on Linux systemd-inhibit --what=idle:sleep (Pdeathsig; said once in the log and nothing else where it is missing). The display may still turn off, and closing the lid still sleeps. en/zh/ja/de. Tested with a real DeepSeek account through magpie web --gateway in a sandbox HOME: a streamed request had caffeinate asserting on behalf of magpie's pid in pmset -g assertions, and turning the setting off through /api/settings released it within a tick. TestKeep (held once while busy and within the grace, let go past it, when off and when Keep ends; -race) and TestKeepAwakeKeptAndOwn are new; keep-awake.test.cjs (WebKit and Chromium, en and zh: off by default, On/Off post keepAwake, another setting's save keeps it, no scroll, no left border, shown on a browser's page) fails without the change; lightweight and click-scroll pass in WebKit. go vet, go build (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui ./... under a temp HOME pass.

2026-10-05 19:46:02 +08:00

backup

backup: pin the #880 subscription sign-in policy with a test (#901 )

2026-10-05 21:39:23 +08:00

budget

budget: keep reservations in their original window (#796 )

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

catalog

catalog: a model the provider's catalog doesn't list is named as the other providers name it (John on Discord #feedback: GLM Coding Plan and ZCode name the same models in different case, in the provider list and the group picker) — the Coding Plan's /models (open.bigmodel.cn and api.z.ai, read with a real key) gives ids alone, glm-5-turbo, glm-5.3-flashx …; catalog.Decorate names only those Zhipu's models.dev entry (zhipuai) lists, so glm-5-turbo kept its id as its name beside ZCode's GLM-5-Turbo. models.dev's load now keeps each model's name as most providers serving it give it (a name that is only the id casts no vote), catalog.NameOf reads it by bare id in any case, and catalog.Named fills it in for a model still named by its id: in Available's live list and for a pick the list doesn't have. Ids, and what is sent upstream, are unchanged; a name the user gave stays theirs (Catalog's Name, with the new one as Default); an Azure provider is left out, its deployments named as their owner named them. TestModelNamedAsElsewhere (the Coding Plan's real ids, a user name, an Azure deployment) fails without the provider change and passes; TestNameOf is new. TestSearcherChosen read whatever catalog an earlier test had left loaded, and now resets it: with none, its lists' models go by their ids, as it expects. go test ./internal/catalog/ ./internal/provider/ ./internal/gateway/ ./internal/gui/ . pass; -race -count=5 for the two new tests; go vet, linux(nogui)/windows builds pass. No GUI change (the GUI and the group picker show name || id).

2026-10-06 13:09:40 +08:00

claudebridge

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

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

codexcat

codexcat, gateway, gui: Settings › Codex auto-review model picks the model Codex's auto-review decides approvals on (#938 , guitaoliu)

2026-10-06 01:58:42 +08:00

davsync

davsync, agent: sync turned off and on again to the same server keeps what changed here, and an agent shown only routing groups connects on the first (#939 , aiirobyte)

2026-10-06 02:16:08 +08:00

edit

refactor(agent): separate Aside provider connection from model settings (#827 )

2026-10-05 14:37:44 +08:00

filememo

windows: an account list read while another magpie writes it is waited for, not taken for no accounts (Packing1 on Discord, Windows 11: 早上更新重启后之前登录的Antigravity订阅供应商和账号都没了 … 整行都没了，供应商里面antigravity直接消失了) — on Windows a file being renamed over (every write magpie makes: a temp file renamed onto it) is, for a moment of up to ~2ms, "The system cannot find the file specified" to anyone else looking at it, with MoveFileEx and with POSIX-semantics renames alike. filememo.Read gave that back as an error, readLogins as no accounts, and whatever change came next (any account's read-modify-write) wrote the empty list back: every built-in account gone, its subscription with it. Measured on Windows 11 (10.0.0.132): one process replacing a 200 KB file, another stat-ing and reading it, saw the file "not there" in a few windows each 20 s. Now steady.Stat and steady.ReadThere wait out a moment of a file not there (15 tries a millisecond apart, Windows only), and filememo looks through them, remembering a file found not there so one that really isn't costs the wait once. A magpie started by an update now waits for the one it replaces before its start-up moves write any file (AwaitPredecessor at the top of run, not only in the GUI). TestLoginsKeptWhileAnotherMagpieWrites (Windows: two writers replacing logins.json, readLogins never without the Antigravity account) failed 1 in 3 and 2 in 8 runs on the old code ("read as no accounts 8 times"), passed 11 of 11 on this; filememo's TestReadWhileReplaced the same (1180 misses on the old code); TestStatWaitsOutAReplace everywhere. A real update in a sandbox home on the Windows box, magpie-cli 0.1.880 → 0.1.942 from the release, kept the account and logins.json byte for byte. go vet (darwin, and windows nogui), builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 10:57:45 +08:00

fx

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

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

gateway

claude: Claude Code's output is read to the end before its run ends, not cut by Wait closing the pipe (CI Test run 37415124103 on 963a8d8f: TestClientGoneRecordedAsCanceled got event: error … "read |0: file already closed" in place of message_stop on ubuntu, race shard) — the run read Claude Code's stdout from cmd.StdoutPipe, and launch's goroutine called Wait as soon as Claude Code exited, which closes that pipe. A run stopped as its client went away (letGo → abort → Kill) could have Wait close the pipe under readOutput before abort's finish closed the segment: the scanner failed with os.ErrClosed, readOutput emitted it as a KError, and relay wrote it to the client as the stream's error. The same cut lost what Claude Code wrote last whenever it exited: whatever was still in the pipe never reached the client. Its stdout and stderr now come through os.Pipe pipes of the run's own, which Wait doesn't touch; once Claude Code has exited and its group been ended, the run waits for both readers (up to outputDrain, 2s, for a process that left the group and still holds them), closes the pipes, then finishes. A read cut by that close is taken as the output's end, not an error. TestClaudeLastWordsAreRead (a fake Claude Code writes ~300KB and exits) fails on the old code on every run (the reply's last delta lost) and passes; TestClientGoneRecordedAsCanceled|Keepalive|TestClaudeLastWordsAreRead pass -race -count=50 under GOMAXPROCS=2 with 4 busy cores; the gateway's race suite through build/race-shards.sh (4 shards, as CI) and go vet pass. The CI failure itself didn't reproduce on macOS. Not changed: the "http: panic serving …: invalid concurrent Body.Read call" lines in the same log are in shards that pass and in green runs too (5 in 37416877275), near the Copilot auto / count_tokens tests; their handler wasn't found.

2026-10-06 13:40:55 +08:00

gui

usage-sessions-agents-fit test: in WebKit the last agent is clicked as an element — the test failed ~70% of runs in WebKit, en and zh (a timeout waiting for Zed to be picked), and had since c6e318e1 added it: no commit turned it red. Playwright's WebKit stops hit-testing a scroller's children once it has been scrolled: on a bare page with a display:flex, overflow-x:auto strip, after scrollLeft is set every click on its buttons lands on the strip (57/57 lost; Chromium 0/58), elementFromPoint gives the strip from the next frame on, and in this test a wheel scroll does it too. The system's WKWebView, which the Mac app uses, takes the click: the same page in a WKWebView in an AppKit window, scrolled the same way, hit-tests and clicks the button. So it isn't the app. Chromium still clicks with the mouse; WebKit clicks the button through the DOM, which runs the same onclick and redraw. What the test guards is kept: with the button reuse and the bring-into-view both taken out of app.js, the WebKit cases still fail ("the picked agent stays in view"). No app change.

2026-10-06 13:51:38 +08:00

imagemcp

library, imagemcp: magpie's own image server is given to agents in WSL, started through WSL's interop with the paths crossing over (#900 , cjyrainbow) — on Windows the Library names magpie-image by this machine's binary ('D:\tools\Magpie\magpie-windows-amd64.exe' mcp image), and turning it on for "Codex · WSL Ubuntu" or "Claude Code · WSL Ubuntu" failed: a Windows program was refused for every agent in WSL. WSL's interop starts a Windows .exe from inside the distro, so magpie's own server (args mcp image, whatever its binary) is now written for an agent in WSL by the binary's path in the distro, asked of the distro itself (wslpath -u, so a custom automount root is followed; asked once in ten minutes; /mnt/<drive>/ when it can't be asked), with --wsl <distro>, --mount where the drives aren't under /mnt/, --home the distro's $HOME, and WSLENV naming the variables it is given (MAGPIE_ADDR), which a Windows program otherwise doesn't get. A distro whose interop is off (no WSLInterop in binfmt_misc) is told so: turn it on in /etc/wsl.conf. A user's own Windows program is still refused, as before: its paths and variables wouldn't cross over. A Linux magpie in the distro isn't looked for: the Windows one reaches the gateway at 127.0.0.1 and reads this machine's settings, the same version as the app, which a Linux one would need the gateway's address from inside WSL for. With --wsl, magpie mcp image opens the paths the agent gives (its roots, reference images, where to save, ~/) as the distro's — /home/me/x through \\wsl.localhost\<distro>\home\me\x (\\wsl$\ where that isn't), /mnt/c/x as C:\x — answers the saved paths as the distro's (/home/me/app/generated-images/…, /mnt/c/…), and with no project falls back to the distro's ~/Pictures/Magpie. Tested on the Windows 11 test box: in a WSL2 Ubuntu 24.04 distro the library's probe gave /mnt/c/…/magpie.exe and interop:on, and this build, started from the distro as the library writes it (the .exe's /mnt/c path, mcp image --wsl, MAGPIE_GATEWAY through WSLENV to a stand-in gateway in the distro), answered initialize and generate_image with a root of /home/yeton/m900proj: a relative path and an absolute reference image (sent as /v1/images/edits), ~/m900proj/home.png and /mnt/c/… were each saved there and answered as the distro's paths. TestWSLMagpieImage (the /mnt/d command, --wsl, WSLENV, nothing rewritten or asked again at the next sync, a custom mount, interop off as a problem) and TestLinuxHome in internal/library, TestWSLPaths in internal/imagemcp are new and fail without the change; TestWSLServers (npx.cmd still refused) passes. go vet, go build (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui ./... under a temp HOME pass (internal/provider failed once under load and passes alone).

2026-10-05 20:09:34 +08:00

library

library tests: TestAgentsSkillsFolders gives Alma a data folder on Windows (#973 ) — sandbox clears APPDATA, so os.UserConfigDir failed there: Alma (whose data folder is %APPDATA%\alma) was never there, and the test's MkdirAll made an "alma" folder in the working directory. The test now sets APPDATA in its sandbox, and puts Goose's config where Goose reads it on Windows (%APPDATA%\Block\goose\config), as Alma reads the shared folder Goose's skills are in. No app change. Passes on the Windows box with and without the symlink privilege, and on the Mac.

2026-10-06 13:32:03 +08:00

mcpauth

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

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

middleware

plugin, gateway, gui: a plugin can be gateway middleware — onRequest, onEvent and onResponse run in magpie's gateway on what agents send and get back (moejs) — a plugin could only be a subscription provider, run in the Bun host, a process away from the gateway. A plugin may now declare middleware (package.json magpie.middleware, or a *.middleware.js / .mjs file), run in-process by moejs (pure-Go JS engine): compiled once, one runtime per request from a pool, so every hook of a request shares ctx.state. onRequest(body, ctx) sees the agent's body in its own API before routing; what it returns is the body the next middleware and the gateway get, undefined leaves the bytes as they were, ctx.reject(status, msg) answers with an error in the agent's API's shape. onEvent(ev, ctx) sees each SSE event's JSON (export const events = [...] filters by name; an object changes it, null drops it, undefined passes the bytes through untouched; data: [DONE] is no JSON and passes by). onResponse(body, ctx) sees a whole JSON reply, with ctx.status. ctx has protocol, model, stream, path, agent, the plugin's options and state. A hook that throws, returns a non-object or runs past its limit (250ms request/response, 50ms an event, 1s load; interrupted) leaves the request or reply as it was and is counted and logged (60 lines a minute); a compressed reply passes as-is. Files are reloaded within a second of a change. Only agents' requests run through it (serveAgent at the gateway's agent entry points and the Codex backend), never magpie's own titles, classifier or stand-ins; it sees bodies before redaction. A middleware-only package is skipped by the Bun host. The Plugins page marks a middleware with a chip, its hooks, calls and µs per call (JSON in and out counted), failures in red with the last error, and a load error. en/zh/ja/de; docs/reference.md and usemagpie.ai/docs/plugins#middleware (en/zh/ja) with an alias example. Tested with a real DeepSeek account through magpie web --gateway in a sandbox HOME: an alias middleware served "fast" and named it in message_start, a reject came back as 403 permission_error, a Chat stream uppercased; real Claude Code (sandbox CLAUDE_CONFIG_DIR) did Read, Bash and Glob tool turns through three middlewares with 0 failures: ≈1–1.6µs an event, 0.2–0.7ms an onRequest that parses and rewrites Claude Code's ≈80KB body. Real use found two bugs fixed here: [DONE] parsed as JSON (SyntaxError on every Chat stream) and stats leaving out the JSON time. internal/middleware tests (chain, undefined keeps bytes, reject, fail-open on throw/spin/string with the runtime reused, async hook, load errors, off and Bun skip, reload, split/CRLF/filtered/dropped stream events, [DONE] untouched, whole reply and gzip, 64 in parallel; BenchmarkEvent ≈0.9µs, 11 allocs) and TestMiddlewareThroughGateway (alias routed, events by protocol, redaction still upstream, reject in Anthropic's shape; fails without the change) are new; plugin-middleware.test.cjs (Chromium and WebKit, en and zh: chip, hooks and stats, failures with last error, broken and off, no left border) fails without it. The other plugin GUI tests and click-scroll pass in WebKit. go vet, go build (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui ./... under a temp HOME pass (internal/provider failed once under load and passes alone).

2026-10-05 19:14:31 +08:00

netproxy

netproxy: a host on the user's own network goes around the proxy (#982 , jiz4oh: a Remote magpie's model list failed with "no model list: http://server…:3425/v1/models : 502 Bad Gateway", and Test with "no model to try", while curl with the key got the list) — the 502 had no body, which magpie's own errors always carry, and the other magpie logged nothing for the refresh: the request went to the proxy magpie takes from its settings, the environment or the system (Clash and the like), which couldn't reach the LAN name and answered 502. netproxy.Func now sends a request directly when the global proxy would take it and the host is on the user's network: a private, link-local, loopback or 100.64/10 (Tailscale) address, a .local name, or a name whose every address is one of those (looked up for at most 400ms, kept a minute; a name that doesn't resolve still goes through the proxy). A provider's own proxy is still taken as it is. Models, chat, count_tokens and the shared quota cards to a Remote magpie all go through Func (http.DefaultClient and the gateway's transport), so all are covered; so is any other provider on the LAN (an Ollama on a NAS). TestLANModelListNotThroughProxy (a proxy that answers 502 to everything, set in magpie, and a fake remote magpie on this computer's LAN address) fails without the change with the reporter's bare "502 Bad Gateway" and passes; TestLANGoesAroundTheProxy (IPs, LAN/Tailscale names, a vendor, a provider's own proxy) fails without it. Not tried on the reporter's network; they're asked to confirm. go test ./internal/netproxy/ ./internal/catalog/ ./internal/provider/ ./internal/gateway/ ./internal/update/ ./internal/usage/ pass; -race -count=5 on the new tests; go vet, darwin/linux(nogui)/windows builds pass.

2026-10-06 13:35:32 +08:00

omarchy

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

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

plugin

plugin: magpie plugin update in a terminal restarts the app's plugin host (#952 , mxzs123) — the running magpie noticed another magpie's plugin change only by plugins.json, which an update leaves as it was (the spec stays, bun installs a newer version), so the app's host went on answering with the old code (0.1.17 after the update to 0.1.18, still 403) until it was killed. The stamp checkList compares now also covers what is installed: Dir()'s package.json and bun's lockfile; and Restart takes the stamp as it is, so this magpie's own install isn't taken for another's and restarted twice. In a sandbox (serve on 3476 under its own HOME, the Factory plugin at 0.1.17, unpinned spec; a request, then magpie plugin update in another process, then a request): on 2d85a086 the host process stayed the same (58657) with 0.1.18 installed; with this change it was replaced (60004 → 60583) and the old one stopped. TestTerminalUpdateRestartsTheHost is new and fails without the change; go vet and go test -race -tags nogui ./internal/plugin/ ./internal/provider/ under a temp HOME pass.

2026-10-06 08:47:59 +08:00

proc

proc: IsMagpie knows the name an update leaves a running exe under (#963 )

2026-10-06 11:28:04 +08:00

profile

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

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

provider

claude: an account's saved sign-in isn't overwritten with the account Claude Code was just switched to (netfishx on X: Pro, Max and Team accounts, "Keep Claude Code signed in to" on; after routing moved once or twice the Usage page showed one account's plan and allowance on another's card) — magpie switching Claude Code (to the kept account, or back to it) writes the new sign-in and profile, and a Claude Code started on the account before then writes that one's profile into ~/.claude.json: the credential was the Team's, the profile the Pro's. rememberLogins paired them, and upsertLogin, matching the Pro's record by the profile, wrote the Team's sign-in and plan into it ("pro@x.com · Team"). The Pro's runs, in its own config directory seeded from that record, then spent the Team account, and their rate_limit_events and plan showed on the Pro's card. upsertLogin now refuses a Claude sign-in another saved account holds (access or refresh token) while the record the profile names doesn't: the account the profile names holding it already, or Claude Code having renewed it, it is saved as before, so a record crossed by an earlier version doesn't hold the owner back (re-adding the crossed account puts its own sign-in back). TestClaudeUsageUnavailableAfterAccountSwitch switched by the profile alone; it now writes the new account's sign-in as a switch does. Not tried with real Claude accounts (one here). claude_crossed_test (switch to Team, the Pro's profile written after, switch back: each record and each saved account's directory keeps its own sign-in and plan; a crossed record doesn't stop the Team's own being saved, renewed or not) fails without the fix on the first case and passes with -race -count=5; go test ./internal/provider/ ./internal/gateway/, go vet, linux(nogui)/windows builds pass.

2026-10-06 13:39:48 +08:00

qoder

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

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

redact

cleanup: drop redact.Known and the quotaWire type — nothing calls either (deadcode -test -tags nogui, git grep). vet on darwin, linux, windows; redact and provider tests pass.

2026-10-06 06:07:02 +08:00

sessions

cleanup: gofmt the 15 Go files main had unformatted — whitespace, comment alignment and three one-line funcs gofmt opens up; nothing else. go build and vet -tags nogui pass.

2026-10-06 07:43:47 +08:00

settings

qoder: daily check-in for Qoder and Qoder CN (ARNO on Discord) — while Settings › Daily check-in › Qoder (or the card's Auto check-in) is on, the gateway claims each plugin account's claimable daily credits (campaigns with actionType CLAIM_BENEFIT on openapi.qoder.sh / openapi.qoder.com.cn, as wallechfox/qoder-checkin claims them) once a Beijing day, through the plugin's fetch on its device token (@magpie-community/opencode-qoder-auth 0.2.7, now the mover's min). One claimed already is done, none listed is no event, an expired sign-in or an old plugin says so. Kept in qoder-checkin.json by site and uid; shown on the usage card, in the TUI's and CLI's check-in. Built-in (unmoved) accounts aren't checked in. Not tried with a real Qoder account. qoder_checkin_test (fake campaigns, both sites; -race -count=3) and usage-checkin (Chromium and WebKit, en and zh, fails without the GUI change) pass; go test provider/gui/tui/settings/gateway, vet, linux/windows/nogui builds pass.

2026-10-06 11:41:11 +08:00

shortcut

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

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

source

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

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

stats

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

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

steady

windows: an account list read while another magpie writes it is waited for, not taken for no accounts (Packing1 on Discord, Windows 11: 早上更新重启后之前登录的Antigravity订阅供应商和账号都没了 … 整行都没了，供应商里面antigravity直接消失了) — on Windows a file being renamed over (every write magpie makes: a temp file renamed onto it) is, for a moment of up to ~2ms, "The system cannot find the file specified" to anyone else looking at it, with MoveFileEx and with POSIX-semantics renames alike. filememo.Read gave that back as an error, readLogins as no accounts, and whatever change came next (any account's read-modify-write) wrote the empty list back: every built-in account gone, its subscription with it. Measured on Windows 11 (10.0.0.132): one process replacing a 200 KB file, another stat-ing and reading it, saw the file "not there" in a few windows each 20 s. Now steady.Stat and steady.ReadThere wait out a moment of a file not there (15 tries a millisecond apart, Windows only), and filememo looks through them, remembering a file found not there so one that really isn't costs the wait once. A magpie started by an update now waits for the one it replaces before its start-up moves write any file (AwaitPredecessor at the top of run, not only in the GUI). TestLoginsKeptWhileAnotherMagpieWrites (Windows: two writers replacing logins.json, readLogins never without the Antigravity account) failed 1 in 3 and 2 in 8 runs on the old code ("read as no accounts 8 times"), passed 11 of 11 on this; filememo's TestReadWhileReplaced the same (1180 misses on the old code); TestStatWaitsOutAReplace everywhere. A real update in a sandbox home on the Windows box, magpie-cli 0.1.880 → 0.1.942 from the release, kept the account and logins.json byte for byte. go vet (darwin, and windows nogui), builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 10:57:45 +08:00

testenv

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

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

tui

qoder: daily check-in for Qoder and Qoder CN (ARNO on Discord) — while Settings › Daily check-in › Qoder (or the card's Auto check-in) is on, the gateway claims each plugin account's claimable daily credits (campaigns with actionType CLAIM_BENEFIT on openapi.qoder.sh / openapi.qoder.com.cn, as wallechfox/qoder-checkin claims them) once a Beijing day, through the plugin's fetch on its device token (@magpie-community/opencode-qoder-auth 0.2.7, now the mover's min). One claimed already is done, none listed is no event, an expired sign-in or an old plugin says so. Kept in qoder-checkin.json by site and uid; shown on the usage card, in the TUI's and CLI's check-in. Built-in (unmoved) accounts aren't checked in. Not tried with a real Qoder account. qoder_checkin_test (fake campaigns, both sites; -race -count=3) and usage-checkin (Chromium and WebKit, en and zh, fails without the GUI change) pass; go test provider/gui/tui/settings/gateway, vet, linux/windows/nogui builds pass.

2026-10-06 11:41:11 +08:00

update

update, gui: Add to PATH on Windows writes a magpie.cmd beside an app not named magpie.exe, so the site's magpie-windows-amd64.exe runs as magpie in a new terminal, and says so (#942 , mintonight)

2026-10-06 02:18:07 +08:00

upstream

upstream: the vendors' own status pages say when their API is down (#971 , emo172: an Anthropic or OpenAI outage looked like a sign-in or quota problem) — a provider that calls Anthropic's, OpenAI's or Moonshot's API (by its base URL's host: api.anthropic.com, which the Claude subscription calls too; api.openai.com and chatgpt.com, Codex's; api.moonshot.cn/.ai) carries "API outage" (red), "API degraded" or "API maintenance" beside its name on its Providers row and its Usage card while the vendor's page says so; its title names the parts and the open incidents, and a click opens the incident (or the page), not the row. internal/upstream reads each page's Statuspage-style summary.json (status.claude.com; status.openai.com, incident.io's; status.moonshot.cn), checked by hand on 2026-10-06, and only the API's own parts (Claude API and Claude Code, not claude.ai; Chat Completions, Responses, Codex, Codex CLI, not "Codex in ChatGPT Desktop", which was degraded that day); an incident naming no parts (OpenAI's) counts only while those parts are affected. Pages are read only when the Providers or Usage page asks (GET /api/upstream), at most once in five minutes, never on a request's way; a page that fails, isn't JSON or no longer lists the API's parts is unknown and marks nothing. A relay serving the same models is never marked. DeepSeek's page (Flashduty) has nothing readable and is only known for its link; OpenRouter, xAI, Mistral and z.ai have no page read. The gateway's failure messages, TUI, CLI and tray aren't changed. zh/ja/de added. upstream_test (fake pages from the real summaries: API down, claude.ai down isn't the API, Claude Code degraded, OpenAI's app isn't the API, 503/HTML/changed page unknown, read once in Fresh and Of never waits, hosts; -race -count=5) and gui's TestUpstreamRoute pass; upstream-status (Anthropic down: its provider and the Claude subscription marked, relay/OpenAI/unread Moonshot not, click opens the incident not the row, all well marks nothing; 900 and 440px, the badge whole, the name giving way) passes in Chromium and WebKit, en and zh, and fails 8/8 without the app.js change. i18n-keys, gui-ja, gui-de, click-scroll, account-return, account-models, usage-keys-fold, deprecated-subscriptions and add-sheet pass; go vet, go test ./internal/gui/, linux/windows/nogui builds pass.

2026-10-06 12:36:05 +08:00

usage

usage tests: TestOTelRetryAfterBound times the retries from the first attempt (#973 ) — on Windows every attempt came 30ms late in the synctest bubble: a settings file not there is waited on (steady, 1ms × 15 per path) before it is taken as gone, and the bubble's clock counts those sleeps, so the first attempt was at 30ms, not 0. The spacing between attempts, what the test is about, was exact. No app change. Passes on the Windows box and on the Mac (-race -count=5).

2026-10-06 13:32:03 +08:00

wslrun

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

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

zed

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

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