okooooooo/magpie
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2,072 Commits 1 Branch 0 Tags
c06a550b73680289d5a94de7a412356d4040297d
Commit Graph
9 Commits
Author SHA1 Message Date
yetone 3ffc99ef60 codex: a call id longer than 64 characters goes as one the backend takes on Codex's own ChatGPT sign-in too, and tool_search ids with it (#732, congee949) — #732 bounded them where magpie writes the request (codexBody: Chat and Anthropic clients on a Codex model, Codex App with spare accounts), but Codex on one ChatGPT account is relayed as it came (codexUpstream), so a conversation with a foreign provider's tool calls (two ids joined, 86 or 87 characters) still got 400 "input[7].call_id … maximum length 64" there: 30 in a week in the report, 29 of them thread_description on gpt-6-luna, on v0.1.869. The relay now gives every call_id over 64 characters as provider.BoundCallID has it (the sha256 of the trimmed id, so a call and its output, paired by the trimmed id, get the same one on every request), the rest of the request byte for byte; codexBody uses the same helper and covers tool_search_call / tool_search_output as well. TestCodexRelayBoundsLongCallIDs (single-account relay: function and tool_search ids bounded, paired and stable across requests, a 64-character id kept) fails on the old code. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass. 2026-10-05 00:31:36 +08:00
congee949 6a67774a99 fix(codex): bound foreign tool call IDs and preserve result pairing (#732) 2026-10-05 00:31:19 +08:00
yetone 9f7b6bd86c codex: a cached entry keeps the cache's own max when magpie's list has none, and Codex's models_cache.json is read under CODEX_HOME everywhere (follow-up to #674, from reviewing #679) — restoring a cached native entry (backend away) set max_context_window to max(MaxContext, Context) from magpie's live list, so a list saved without the max (before magpie kept it) wrote the window over the cache's own (872000 became 272000); now a list with no max leaves the cache's, and codexcat.Window still raises it to a window past it. codexcat.CacheEntries and catalog.Codex read ~/.codex/models_cache.json even with CODEX_HOME set, while codexVersion and codexInstructions followed it; all four now take catalog.CodexModelsCache() (CODEX_HOME, else ~/.codex), and provider's codexCLIHome and the copy in codexInstructions are gone. TestCodexReadsCacheUnderCodexHome, TestCodexCachedListUnderCodexHomeKeepsItsMax and TestCodexCatalogEntryFromCodexHome fail on the old code (the ~/.codex cache read, none listed from CODEX_HOME); TestCodexNativeModelsTakeSetWindows now wants a cached gpt-5.5 with no live max to keep the cache's 400000 (old code: 272000). go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass but TestProvidersAnswerWhileListsComeIn, a timing test that passes alone. 2026-10-03 21:39:13 +08:00
Zhaofeng 1a283b95fc fix(gateway): normalize standalone Responses tool outputs (#544) 
* fix(gateway): normalize standalone Responses tool outputs

* fix(gateway): preserve native notifications and tool result ordering
 2026-10-02 18:26:23 +08:00
yetone dd12c75bff codex: a turn relayed through Codex accounts says it is the Codex client it came from, or newer, so a model Codex CLI reaches on its own is no longer refused through magpie (Discord, lantern2077 / TuskerManshu: gpt-6.1-sol through a routing group answered 400 "The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account" while Codex CLI alone could use it) — the ChatGPT backend serves a model only to a client new enough for it. Re-signing a pool turn, codexSign set User-Agent codex_cli_rs/<codexVersion()>, the newest of a constant 0.154.0, ~/.codex/models_cache.json's client_version (written by the Codex before the last update) and codex --version when codex was on PATH, ~/.local/bin or Homebrew's — nvm, mise, fnm, npm prefixes, pnpm and Volta were out of reach, above all in magpie serve — while the client's own version header was relayed: one turn saying two versions, the older in the User-Agent. Now codexSign writes one version in both, never older than the relayed one; the gateway notes the newest version a Codex client (originator or codex… User-Agent) has come with (SawCodexClient) and codexVersion, also asked by the accounts' model lists, takes it; the fallback is 0.159.0; the models cache is read from CODEX_HOME when set; codexExecutable also looks in proc.UserBinDirs() (every Node of nvm, mise and fnm, ~/.npmrc's prefix, pnpm, bun, Volta; %APPDATA%\npm and the like on Windows; codex.cmd/.exe there). Tested with TestCodexPoolSaysTheClientsVersion against a fake backend refusing gpt-6.1-sol below 0.161.0: Codex CLI 0.161.0 through the pool failed on main with codex_cli_rs/0.154.0 and passes; TestCodexVersionSeen (Claude Code's User-Agent ignored, CLI and Desktop versions read, never lowered, the model list asked with it), TestCodexVersion with CODEX_HOME, TestCodexExecutableOffPath (nvm, mise, an .npmrc prefix with PATH /usr/bin:/bin). go vet ./internal/..., go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried against the real backend: the version gating is read from the error and the models cache, not seen on the wire. 2026-09-30 10:06:15 +08:00
yetone 0ce1888a32 codex: Fast mode through a ChatGPT account — a GPT model Codex's own catalog doesn't list carries the Fast tier Codex gives its GPT models, and the priority service_tier Codex sends for /fast reaches the backend instead of being dropped; other providers' models don't offer it, and other tiers are still left out 2026-09-27 17:42:43 +08:00
Charan RathoreandCursor Agent 20fe8b4fac provider: a second Codex account's prompts stay cached when two saves share an mtime - the list on disk was merged, but the in-process cache re-read it only when ModTime changed, so a second write in the same tick left the first account's list in memory; a successful save now drops that cache, and a test puts the mtime back with Chtimes so the collision happens every run (#74) 
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
 2026-09-26 00:26:41 +08:00
yetone e8b3be572c 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
yetone 2b80641dfc codex: a ChatGPT account's requests are made as Codex CLI makes them, as Alma's Codex plugin does — the backend gates its newest models on a Codex User-Agent (gpt-5.6-luna answered 404 "Model not found" to magpie's), so a request now says it comes from codex_cli_rs, carries the instructions the account's model list gives each model (kept on disk beside the list, for the gateway to find though another process asked, else Codex CLI's copy, else Codex's generic prompt) with the client's own riding first in the input, and is shaped the way Codex sends one: no stored references or item ids, a tool output without its call told as a note, reasoning summaries and encrypted content asked for, tool_choice auto; and a conversation whose client names none gets a prompt_cache_key of its own, the same on every turn, taken from how the conversation starts, so its cached prompt is found again (Claude Code through magpie went from 74% of its input cached to 96%, where requests without one landed on caches that didn't have it) 2026-09-25 11:44:17 +08:00