Support unlimited named API-key provider instances - #470
Conversation
First-class API-key connects now ask for an instance name before the key, matching OAuth multi-account naming. Instances land as kind/slug catalog rows so a second key cannot silently overwrite the first; reusing a name confirms before replace.
TheGreatAxios
left a comment
There was a problem hiding this comment.
Critique
Lens: behavioral correctness and multi-instance safety
Verdict: approve
Summary: First-class API-key connects name instances before the key and store kind/slug catalog rows so a second key cannot overwrite the first; confirmed reuse updates in place, including legacy bare keys.
Findings: none.
Greybeard
Lens: architecture and documentation alignment
Verdict: approve
Summary: Reuses the OAuth multi-instance slug machinery (oauthProfile, suggest/confirm) for API-key kinds without pulling Custom into that path; PRODUCT/TUI/CHANGELOG describe the shipped behavior.
Findings: none.
gaasbot
Lens: public OSS / release readiness
Verdict: approve
Summary: UX, tests, and docs are contributor-readable; no secrets, machine paths, or private assumptions land in the tree.
Findings: none.
Summary
kind/slugcatalog rows so a second key cannot silently overwrite the first; reusing a name confirms before replace.Closes CL-5898.
Verification
bun run typecheckbun run buildbun run test(4541 pass, 0 fail)Notes
openai) still count as thedefaultslug and are updated in place on confirmed reconnect.