[Bug] ZCode after OAuth login only shows GLM-5.2 and GLM-5-TURBO in model picker — rest of Coding Plan models missing

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

账号 / 登录 · Account / Login

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

阻塞使用 · Blocking (无法使用核心功能 / core function unusable)

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

After signing in to ZCode via the official "Connect to Z.ai" OAuth flow (auth completes successfully, subscription is detected, no errors shown in UI), the model picker only exposes two models:

• GLM-5.2
• GLM-5-TURBO

None of the other models included in the active Coding Plan subscription are listed. This means the user cannot select glm-4.6, glm-4.5-air, glm-4.5-flash, or any other plan-covered model from ZCode's UI — even though those same models are available on chat.z.ai and via the /paas/v4 API under the same account.

Effectively, paying Coding Plan subscribers are restricted to a 2-model subset of their plan when working in ZCode, while the full plan catalog is available everywhere else. This makes it impossible to use the model tier the user actually paid for inside the desktop app.

复现步骤 · Steps to reproduce

1. Open ZCode desktop (clean install or after signing out).
2. Click "Connect to Z.ai" and complete the OAuth flow in the browser.
3. After the callback succeeds and ZCode shows the signed-in state, open a new conversation.
4. Open the model picker (top of conversation / settings).
5. Observe the available models: only GLM-5.2 and GLM-5-TURBO are listed.
6. (Sanity check) In the same browser session, open https://chat.z.ai — confirm the same account sees the full Coding Plan model catalog there.
7. (Optional) Hit https://api.z.ai/api/coding/paas/v4/models with the account's token — confirm the full model list is returned.

期望表现 · Expected behavior

After a successful OAuth login with an active Coding Plan, ZCode's model picker should display every model the plan grants access to — at minimum glm-4.6, glm-4.5-air, glm-4.5-flash, glm-5.2, glm-5-turbo, and any coding-tuned variants the user's plan tier covers. The list should match what the same account sees on chat.z.ai and via /paas/v4/models.

实际表现 · Actual behavior

Only GLM-5.2 and GLM-5-TURBO appear in the model picker. The rest of the Coding Plan's model catalog is missing — there is no error, no "loading more models" spinner, no explanation. The models simply aren't surfaced.

ZCode 版本 · ZCode version

(to be confirmed by reporter — please reply with the exact version string from ZCode → About. Latest known affected: v3.3.x.)

设备 / 系统 / 浏览器 · Device / OS / Browser

(to be confirmed — please reply with OS + version. Reproduced on at least one platform.)

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

(Screenshots of the ZCode model picker showing only 2 models, plus a side-by-side of chat.z.ai showing the full plan catalog, would make this issue trivially triageable — please attach if possible.)

Likely root cause (hypothesis)

The ZCode client appears to be fetching the model list from a different endpoint than chat.z.ai — possibly a hardcoded allowlist, a legacy /v4/models endpoint that only returns the two flagship models, or a Coding-Plan-scoped endpoint that's not being passed the correct plan identifier after OAuth.

Specifically, the OAuth callback resolves to a business_token (per the logs in #116), and that token is then used to call an entitlements / models endpoint. If the entitlements call is silently failing or returning a degraded response, ZCode may be falling back to a minimal hardcoded list (glm-5.2, glm-5-turbo) without surfacing the failure to the user.

Suggested debugging angle:

1. Capture the network request ZCode makes immediately after OAuth callback to fetch the model list.
2. Compare the response to the same call made by chat.z.ai for the same account.
3. If the responses differ, the bug is server-side (entitlements endpoint). If they're identical, the bug is client-side (ZCode is filtering the list down to 2 models locally).

Related

• #116 — Z.ai OAuth succeeds but ZCode fails with zai_oauth_required on Ubuntu. Same OAuth flow; different failure mode (token exchange fails outright there, here it succeeds but produces a degraded model list). Worth investigating together — both suggest the OAuth → entitlements handoff is fragile.
• #31 — New users shown "coding plan not activated." Same symptom family: plan entitlement isn't being correctly propagated into ZCode after auth. Different visible result, possibly the same underlying bug.
• #127 — Let paid Coding Plan subscribers spend their tokens inside chat.z.ai. This bug is the inverse failure of #127: instead of chat-side users being unable to use coding-plan quota, here coding-plan users (in ZCode) are unable to use coding-plan models. Both stem from the artificial split between the two surfaces.
• #122 — chat.z.ai: switch model mid-conversation. The model picker bug here makes #122 moot inside ZCode — you can't switch to a model that doesn't appear in the picker.

---

Regards,
Roman
http://www.rommark.dev
VIbe Coders Telegram Channel: https://t.me/VibeCodePrompterSystem

Start by capturing the request made after the OAuth callback and inspect the business_token and model-list response. Compare ZCode's request with chat.z.ai and https://api.z.ai/api/coding/paas/v4/models for the same account, then determine whether filtering occurs in the client or entitlement response. Done means the model picker exposes the plan-covered catalog or clearly reports the entitlement failure.