DeepSeek Harness account card unavailable: WAF cookie

"Account details temporarily unavailable", while the balance of ¥32.74 right below renders fine — that combination alone rules out an account problem. The profile lookup and the balance lookup hit two different endpoints, and only the former is intermittently stopped by the edge WAF (#11016). Three request comparisons narrow the difference down to a single cookie.

DeepSeek Harness: Experiment 1: same path, different User-Agent

Without a browser UA, the request may be blocked by CloudFront outright.

1. Request the profile API with node as the UA: curl -A node https://platform.deepseek.com/auth-api/v0/users/current.
2. At 15:51Z the reporter saw 403 with CloudFront's "Request blocked" page.
3. On the same machine with the same UA, at 16:55Z it became 200 with body {"code":40002,"msg":"Missing Token"} — the edge behavior itself is changing.
4. Switch to a browser UA and request again: 202 with x-amzn-waf-action: challenge.
5. Conclusion: this step is only "being challenged", not yet passing.

DSH plugin: Experiment 2: the balance endpoint on the same machine

The balance endpoint has no such challenge, which is why it returns normally.

1. Request https://platform.deepseek.com/api/v0/users/get_user_summary.
2. Even without credentials it returns 200 with body {"code":40002,"msg":"Missing Token"}.
3. That means this path does not go through the WAF challenge.
4. So "balance fine, profile unavailable" becomes an explainable phenomenon rather than a contradiction.
5. This step also rules out guesses such as "the whole site is unreachable".

DeepSeek Harness: Experiment 3: add the WebView's aws-waf-token

The same request with the same headers, plus one WAF cookie, goes from failing to 200.

1. The login dialog completes inside a WebView, after which WebKit's cookie store holds an aws-waf-token for .deepseek.com.
2. In other words, the challenge has already been passed and the credential is sitting in the WebView.
3. But the host process does not include it when sending requests, so every attempt is challenged again.
4. This is the only missing piece in the chain.
5. So either "forward this cookie (including expiry and refresh handling)" or "read account info inside the renderer's browser context" makes the profile return reliably.

DSH Plugin: Why the UI looks broken

The failure state and "the profile has no contact" render as the same sentence, and there is no retry entry.

1. The state logic is profile?.contact ?? (details.profile === undefined ? 'loading' : 'profileUnavailable').
2. So { status: 'failed' } and contact: null both display as "account details temporarily unavailable".
3. lastProfile lives only in memory, so every launch starts with an empty cache.
4. The result: a placeholder appears at startup, and if the first fetch fails it stays forever.
5. The reporter suggests distinguishing "read failed" from "no contact" and adding a retry button.

DeepSeek Harness: Conclusion and recommendations

This is not a restricted account but a host request missing the edge challenge credential; the changeable layers are the request side and the UI side.

1. Request side: forward the WebView's existing aws-waf-token to host requests and handle expiry and refresh.
2. Or: read account details inside the renderer's browser context.
3. Error classification: classify 403 / 202 as "WAF challenge failed" rather than network, so users and support can tell.
4. UI side: give the failure state its own copy and a retry button; make the cache persistent (still bound to the auth token).
5. Do not try to bypass WAF on the client — the reporter explicitly did not seek such a solution.

DSH plugin: One-minute test: is this the issue

All three signs together and you can stop: balance fine, profile unavailable, and it recovers by itself after a while.

1. Check the balance: if it displays, authorization and network are both working.
2. Check the profile: unavailable, but the copy says "temporarily" rather than "not signed in".
3. Check the timing: wait ten minutes to an hour and reopen; it may come back.
4. Check login: signing in again may restore it briefly, then it returns later.
5. Three or more hits and you can stop checking account status.

If you report it

The more specific the information for maintainers, the easier it is to locate the request side.

1. Include the profile API's response code and headers, especially x-amzn-waf-action.
2. State whether the balance API worked at the same moment.
3. State the client version and platform (desktop or web).
4. Note whether you signed in inside a WebView and whether the cookie store contains aws-waf-token.
5. Do not attach account identifiers, tokens, or any credentials.

Cautions

Check the balance endpoint as a control before suspecting the account.

1. Do not treat a working balance as full proof the account is healthy. The two endpoints take different paths.
2. Do not rush to reinstall or re-login. The reporter's profile recovered by itself an hour later.
3. Login needing several clicks has the same cause. auth_init hits the 202 challenge too.
4. Do not treat the WAF cookie as a long-lived credential. It expires and needs refresh logic.
5. Include response headers when reporting. x-amzn-waf-action explains more than the error copy.

If your profile card is "always unavailable" rather than intermittent, it is more likely a login-state issue — check the auth token rather than WAF.See Fix "Failed to fetch available models" 401 error in DeepSeek Harness for the related case.