fix(trae): send the aha device id shape the checkin backend expects - #206
Merged
caigee-cmd merged 2 commits intoSep 19, 2026
Merged
Conversation
The UG checkin backend keys its per-device daily limit on X-Device-Id and answers a bare hex id with code 9074, whose message reads as a rate limit but is a device-identity refusal. EnsureDevice issues randomHex(16) and SetUgHeaders forwarded it verbatim, so every browser-login account fails to check in even though the claim flow itself is correct. Trae's own client sends aha-<hex>. Normalising in SetUgHeaders keeps existing credentials working without a re-login and keeps distinct ids distinct, so each account still maps to its own device.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes Trae CN check-in, which currently cannot succeed for any account added through the login flow.
The problem
EnsureDevicefills an emptydevice_idwithrandomHex(16):SetUgHeadersthen forwards it verbatim asX-Device-Id. The UG check-in backend keys its per-device daily limit on that header and answers a bare hex id with:The message reads as a rate limit, so it looks like the service is simply busy — but retrying never helps, and it happens at every hour of the day. The device dimension is the real axis. Same account, same token, same host, seconds apart:
X-Device-Idsent3ee0250fe3e0e6e03cdd8054e3a01a7b(what a login-flow credential holds)9074 当前参与用户太多aha-b9efcd18de307d33417bce2b3e27a0b2{"code":0,"message":"success"}aha-cfac6e546e2386ec29e13335393d79dc{"code":0,"message":"success"}1800324722220809(the Trae client's own id, already used today)9095 当前设备今日已经签到Trae's own client sends
aha-<hex>—[ICDRS] did: 1800324722220809, ldid: aha-d1f737a30c4f966fbca6b0e7ad1718cein its logs — which is why the client checks in on the same machine while cli2api does not.One detail worth knowing while reading the status envelope: it carries
did_checked_inalongsidechecked_in. That second flag is the per-device state, and it is what the client's UI shows as "当前设备今日已经签到".The fix
SetUgHeadersnormalises the stored id to theaha-<hex>shape before sending. Only the UG endpoints are affected — login URLs and the SOLO/chat headers keep the raw value, so nothing else changes behaviour.Existing credentials work as-is: no re-login, no migration. Distinct ids stay distinct, so the one-device-one-account-per-day rule still holds.
Test plan
go test ./...— all packages pass on this branch (d574006+ these two commits)go vet ./...cd worker && npm test— 77 pass, 0 failcd frontend && npm run build && npm run lint— build ok, 0 errors (warnings are pre-existing)changelog/unreleased/trae-checkin-device-id.md(python scripts/release-notes.py validatepasses)Live verification
Checked against the running service with four Trae CN accounts: a bare hex device id returns
9074on every claim, the same id prefixed withaha-returns{"code":0}and the account flips tochecked_in: true.