Repository navigation
[Security] Changing providers reuses the previous provider's API key #312
Description
Description
Changing the configured provider does not clear or re-scope the existing API key. Both the interactive init flow and config set provider ... can carry a key issued for the old provider into the new provider configuration.
This can cause commit-echo to send a credential to the wrong upstream service, and it makes provider switches fail in confusing ways when the old credential is rejected.
Location
src/commands/init.ts:148-157—promptApiKey()src/commands/config.ts:86-101—applyProviderChange()
Relevant code
// init.ts
const existingKey = existingConfig?.apiKey ?? process.env[provider.apiKeyEnv] ?? '';
...
return keyResult || existingKey || '';
// config.ts
function applyProviderChange(config: Config, provider: Config['provider']): Config {
const nextConfig = updateConfigField(config, 'provider', provider);
if (provider === CUSTOM_PROVIDER_KEY) return nextConfig;
return {
...nextConfig,
baseUrl: undefined,
};
}The provider-change path clears baseUrl when appropriate, but leaves apiKey untouched. The init wizard also treats the existing stored key as reusable without checking whether it belongs to the newly selected provider.
Steps to Reproduce
- Configure provider A with API key A.
- Re-run
commit-echo initand switch to provider B. - Leave the API-key prompt blank.
- The resulting config still contains API key A, and
resolveApiKey()uses the stored key for provider B. - The same stale-key behavior is reproducible with
commit-echo config set provider <provider>.
Expected Behavior
A provider switch should require a key appropriate for the selected provider, or explicitly preserve a key only when the user confirms it is reusable. Stored credentials should not silently cross provider boundaries.
Actual Behavior
The previous provider's key is retained and can be sent to the new provider endpoint.
Suggested Fix
Track the provider that a stored credential belongs to, or clear apiKey whenever the provider changes and resolve the new provider's key from its configured environment variable. The init wizard should distinguish an existing key for the selected provider from a key belonging to another provider.
Impact
Provider reconfiguration can send the wrong secret to an unrelated third-party API endpoint and can leave the CLI configured with an invalid credential for the selected provider.
Reviewed against current main at 6c01ad0a853501e9617a3af0a5db3b515dd8ed53.
Activity
404-Page-Found commentedon Sep 22, 2026
Triage update
Validated against
mainat335fda84f3f57242e03d891749c597caa6d42bd5.commit-echo initandcommit-echo config set provider <provider>.resolveApiKey()prefers the persistedconfig.apiKeyover the newly selected provider's environment variable, so the old secret can be sent to the new provider endpoint.p1label remains appropriate for the security impact; no label change made.init, but does not by itself resolve provider/key provenance. Its implementation should be coordinated with this issue.Fix guidance
Prefer explicit credential provenance (associate a stored key with its provider and only reuse it for the same provider). A simpler mitigation is to clear the stored
apiKeywheneverproviderchanges and resolve the new provider's key from its environment variable.Add regression tests covering provider switches through both
initandconfig set, including fallback to the newly selected provider's environment variable.fix: scope init API keys to selected provider (#312)
fix: clear API key when changing provider (#312)
test: cover provider-scoped init API keys (#312)
test: cover provider-switch API key fallback (#312)
404-Page-Found commentedon Sep 22, 2026
Implemented in PR #321: provider changes now clear persisted API keys, and
initonly reuses a stored key when its saved provider matches the selected provider. Otherwise it falls back to the selected provider's environment key. Regression coverage was added for both flows. The latest GitHub Actions CI run is in progress; Ubuntu has already passed format check and all 438 tests, while macOS/Windows are still running.fix: scope API keys to configured provider (#321)