Account profile card degrades to "details not available" on a single transient fetch failure (no retry, memory-only cache)

[ShiTan-677]

What I see

Official desktop build (Electron app, 0.2.1-rc.3). Settings → Account shows "Signed in to DeepSeek" with the subtitle "Account details are not available yet" (账号资料暂不可用). Balance (¥32.74) renders fine, tasks run fine. About an hour later the profile came back on its own — no restart, no re-login.

Why it happens (measured on one machine)

The profile query and the balance query hit different Platform endpoints, and only one of them sits behind an edge challenge:

# profile → /auth-api/v0/users/current
curl -s -o /dev/null -w '%{http_code}\n' -A node \
  https://platform.deepseek.com/auth-api/v0/users/current
# at 15:51Z: 403, CloudFront "Request blocked" (repeatedly)
# at 16:55Z: 200 {"code":40002,"msg":"Missing Token"}   ← same machine, same UA

# same path, browser UA
curl -s -D - -o /dev/null -A 'Mozilla/5.0 … Chrome/141.0.0.0 Safari/537.36' \
  https://platform.deepseek.com/auth-api/v0/users/current
# 202 + x-amzn-waf-action: challenge

# balance → /api/v0/users/get_user_summary, no challenge
curl -s -A node https://platform.deepseek.com/api/v0/users/get_user_summary
# 200 {"code":40002,"msg":"Missing Token"}

So the edge can intermittently challenge or block GET /auth-api/* for non-browser clients. The host's request goes through Node's fetch; platformClientHeaders() sets five x-client-* headers but no User-Agent, so undici sends node, and platformRequest() classifies the resulting 403 as PlatformAuthError('network').

I am not asking anyone to defeat the challenge — the interesting part is what the UI does with a failure it cannot avoid.

What I think is worth fixing

1. A failed fetch and an account without contact info render the same sentence. In packages/client/ui-settings-account the status is profile?.contact ?? (details.profile === undefined ? 'loading' : 'profileUnavailable'), so { status: 'failed' } and contact: null both read as "Account details are not available yet", with no retry affordance. A distinct failure state ("couldn't load details — balance is unaffected") plus a retry button would make the card self-explanatory.
2. lastProfile is memory-only, so every launch starts with an empty cache and the card shows the placeholder until the first successful fetch. The code already binds the cache to the grant token; persisting it (still token-bound) would remove the "looks broken after every launch" case.
3. Optional, your call: whether the host should send an identifiable User-Agent (or whether Platform can exempt the DSH client from the challenge). I would rather report the behaviour than suggest working around the WAF.

Environment

• macOS, egress CloudFront LAX53-P5, DSH 0.2.1-rc.3 (desktop), password login valid, balance endpoint healthy.
• A third-party notification plugin was installed around the same time; it is unrelated — the same HTTP results reproduce with curl outside the app.

[NaleenB]

Additional data point from a native WKWebView launcher (macOS 27.0.1, dsh 0.2.1-rc.2, web profile): the host request succeeds when the browser's WAF cookie is included, so the profile read can be made reliable without defeating the challenge.

After signing in through the Web UI popup, the WebKit cookie store contains aws-waf-token for .deepseek.com. Repeating the same GET /auth-api/v0/users/current from the host process:

Request	Result
fetch with the headers DSH sends	403, CloudFront HTML block
Same + Safari User-Agent	202, x-amzn-waf-action: challenge, empty body
Same + the WebView's aws-waf-token cookie	200, JSON profile payload

So the sign-in popup already obtains the clearance; the host process just does not have it. Forwarding that cookie (with expiry/refresh handling), or performing the account reads in the renderer's browser context, would make the profile/balance calls work. At minimum, classifying the 403/202 as a WAF/challenge failure with a retry would be clearer than errorCode: 'network'.

auth_init shows the same intermittent 202 challenge during sign-in, which is why sign-in sometimes needs several clicks.

No tokens, keys, or account identifiers are included.