Alibaba Token Plan: BailianGateway.Workspace.NotAuthorised for INTL Personal/Solo (sec_token not resolving)

[Yula-J]

CodexBar version: 0.48.0
Provider: Alibaba Token Plan, Region: International Personal/Solo (Singapore)
Account: Alibaba Cloud Model Studio, Personal Token Plan (Individual), international

Steps taken:

Confirmed valid login on the dashboard host (bailian.console.alibabacloud.com → redirects to modelstudio.console.alibabacloud.com; the redirect lands on cn-beijing, but the actual subscription lives in the Singapore region)
Freshly captured cookies from the subscription page (.../cn-beijing?tab=plan#/efm/subscription/token-plan, Singapore region) and registered them under Token accounts → Personal
Result: Consistently getting:

Alibaba Token Plan API error: BailianGateway.Workspace.NotAuthorised

Relevant doc note: docs/alibaba-token-plan.md states this error occurs for "some accounts" when the dashboard sec_token fails to resolve. This account appears to be exactly that case.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 12, 2026, 12:02 PM ET / 16:02 UTC.

Summary
The reported v0.48.0 flow predates the Personal/Solo implementation shipped in v0.49.2, which resolves and sends sec_token; retain this new report until the International Personal/Solo path is verified on the current release.

Reproducibility: no. high-confidence current-main reproduction is available: the report is from v0.48.0 and the live international account flow cannot be exercised without its authenticated session.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A redacted current-version result is needed to distinguish the superseded v0.48.0 path from a remaining international account-specific failure.

Review details

Best possible solution:

Confirm the behavior on v0.49.2 with the International Personal/Solo region and a redacted quota-request trace; if it still fails, extend the token/redirect handling and add an international regression fixture.

Do we have a high-confidence way to reproduce the issue?

No high-confidence current-main reproduction is available: the report is from v0.48.0 and the live international account flow cannot be exercised without its authenticated session.

Is this the best way to solve the issue?

Unclear: v0.49.2 contains the targeted token-resolution path, so upgrading and collecting a redacted current-version trace is the narrowest next step before changing the provider again.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reported account has not been retried on v0.49.2 or current main, so a remaining international redirect or cookie-scope incompatibility is unverified.
• The live provider contract requires an authenticated account; fixture coverage does not establish the International Personal/Solo route for this account class.

Codex review notes: model internal, reasoning high; reviewed against c4ed34d0e44a; fix evidence: release v0.49.2, commit 330ae4384b18.

Label changes

Label changes:

• add P2: The provider's documented Personal/Solo usage workflow is unavailable for the reported account, but no current-release regression has been established.
• add impact:auth-provider: The failure concerns cookie-based provider authentication and security-token resolution for Alibaba Token Plan.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: The provider's documented Personal/Solo usage workflow is unavailable for the reported account, but no current-release regression has been established.
• impact:auth-provider: The failure concerns cookie-based provider authentication and security-token resolution for Alibaba Token Plan.

Evidence reviewed

What I checked:

• Current Personal/Solo flow: Current main resolves a dashboard security token before the Personal/Solo usage request, while retaining a cookie-only fallback when no token can be found. (Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift:134, 330ae4384b18)
• Token is sent to the gateway: The request builder appends the resolved security token and deliberately omits a captured workspace agent so the gateway selects the account's default workspace. (Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift:453, 330ae4384b18)
• Release coverage: v0.49.2 contains the current fetcher and provider documentation, including the documented International Personal/Solo quota host and token-resolution behavior. (docs/alibaba-token-plan.md:38, 330ae4384b18)
• Focused test coverage: Tests cover a Personal/Solo security-token lookup and request construction, including the workspace-authorization payload shape, but the full successful fetch fixture is mainland rather than an authenticated international account. (Tests/CodexBarTests/AlibabaTokenPlanProviderTests.swift:549, 330ae4384b18)
• Maturity label unavailable: The required shortlist helper could not load the repository maturity scorecard, so no stable-maturity label is supported. (qa/maturity-scores.yaml)

Likely related people:

• Peter Steinberger: Blame attributes the token-resolution, request construction, and provider documentation included in v0.49.2 to this release snapshot. (role: introduced current Personal/Solo provider flow; confidence: high; commits: 330ae4384b18; files: Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift, docs/alibaba-token-plan.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.