Skip to content

v0.9.1

Latest

Choose a tag to compare

@rsalmn rsalmn released this 23 Sep 09:43

Highlights

  • Xiaomi MiMo Desktop: handshake region + cookie threading — three defects fixed that made every mimo-x-*-preview call fail. Reason-blind error: getServiceCookie already distinguished "no-pass-token" from "sso-failed" but the executor collapsed both into a misleading "sign in to MiMo Desktop" message — new getMimoAccountSession() returns {cookie, reason} with reason-specific guidance. Region mismatch: the SSO handshake could succeed on the CN cluster while the chat request still went to the SGP host, so a valid CN-minted cookie got a 401 — the handshake now returns the winning region and buildUrl uses credentials.__mimoAccountRegion. Wrong cookie names: Xiaomi issues SID-scoped identity cookies (mimopc_ph / mimopc_slh), not the region-derived names the old needed-list expected — emission now uses serviceToken + userId + cUserId + any mimo* cookie. userId/cUserId from Desktop auto-detect now reach the saved connection, and [MimoSSO] per-step diagnostics were added. The handshake now completes and Xiaomi authenticates the session; a remaining 403 membership_required is an account-entitlement issue, not a code defect.
  • Antigravity: projectId provisioning + diagnosable gateway 403s — every stored antigravity connection shipped projectId="" (DB-verified), so the executor sent a locally fabricated id as the request project field. Two provisioning holes: projectId.js skipped onboardUser for any endpoint containing daily- (the canary host antigravity actually uses), and the dashboard OAuth connect path only fired onboardUser when a projectId was already present — never rescuing an empty one — and never persisted the issued id. Now: the same loadCodeAssist → onboardUser fallback as gemini-cli, the connect path tries both production and canary hosts, onboardUser is always attempted (bounded, awaited) even when loadCodeAssist returns no project, and any issued id is adopted and persisted. The executor's new parseError turns an empty-body 403 into a diagnosable message (host + project sent + gateway headers) and warns whenever a fabricated projectId is used. Note: bare 403s also occur on healthy connections, so the missing id is a real defect but not a proven deterministic cause of every failure — intermittent body-less 403s remain consistent with Google-side gateway rejection on the canary host.

Install / upgrade: npm install -g @rsalmn/extremerouter · Docker: rsalmn/extremerouter:0.9.1 · Single executables attached below (Windows / Linux / macOS).