@magpie-community/opencode-trae-auth 0.2.21 → 0.2.23

package/README.md

@@ -231,7 +231,9 @@ which levels it takes — its `reasoning_effort_config`, with the options
 (`light`, `high`, `extra_high`) and the default. The request takes the same
 names as `reasoning_effort`, so a level an agent picks is sent as Trae
 spells it: the plugin offers each model's own levels as `variants`
-(`low`/`high`/`xhigh` for `light`/`high`/`extra_high`), and sends nothing
+(`low`/`high`/`xhigh` for `light`/`high`/`extra_high`; `medium` and `max`
+keep their names, offered only where the entry names them, as for DeepSeek
+V4.1 Flash's `max` in Trae's app), and sends nothing
 for a level the model doesn't name, or for a model whose entry names none —
 Trae then serves it at its own default. An entry naming levels this map
 can't spell offers none, rather than being sent one Trae would reject. A
@@ -354,12 +356,15 @@ an empty answer.
 Trae CN gives credits for a daily check-in (每日签到); Trae Global has no
 such page, so this is CN only. magpie can press it
 once a day for each account (Settings, or the switch on the usage card),
-through `auth.checkin`: `claimed` when Trae grants the credits, `done`
-when the status says today's is in already, `inactive` when the page is
+through `auth.checkin`: `claimed` when the status says today's is in after
+the claim, `done` when it said so before it, `inactive` when the page is
 disabled, `ineligible` when the claim answers 9095 (this device has
-checked in today) or 9074 (to be done in Trae CN's own app; not asked
-again that day), and `failed` for a turned-away sign-in or any other
-answer, which is tried again later that day.
+checked in today) or 9074 (Trae did not take it for this account's
+device) or answers code 0 while the read-back still says the day is out,
+and `failed` for a turned-away sign-in or any answer that got nowhere,
+which is tried again later that day. An `ineligible` is the day's answer:
+magpie asks that account no more until tomorrow, and only reads its
+status.
 It asks Trae CN's own pages through
 this plugin's fetch, which sends them as the account, as Trae CN's IDE
 (3.3.104) sends them: its Cloud-IDE-JWT (renewed first when near its
@@ -390,10 +395,27 @@ answered it 9074 even with the client's headers.
   plugin's, on its own device, got 9074 (yetone/magpie#808, #1920); that
   this header is what changes it hasn't been tried on a real account
   yet. Every other account keeps its own device, and a file that can't be
-  read or made out, or holds no single device, changes nothing. Files:
-  macOS `~/Library/Application Support/Trae CN/…`, Windows
-  `%APPDATA%\Trae CN\…` (or `trae-cn`), Linux `~/.config/trae-cn/…`
-  (or `Trae CN`; not seen on a real Linux install).
+  read or made out, or holds no single device, changes nothing.
+- **Every profile is read (0.2.21):** a machine can hold more than one
+  Trae CN client profile — the IDE's and TRAE SOLO CN's each write their
+  own `storage.json`, and each names the account that profile is signed in
+  as, with that account's device. So every profile is read and the one
+  signed in as the account answers with its device, which is how two
+  accounts can each check in on a real client's device. Before, only the
+  first profile was read and it decided for all of them: a second
+  account's own profile was never seen, and one profile signed in as
+  someone else (or one file that didn't parse) hid every profile after it.
+  A profile that isn't signed in as the account, or that names no single
+  device, is passed over rather than ending the search. Files: macOS
+  `~/Library/Application Support/Trae CN/…` and `…/TRAE SOLO CN/…`, Windows
+  `%APPDATA%\Trae CN\…`, `…\TRAE SOLO CN\…` (or `trae-cn`), Linux
+  `~/.config/trae-cn/…`, `…/Trae CN/…`, `…/TRAE SOLO CN/…`. The IDE's
+  folder has been seen in a real install (macOS and Windows); TRAE SOLO
+  CN's name and its `iCubeAuthInfo://` keys are read as the same client
+  of the same realm writes them, which hasn't been checked against real
+  files — harmless if they differ, since a folder that isn't there, or a
+  key that isn't named, is simply not read. A client started with its own
+  `--user-data-dir` is not found: there is no list of those to read.
 - **Every other account's device (0.2.16):** its own device id, in the
   client's shape. Trae CN answered a claim on the plugin's 19-digit id
   9074, while the same account and token on a 16-digit id were taken
@@ -404,15 +426,37 @@ answered it 9074 even with the client's headers.
   keep the 19-digit device it signed in with.
 - **What comes back:** Trae's answer as it is. A 401 or code 1001 marks
   the account for a new sign-in. Code 9095 means this device has checked
-  in today, and that holds for the day. No device id is ever changed or
-  rotated to get round a 9095 or a 9074, and no account is given another
-  account's device or its own client's device unless the client is signed
-  in as that account. The credit a claim granted is its `credits`, or
-  its `extra_credits` when it names only that; Trae CN's claim usually
-  names neither (`{"code":0,"message":"success"}`), and then the status
-  answer's `credits` is the credit. The two are never added: the status
-  carries `extra_credits` beside `credits` (100 and 100 on a real
-  account) while the day gives 100.
+  in today, and that holds for the day. Code 9074 means Trae did not take
+  the claim for this account's device: its own words say the pool is busy,
+  which two measurements do not bear out — the same account, token and
+  headers were taken on a 16-digit id where a 19-digit one got 9074
+  (plugins#194), and on 2026-10-23 the same account and headers were taken
+  on a device id Trae had never seen while this account's own id answered
+  9074. The message says so, and does not send people to Trae CN's app,
+  which is not where the problem is. Signing the account in to a Trae CN
+  client on this machine is the one thing seen to change a 9074, but it
+  hasn't been tried on a real account, so it isn't named in the message;
+  nor is it named when the claim already rode a client's device, where it
+  would only tell the user to do what they did. No device id is ever
+  changed or rotated to get round a 9095 or a 9074, and no account is
+  given another account's device or its own client's device unless a
+  client is signed in as that account.
+- **A claim's code 0 is not the answer (0.2.22):** Trae answers a
+  claim code 0 for one that registered nothing, so the status is read back
+  after every claim and only a day that is in is reported as `claimed`.
+  Since 0.2.22 one that isn't is an `ineligible` — the day's answer, not a
+  `failed` to be tried again: a `failed` is retried with backoff for the
+  rest of the day and each retry is another claim, which for an account
+  Trae keeps answering code 0 would turn one claim a day into many, and a
+  status that lags a claim that did land would read as not in once and
+  claim again. Nothing is claimed again that day; the status alone is
+  read, so a lag that catches up is still reported as `done`. The credit a
+  claim granted is its `credits`, or its `extra_credits` when it names
+  only that; Trae CN's claim usually names neither
+  (`{"code":0,"message":"success"}`), and then the read-back's `credits`
+  is the credit. The two are never added: the status carries
+  `extra_credits` beside `credits` (100 and 100 on a real account) while
+  the day gives 100.
 
 Only `api.trae.cn`'s `/trae/api/` pages are sent this way; any other URL
 that isn't a chat request is still refused (400). Needs 0.1.4 or later.

package/index.mjs

@@ -826,9 +826,16 @@ const ownClient = {
   paths: () => clientStoragePaths(process.platform, homedir(), process.env),
 }
 
+// CLIENT_PROFILES are the folder names a Trae CN client profile is kept
+// under: the IDE's own, and TRAE SOLO CN's, which is a client of the same
+// realm and signs in its own account. A profile started with its own
+// --user-data-dir is found only if it is one of these; there is no list of
+// them to read, and nothing is guessed from a folder's contents.
+const CLIENT_PROFILES = ["Trae CN", "TRAE SOLO CN", "trae-cn"]
+
 function clientStoragePaths(platform, home, env) {
   const file = (root, name) => join(root, name, "User", "globalStorage", "storage.json")
-  if (platform === "darwin") return [file(join(home, "Library", "Application Support"), "Trae CN")]
+  if (platform === "darwin") return CLIENT_PROFILES.filter((n) => n !== "trae-cn").map((n) => file(join(home, "Library", "Application Support"), n))
   if (platform === "win32") {
     // the two roots are often the same folder: APPDATA and the home's own
     // AppData\Roaming. They are compared as one system spells them, so a
@@ -840,19 +847,28 @@ function clientStoragePaths(platform, home, env) {
       if (roots.some((was) => spell(was) === spell(r))) continue
       roots.push(r)
     }
-    return roots.flatMap((r) => ["Trae CN", "trae-cn"].map((n) => file(r, n)))
+    return roots.flatMap((r) => CLIENT_PROFILES.map((n) => file(r, n)))
   }
-  if (platform === "linux") return ["trae-cn", "Trae CN"].map((n) => file(env.XDG_CONFIG_HOME || join(home, ".config"), n))
+  if (platform === "linux") return CLIENT_PROFILES.map((n) => file(env.XDG_CONFIG_HOME || join(home, ".config"), n))
   return []
 }
 
-// clientDevice is the device id of this machine's Trae CN client when the
-// client is signed in as uid, else undefined. It only reads: nothing of
-// the client's is written, kept or sent but that id, and the client's own
-// token is read past, never used. A file it can't read or make out, or one
-// with no single device, names no device, and the account keeps its own.
-// Never an id made up or changed: an account the client isn't signed in
-// as never gets the client's id.
+// clientDevice is the device id of a Trae CN client profile on this machine
+// that is signed in as uid, else undefined. It only reads: nothing of the
+// client's is written, kept or sent but that id, and the client's own token
+// is read past, never used. Never an id made up or changed: an account no
+// profile is signed in as never gets a client's id.
+//
+// A machine can hold more than one profile — Trae CN and TRAE SOLO CN each
+// write one, and a client started with its own --user-data-dir writes
+// another — and each profile's storage.json names the account it is signed
+// in as, with that account's device. So every profile is read and the one
+// signed in as uid answers with its device, which is what lets two accounts
+// each check in on a real client's device. A profile that isn't signed in
+// as uid, that can't be read or made out, or that names no single device
+// is passed over rather than ending the search: before, the first profile
+// read decided for all of them, so a second account's own profile was never
+// seen (and one unreadable file hid every profile after it).
 async function clientDevice(uid) {
   if (!uid) return undefined
   for (const p of ownClient.paths()) {
@@ -862,14 +878,19 @@ async function clientDevice(uid) {
     } catch {
       continue // not installed here
     }
+    let doc
+    try {
+      doc = JSON.parse(text)
+    } catch {
+      continue // not a file we can make out: the next profile may be
+    }
     try {
-      const doc = JSON.parse(text)
       const ids = Object.keys(doc ?? {}).filter((k) => k.startsWith(DC_KEY)).map((k) => k.slice(DC_KEY.length))
-      if (ids.length !== 1 || !/^\d{8,20}$/.test(ids[0])) return undefined
+      if (ids.length !== 1 || !/^\d{8,20}$/.test(ids[0])) continue
       const who = clientAuth(doc[AUTH_KEY])?.userId
-      return who != null && String(who) === String(uid) ? ids[0] : undefined
+      if (who != null && String(who) === String(uid)) return ids[0]
     } catch {
-      return undefined
+      continue // a sign-in that doesn't decode: the next profile may be
     }
   }
   return undefined
@@ -2572,13 +2593,16 @@ const MAX = "-max"
 // (light, high, extra_high) and the one it defaults to. The request takes the
 // same names, as reasoning_effort, so a level an agent picks is sent as Trae
 // spells it. OpenCode knows the three as low/high/xhigh, so the map goes both
-// ways.
+// ways. Trae's client names two more, medium and max (its bundle's
+// reasoning_effort.{low,medium,high,extra_high,max}), handed out per model:
+// its app offers DeepSeek V4.1 Flash max (#434), so they are spelled here too,
+// and still offered only for a model whose entry names them.
 //
 // An entry without the config takes no level: Trae serves it at its own
 // default and nothing is sent. The plugin used to send none for every model,
 // which read as "Trae takes no level" — it takes them, per model, and an
 // entry that names none is the exception rather than the rule.
-const LEVELS = { light: "low", high: "high", extra_high: "xhigh" }
+const LEVELS = { light: "low", medium: "medium", high: "high", extra_high: "xhigh", max: "max" }
 
 // levelsOf is an entry's levels in OpenCode's names, in Trae's order: [] when
 // the entry names none, null when it names ones this map can't spell (so a
@@ -2874,34 +2898,78 @@ const makePlugin = (site) => async ({ client }) => {
     return new Response(text, { status: res.status, headers })
   }
 
-  // checkin asks Trae CN's own pages as magpie's check-in host does, with
-  // the same account, device and renewal as any own page. Trae Global has
-  // no such page.
+  // checkinStatus reads the check-in's status page: its body, or an outcome
+  // to give back as it is (a turned-away sign-in, Trae's own error, a reply
+  // that isn't one). checkin reads it before the claim, and again after it.
+  const checkinStatus = async (getAuth, a0) => {
+    const res = await ownRequest(getAuth, a0, site.hosts.auth + site.checkin.status.path, "POST", "{}")
+    const text = await res.text()
+    let body
+    try { body = JSON.parse(text) } catch {}
+    if (!body || typeof body !== "object" || Array.isArray(body)) return { outcome: { outcome: "failed", message: `check-in status: unreadable reply ${text.trim().slice(0, 120) || "(empty)"}` } }
+    const e = errorOf(body)
+    if (res.status === 401 || lapsedCode(e.code, site)) return { outcome: { outcome: "failed", message: e.message || `${a0.name || a0.uid}: Trae's sign-in has expired` } }
+    if (res.status !== 200 || (e.code && String(e.code) !== "0")) return { outcome: { outcome: "failed", message: e.message || statusLine(res.status) } }
+    return { body }
+  }
+
   const checkin = async (getAuth) => {
     if (!site.checkin) return { outcome: "inactive", message: `${site.realm} has no daily check-in` }
     const a0 = fromAuth(await getAuth(), site)
     if (!a0) return { outcome: "failed", message: "not signed in" }
-    const base = site.hosts.auth + site.checkin.status.path
-    const status = await ownRequest(getAuth, a0, base, "POST", "{}")
-    const statusText = await status.text()
-    let body
-    try { body = JSON.parse(statusText) } catch {}
-    if (!body || typeof body !== "object" || Array.isArray(body)) return { outcome: "failed", message: `check-in status: unreadable reply ${statusText.trim().slice(0, 120) || "(empty)"}` }
-    const e = errorOf(body)
-    if (status.status === 401 || lapsedCode(e.code, site)) return { outcome: "failed", message: e.message || `${a0.name || a0.uid}: Trae's sign-in has expired` }
-    if (status.status !== 200 || (e.code && String(e.code) !== "0")) return { outcome: "failed", message: e.message || statusLine(status.status) }
-    if (body?.checked_in) return { outcome: "done", ...(Number(body.credits) > 0 ? { credit: Number(body.credits) } : {}) }
-    if (!body?.enable) return { outcome: "inactive" }
+    const first = await checkinStatus(getAuth, a0)
+    if (first.outcome) return first.outcome
+    const body = first.body
+    if (body.checked_in) return { outcome: "done", ...(Number(body.credits) > 0 ? { credit: Number(body.credits) } : {}) }
+    if (!body.enable) return { outcome: "inactive" }
     const claim = await ownRequest(getAuth, a0, site.hosts.auth + site.checkin.claim.path, "POST", "{}")
     const claimText = await claim.text()
     let answer
     try { answer = JSON.parse(claimText) } catch {}
     const ce = errorOf(answer)
     if (claim.status === 401 || lapsedCode(ce.code, site)) return { outcome: "failed", message: ce.message || `${a0.name || a0.uid}: Trae's sign-in has expired` }
+    // 9095: this device is in for today, whoever took it — the day's answer
     if (String(ce.code) === "9095") return { outcome: "ineligible", message: ce.message || "this device has checked in today" }
-    if (String(ce.code) === "9074") return { outcome: "ineligible", message: `${ce.message} — check in in the Trae CN app` }
+    // 9074: Trae did not take this claim for this account's device. Its own
+    // words say the pool is busy, which measurements do not bear out: the
+    // same account, token and headers were taken on a 16-digit id where a
+    // 19-digit one got 9074 (plugins#194), and on 2026-10-23 the same
+    // account and headers were taken on a device id Trae had never seen
+    // while this account's own id answered 9074. So the message says what
+    // Trae said and that the device is what it refused, rather than
+    // sending people to check in in Trae CN's app, which is not where the
+    // problem is. No device id is made up or rotated to get round this:
+    // the account keeps its own until a client of its own is here to sign
+    // it in. Nothing is said of signing one in: it is the one thing seen
+    // to change a 9074, but it hasn't been tried on a real account, and
+    // on a claim that already rode a client's device it is what the user
+    // did — the advice would only send them back to do it again.
+    if (String(ce.code) === "9074") return { outcome: "ineligible", message: `${ce.message} (9074) — Trae CN did not take this check-in for this account's device` }
     if (claim.status !== 200 || (ce.code && String(ce.code) !== "0")) return { outcome: "failed", message: ce.message || statusLine(claim.status) }
     if (!answer || typeof answer !== "object" || Array.isArray(answer)) return { outcome: "failed", message: `check-in claim: unreadable reply ${claimText.trim().slice(0, 120) || "(empty)"}` }
+    // a claim's own code 0 is not proof the day is in: Trae answers it for
+    // a claim that registered nothing, which cli2api works around by asking
+    // the status again (internal/providers/trae/checkin.go). So success is
+    // what the status page says after the claim, and one that didn't land
+    // is never reported as claimed.
+    //
+    // Nor is it a `failed`. magpie retries a failed check-in with backoff
+    // for the rest of the day, up to every 30 minutes, and each retry is
+    // another claim: a claim answered code 0 while the status still says
+    // the day is out is the very case that would multiply, since code 0
+    // for a claim that registered nothing is this plugin's own premise —
+    // an account that claimed once a day would claim many times. A status
+    // that lags a claim that did land reads as not in once, which is a
+    // false failure and a second claim. So once a claim has been sent,
+    // what the read-back says is the day's answer and nothing is claimed
+    // again: `ineligible`, as a 9095 is. A read-back that itself comes to
+    // nothing — the network, an answer that isn't one — is the same: the
+    // claim was made, and whether the day is in is not known, so it is
+    // read again on the next press rather than claimed again.
+    const noMore = (o) => (o.outcome === "failed" ? { outcome: "ineligible", message: `${o.message} — nothing is claimed again today` } : o)
+    const back = await checkinStatus(getAuth, a0)
+    if (back.outcome) return noMore(back.outcome)
+    if (!back.body.checked_in) return { outcome: "ineligible", message: `${site.realm}: the claim answered success, but the day's check-in is not in — nothing is claimed again today` }
     // The credit is the day's credits, never credits plus extra_credits.
     // Trae CN's real claim answers {"code":0,"message":"success"}, with no
     // credit at all (plugins#194), so the status's credits stand in. Its
@@ -2912,7 +2980,7 @@ const makePlugin = (site) => async ({ client }) => {
     // taken first; one naming extra_credits alone is that (#260). Either
     // may be absent, and Number(undefined) is NaN, which reads as none.
     const n = (v) => (Number.isFinite(Number(v)) ? Number(v) : 0)
-    const credit = n(answer.credits) || n(answer.extra_credits) || n(body.credits)
+    const credit = n(answer.credits) || n(answer.extra_credits) || n(back.body.credits)
     return { outcome: "claimed", ...(credit > 0 ? { credit } : {}) }
   }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@magpie-community/opencode-trae-auth",
-  "version": "0.2.21",
+  "version": "0.2.23",
   "description": "OpenCode provider plugins for Trae: Trae CN (trae.cn) and Trae Global (trae.ai), free tier included, with Trae's own browser sign-in",
   "type": "module",
   "main": "./index.mjs",