fix(clients): include access.type in ZCode provider_config.json export

[codingbooo]

Summary

Closes #5861.

When exporting the managed OpenCodex block to ZCode 3.14+ provider_config.json, config.access was written as { apiKey: "..." } without the type: "api-key" discriminator. Because ZCode validates access as a discriminated union on type (api-key | zhipu-coding-plan-api-key | zhipu-account), the omitted discriminator caused a ZodError on launch, leading ZCode to discard the entire personal provider list.

This fix:

1. Adds type: "api-key" to ZcodeStoreProviderRule['config']['access'] and buildZcodeStoreProviderRule.
2. Updates regression test in tests/clients/integrations-current-store.test.ts to verify access.type === 'api-key'.

Verification

• bun run typecheck passed cleanly.
• bun test tests/clients/integrations-current-store.test.ts passed (12/12 pass, 60 expect calls).

Checklist

• Target branch is dev
• Followed repository TypeScript and testing guidelines
• Verified with focused regression tests

Review readiness checklist

This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:

• Required local validation passed; commands, results, and any full-suite exception are documented.

• I pushed my PR to a recent dev commit (at most 10 behind; a maintainer may still ask for the exact tip before merge).

• I resolved all correct Codex and CodeRabbit findings.

• My PR is ready for review.

Summary by CodeRabbit

• Bug Fixes
  • Updated store configuration to include the required API key access type, keeping it aligned with the expected format.
  • Added a test to verify the API key access type in store configuration.

[github-actions]

✅ Deterministic PR hygiene checks passed.

[github-actions]

⏳ DRAFT

• review readiness checklist open (0/4 boxes ticked).

What to do

• Tick all four boxes in the PR description once you're done (currently 0/4).

Review readiness checklist

• ⬜ Required local validation passed; commands, results, and any full-suite exception are documented.
• ⬜ I pushed my PR to a recent dev commit (at most 10 behind; a maintainer may still ask for the exact tip before merge).
• ⬜ I resolved all correct Codex and CodeRabbit findings.
• ⬜ My PR is ready for review.

0/4 boxes ticked.

This PR stays in draft until every box above is ticked.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: lidge-jun/opencodex/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: a55d51b8-6587-4141-96b2-4052f1e7bda9

📥 Commits

Reviewing files that changed from the base of the PR and between 08fd8a6 and 28d104e.

📒 Files selected for processing (2)

• src/clients/config-export/zcode-store.ts
• tests/clients/integrations-current-store.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The ZCode provider rule now includes the "api-key" discriminator in its access configuration. The integration test checks that the stored provider rule includes this value.

Changes

ZCode provider configuration

Layer / File(s)	Summary
Define, write, and verify API-key access src/clients/config-export/zcode-store.ts, tests/clients/integrations-current-store.test.ts	The provider rule type requires "api-key", and the generated rule writes it with the placeholder API key. The test asserts that the stored rule has this discriminator.

Priority: ➖ Normal

Estimated code review effort: 1 (Trivial) | ~5 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 28d10

This change adds the access discriminator to the ZCode 3.14+ provider store, while older versions use a separate export format. No actionable merge risk remains.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 28d10

The change appears limited to making the exported provider rule valid for ZCode. It does not change the configured endpoint or credential, but compatibility with ZCode’s actual reader has not been independently verified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — A valid ZCode rule can make this client’s existing OpenCodex endpoint usable where the prior rule was rejected. The changed builder does not select a new endpoint or extend the server’s admission policy.

Trust Boundaries and Controls

• observed — The existing request policy checks the Host on a loopback binding. The API admission policy treats loopback binding separately and requires a configured admission secret when API authentication is required; the exported placeholder is not itself such a secret.

Resilience and Maintainability Implications

• inferred — Existing ownership checks and compensation paths appear to contain failed or repeated store updates without adopting an unowned provider rule. A discriminator-specific failure fixture was not examined.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: adding config.access.type to the ZCode provider configuration export. It matches the implementation in `src/clients/config-export/zcode-sto…
Linked Issues check	✅ Passed	The direct coding requirement in [#5861] is implemented. src/clients/config-export/zcode-store.ts defines ZcodeStoreProviderRule.config.access with type: "api-key" and `buildZcodeStoreProviderRu…
Out of Scope Changes check	✅ Passed	The reviewed changes stay within [#5861]. The source change adds the required ZCode access discriminator and updates its TypeScript shape. The test change imports that shape and verifies the discrimin…
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[lidge-jun]

리뷰 · 우선순위 58 / 80

이 풀리퀘스트의 바탕은 dev예요. ZCode 3.14는 개인 제공자를 ~/.zcode/v2/provider_config.json에서 읽어요. ocx integration client enable --client zcode가 그 파일에 OpenCodex 칸을 넣는데, 열쇠 칸이 { "apiKey": "opencodex-loopback" }만 있었어요. ZCode는 access.type이 api-key, zhipu-coding-plan-api-key, zhipu-account 중 하나여야 그 문서를 받아요. 글자가 없으면 Zod 검사가 문서 전체를 버리고, 메모리에는 빈 목록을 올려요. 그래서 원래 쓰던 제공자까지 모델 고르기에서 사라져요. 이슈 #5861이에요.

고침은 그 칸에 type: "api-key"를 넣는 거예요. ZcodeStoreProviderRule과 buildZcodeStoreProviderRule이 같이 바뀌었어요. 열쇠 값은 예전과 같은 루프백 자리표시자예요. 옛 v2/config.json의 options.apiKey는 그대로예요. 그 파일은 클라이언트가 저장소를 만든 뒤에는 안 읽어요. src/types.ts와 src/config.ts 분리와는 무관해요. 닫을 중복 글은 없어요.

라인 - src/clients/config-export/zcode-store.ts의 buildZcodeStoreProviderRule — access.type만 채워요. 이슈가 두 번째로 적은 config.providerOrder에는 opencodex를 넣지 않아요. 이 함수가 쓰는 조각은 providerRules 한 칸과 모델 규칙이에요. providerOrder는 그 바깥 배열이에요.

라인 - tests/clients/integrations-current-store.test.ts 139행 — toEqual(buildZcodeStoreProviderRule(...))는 쓴 결과와 빌더가 같은지만 봐요. 빌더에서 type을 빼면 양쪽이 같이 빠져서 그 비교는 통과해요. 바로 아래 access.type이 "api-key"인지 보는 줄이 그 글자를 잠가요.

메인테이너의 판단이 필요한 지점

providerOrder를 이 글에서 같이 고칠지 정해 주세요. 검사 실패로 목록이 통째로 비는 버그는 type만으로 막혀요. 고친 뒤에도 OpenCodex가 고르기에 안 보이면, 그때 providerOrder에 opencodex를 붙이면 돼요.

설명 위쪽 체크 세 칸은 켜져 있어요. 아래 자동 블록 네 칸은 비어 있어요. 이 글은 아직 초안이에요. 초안 게이트는 아래 블록을 봐요.

너의 추천

type: "api-key" 변경은 두세요. 테스트의 access.type 확인도 두세요. 바탕은 dev로 두세요. 닫을 중복 글은 없어요. providerOrder는 모델이 다시 보이는지 본 다음 따로 다루세요. 아래 체크 네 칸을 채우고 초안을 풀면 리뷰 준비가 끝나요.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Thanks! This landed on dev through the bug-PR merge train batch #5901 (merge dd1e327). Your change was carried as one squashed commit that keeps you as the commit author, with a Co-authored-by trailer. Closing this PR since its content is now on dev.