magpie

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

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

agent: an agent's own provider named as one of magpie's isn't magpie's, in every agent that spells a model provider/model (the rest of #835 ) — OpenHanako's own deepseek/deepseek-v4-pro read as magpie's deepseek, and so did a model of any agent's own provider whose name magpie has a provider by: Pi's, Crush's, Hermes's, OpenCode's relay/glm-4.6 with magpie's relay had the row connected on the agent's own model, and Disconnect from magpie put that model back and left the row connected. An agent says how magpie's values are spelled in it (Spelled, replacing #835 's Prefixed): magpie/<ref> for Antigravity CLI, Pi, OmO, Aside, Goose, Zed, VS Code, Crush, DeepSeek Harness, Command Code, fx, omp, Hermes, Mister Morph, Kimi Code, Empryo, MiniMax Code, Droid, Qoder, Qoder CN, Grok Build, AtomCode, Cline and OpenHanako, whose every Get spells magpie's so (a sandbox Set of magpie/relay/glm-4.6 read back as that in each); for OpenCode, MiMo Code and OpenChamber also a provider of the config's own that sends to magpie's gateway, as openCodeRef names a model there. A stopped WSL distro's agent keeps its live one's. Left as they are: Claude Code, Claude Desktop, Codex, Gemini CLI, Cursor, Copilot, Devin (magpie's are bare refs there), Muse Code (a model with / is magpie's by design: Meta's have none), Alma (its own are providerId:model), Air (magpie's only). TestOwnProviderNamedAsMagpies (26 agents: own relay/glm-4.6 not connected, Connect, Disconnect puts it back and the row is off) fails on the old code in each; TestOpenCodeGatewayProviderIsMagpies. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 06:49:45 +08:00

agentenv

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

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

appdir

appdir: reject tilde paths that readers do not expand (#803 )

2026-10-05 00:42:29 +08:00

autostart

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

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

backup

davsync: scope provider and library credentials during partial sync (#744 )

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

budget

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

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

catalog

gui, provider: the request log scrolls sideways from a bar at the window's foot and a request's detail opens with its status, duration and a View routing link (mintonight, #799 ); a provider has a price rate its costs are counted at (ITea312, #819 ) — #799 : the request table, wider than the window, could only be scrolled sideways from the scrollbar at its very end, below 40+ rows, so it looked like it had none; and the "status detail" the reply pointed to wasn't to be found in the row's detail. A bar (#ledHScroll) now sits at the window's foot while the table is wider than its box, scrolling with it both ways; a row's detail begins with Status (Succeeded for log rows), Duration and Routing: View routing, which opens the request's route. #819 : costs were counted only at the official (list or maker) price, or a price set per model with magpie model price; a relay billing 0.8 of it had to have each model priced by hand. The provider editor (key and signed-in alike) has a Price rate field (empty for 1; 0–1000, three decimals), saved as priceRate; EffectivePrice multiplies the list/maker price by it, and a price set for a model stays as set. Usage caches key on the providers file, so the counts follow. zh, ja, de strings. ledger-hscroll.test.cjs (fails on the old code) and provider-price-rate.test.cjs (WebKit, en and zh); usage-ledger, usage-ledger-detail (updated for the new rows), usage-ledger-content, usage-ledger-chart, routing-failed-open, purpose-filter, provider-concurrency and provider-levels-save pass on WebKit. TestPriceRateScalesListPrice, TestPriceRateOK, TestPriceRateOf. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 02:03:10 +08:00

claudebridge

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

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

codexcat

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

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

davsync

davsync: scope provider and library credentials during partial sync (#744 )

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

edit

edit: a dotenv key set twice reads and writes its last line, as dotenv does (#832 )

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

filememo

perf: magpie opens and shows the Agents page in a fraction of the time it took (Junjie Zhou on Discord: 8 个 agent 30 个 provider … 每次我打开的时候都会很慢，要好几秒。setting 页面秒进后我切换到 agent 就有问题) — at start, writing the agents' model lists (agent.SyncCatalog) built every provider's catalog thousands of times with nothing held, each build reading migrations.json, settings and groups again: 6000+ file reads and ~8.5s of CPU in the first 8s with the owner's 30-odd providers, all competing with the first /api/state and the Agents page. Now SyncCatalog, magpieModels and main's start-up moves run under provider.Hold, migrations, groups, settings and a provider's fetched models are held for a second like the rest, and filememo.Hold lets a GET /api/* not stat a file it confirmed unchanged within the last second (any magpie write, Changed() or a recent mtime still reads it again). A big ~/.codex/config.toml parsed in quadratic time (the TOML parser's Shape counts newlines from the start for every key): a 3 MB one took 5.4s, now 0.04s (tomlShaper). theInstalled reads through edit.Read's memo. Measured with a copy of the owner's magpie config and agent configs under a sandbox HOME, the real server in WebKit: CPU in the first 8s 8.59s → 0.39s, page up 475 → 75ms, Agents rows drawn 775 → 325ms after start; the agents' written model files are unchanged (pi byte for byte, opencode the same models). TestTOMLShaperMatchesParser, TestTOMLBigFileParsesInLinearTime (fails on the old code), TestHold (filememo), TestHoldReadsMigrationsOnce. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui ./... under a temp HOME pass.

2026-10-05 03:02:40 +08:00

fx

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

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

gateway

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

gui

修正滚动测试的日期按钮定位与触底判断 (#807 )

2026-10-05 07:44:06 +08:00

imagemcp

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

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

library

修复 Windows MCP 连接拒绝分类并补充 CI 回归 (#805 )

2026-10-05 07:44:11 +08:00

mcpauth

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

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

netproxy

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

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

omarchy

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

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

plugin

plugin: a slow reader pauses its stream instead of racing a watchdog (#812 )

2026-10-05 01:36:20 +08:00

proc

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

profile

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

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

provider

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

qoder

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

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

redact

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

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

sessions

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

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

settings

provider, gui: MiniMax Code's daily check-in (Hu9956, #811 ) — magpie claims each MiniMax Code (China) account's daily check-in credits once a Beijing day, as MiniMax Code's page does, the same way it does WorkBuddy's and Trae CN's. It asks GET agent.minimax.cn/minimax-cloud/api/v1/signin/status?timezone_id=Asia/Shanghai and, only while today's day is claimable (status 2), POST /claim with {}. Both go through the minimax-code plugin's fetch, which signs them in as the account. The page's x-timestamp and x-signature (md5 of ts + salt + body) go with them, though MiniMax doesn't check these now. Day status 3 (claimed) and claim_result 2 count as done; status 4 is not eligible; base_resp's code and message are the failure's reason, and an expired sign-in says sign in again. The streak is the week's day_no. Results are kept in minimax-checkin.json. The international site's check-in isn't known, so minimax-code-global accounts are left alone. The switch is in Settings › Usage › warm-up and check-in › MiniMax Code (minimaxCheckin, off by default) and on the usage card (Auto check-in, Check in now: POST /api/settings/minimax-checkin, /api/usage/minimax-checkin); the card row's vendor strings are now a table (CHECKINS). magpie checkin and the TUI also check it in. zh, ja and de strings. No real MiniMax account was at hand: TestMiniMaxCheckin and TestMiniMaxClaimAlready run against an httptest fake built from Hu9956's captured answers. The fake checks timezone_id, the signature, the GET without a body and {} on the claim. It covers claim, no second ask the same day, in already, disabled, a refusal with its reason, and expiry. They pass with -race. usage-checkin.test.cjs adds the MiniMax card (its own switch and press, Trae's untouched) and the Settings tab (WebKit, en and zh, 8/8). settings-sections, gui-ja, gui-de, click-scroll and usage-quota-head pass on WebKit. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 03:05:14 +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

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

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

testenv

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

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

tui

provider, gui: MiniMax Code's daily check-in (Hu9956, #811 ) — magpie claims each MiniMax Code (China) account's daily check-in credits once a Beijing day, as MiniMax Code's page does, the same way it does WorkBuddy's and Trae CN's. It asks GET agent.minimax.cn/minimax-cloud/api/v1/signin/status?timezone_id=Asia/Shanghai and, only while today's day is claimable (status 2), POST /claim with {}. Both go through the minimax-code plugin's fetch, which signs them in as the account. The page's x-timestamp and x-signature (md5 of ts + salt + body) go with them, though MiniMax doesn't check these now. Day status 3 (claimed) and claim_result 2 count as done; status 4 is not eligible; base_resp's code and message are the failure's reason, and an expired sign-in says sign in again. The streak is the week's day_no. Results are kept in minimax-checkin.json. The international site's check-in isn't known, so minimax-code-global accounts are left alone. The switch is in Settings › Usage › warm-up and check-in › MiniMax Code (minimaxCheckin, off by default) and on the usage card (Auto check-in, Check in now: POST /api/settings/minimax-checkin, /api/usage/minimax-checkin); the card row's vendor strings are now a table (CHECKINS). magpie checkin and the TUI also check it in. zh, ja and de strings. No real MiniMax account was at hand: TestMiniMaxCheckin and TestMiniMaxClaimAlready run against an httptest fake built from Hu9956's captured answers. The fake checks timezone_id, the signature, the GET without a body and {} on the claim. It covers claim, no second ask the same day, in already, disabled, a refusal with its reason, and expiry. They pass with -race. usage-checkin.test.cjs adds the MiniMax card (its own switch and press, Trae's untouched) and the Settings tab (WebKit, en and zh, 8/8). settings-sections, gui-ja, gui-de, click-scroll and usage-quota-head pass on WebKit. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 03:05:14 +08:00

update

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

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

usage

agent: Cursor Private Inference, which magpie finds by its product.json and starts on magpie with a command its row copies, and whose /models gives each model's api_types and capabilities (#299 , mamba on Discord) — the build (Cursor 3.23.x, the same app name, bundle id and ~/.cursor as Cursor) runs its agent locally and asks the endpoint in CURSOR_LOCAL_AGENT_BASE_URL / CURSOR_LOCAL_AGENT_API_KEY when its Open configuration has none; mamba confirmed it works with any account pointed at magpie. magpie writes nothing of Cursor's (its settings share Cursor's state.vscdb): the Agents page lists it when an app's product.json says "Cursor Private Inference" (/Applications, ~/Applications; %LOCALAPPDATA%\Programs on Windows; /opt and the like on Linux), and its row's one control, Copy launch command (复制启动命令), copies CURSOR_LOCAL_AGENT_BASE_URL=<gateway>/v1 CURSOR_LOCAL_AGENT_API_KEY=magpie-cursor-local '<app>' (PowerShell on Windows); in the tray panel the row copies it. Its notice says to quit it first (a second start hands over to the running one) and that a base URL in Open configuration comes first. /v1/models asked with its key gives each model api_types (the APIs its provider serves it on, all three for a group or a translated one; it asks Anthropic Messages only when no OpenAI one is listed) and capabilities (context_length, max_output_tokens, supports_vision); any other client's list is unchanged. usage.AgentOf matches a name before a UA prefix, so cursor-local isn't counted as Cursor. TestCursorLocal, TestCursorLocalModels and cursor-local-launch.test.cjs (WebKit, en and zh) fail on the old code; agy-launch and agent-* GUI tests pass on WebKit. Not tried with the real app (not installed here). go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-04 23:38:19 +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