[Bug]: ZCode 3.14 integration writes provider_config.json entry without access.type — ZodError discards all personal providers (no models available) #5861

Client or integration

Other — ZCode (Z.ai desktop client 3.14.3.7762), via ocx integration client enable --client zcode

Area

Other — client integration / provider-config writer (ZCode v2 provider store)

Summary

After enabling the managed ZCode integration, ZCode lists no models at all — including the pre-existing personal providers that worked before.

The managed entry OpenCodex writes into ~/.zcode/v2/provider_config.json stores its key under config.access without the type discriminator. ZCode validates access as a union on type (api-key | zhipu-coding-plan-api-key | zhipu-account); a single invalid entry fails validation of the whole personal-provider document, so ZCode keeps the file on disk but degrades to an empty in-memory config. Every personal provider disappears from the model picker.

Reproduction

1. Have ZCode 3.14 working with personal providers in ~/.zcode/v2/provider_config.json (entries shaped "access": { "type": "api-key", "apiKey": "..." }).
2. Run ocx integration client enable --client zcode (2.65.0), or toggle the ZCode integration in the dashboard.
3. Restart ZCode and open the model picker -> no models.
4. ZCode log (~/.zcode/v2/logs/<date>.log) shows:

[provider-config] Personal Provider Config 加载失败，已保留磁盘状态并以内存空配置降级
{"error":{"name":"ZodError","message":"[{\"code\":\"invalid_union\",\"errors\":[],\"note\":\"No matching discriminator\",\"discriminator\":\"type\",\"options\":[\"api-key\",\"zhipu-coding-plan-api-key\",\"zhipu-account\"],\"path\":[\"providerRules\",5,\"config\",\"access\",\"type\"],\"message\":\"Invalid discriminator value. Expected 'api-key' | 'zhipu-coding-plan-api-key' | 'zhipu-account'\"}]"}}

providerRules[5] is the injected opencodex entry.

Version

2.65.0

Operating system

Windows 11 Home China (10.0.26200)

Logs or error output

See the ZodError above. Before/after inspection of the managed entry:

• written by ocx: "access": { "apiKey": "opencodex-loopback" } (no type)
• every other provider in the same file: "access": { "type": "api-key", "apiKey": "..." }

Adding "type": "api-key" to the managed entry is what makes the document valid again.

Redacted configuration

{
  "providerId": "opencodex",
  "enabled": true,
  "providerName": "OpenCodex",
  "config": {
    "group": "standard-personal",
    "access": { "apiKey": "opencodex-loopback" },
    "api": { "type": "openai-responses", "baseUrl": "http://127.0.0.1:10100/v1" },
    "personalModelIds": ["..."],
    "modelOrder": ["..."]
  }
}

Suggested fix

• In the ZCode provider_config.json writer, emit "type": "api-key" inside the managed provider's access object (matching every other provider entry).
• Secondary: config.providerOrder is not updated to include opencodex; consider appending the managed provider id when writing.

Workaround

Add "type": "api-key" to the managed entry and restart ZCode, or run ocx integration client disable --client zcode to restore the file.

Related: #5348 (that one covered writing to the legacy config.json; this is the current provider_config.json store being schema-invalid).

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.