Summary
Make Brave search key config symmetric with other providers by using tools.web.search.brave.apiKey as the primary path, while keeping tools.web.search.apiKey as a backward-compatible alias
- src/agents/tools/web-search.ts: resolveSearchApiKey should read
search.brave.apiKey first, then alias fallback
- src/commands/onboard-search.ts:
applySearchKey and resolveExistingKey should write/read canonical Brave path and support alias read
- src/config/zod-schema.agent-runtime.ts: add
search.brave.apiKey; keep top-level search.apiKey accepted for compatibility
- src/config/schema.labels.ts: update Brave label to canonical nested key
- src/config/schema.help.ts: update help text to canonical key + compatibility note
- src/secrets/target-registry-data.ts: add
tools.web.search.brave.apiKey target
- src/secrets/runtime-config-collectors-core.ts: collect canonical Brave key (plus alias fallback during migration)
Compatibility behavior:
- Read canonical first, then alias.
- Write canonical only (onboarding/new config)
Problem to solve
Brave is the only search provider using the top-level key path (tools.web.search.apiKey), while others use tools.web.search..apiKey. This asymmetry creates avoidable config confusion and special-case code paths in onboarding, schema/help labels, secret targets, and runtime collectors
Proposed solution
Adopt tools.web.search.brave.apiKey as the canonical Brave key path and keep tools.web.search.apiKey as a deprecated fallback alias for backward compatibility
Alternatives considered
Keep current special-case top-level Brave key. Rejected because it preserves inconsistency, there are 5 other search options!
Impact
Affected: users configuring web search providers and maintainers touching config/runtime/secrets code
Severity: Medium
Frequency: Whenever web search is configured or onboarding/search tooling is changed
Consequence: Higher support/debug cost and increased chance of key-path misconfiguration
Evidence/examples
resolveSearchApiKey fallback to BRAVE_API_KEY
- schema/help text references “Brave Search API Key” and top-level path
- other providers are nested under
search.<provider>.apiKey
Additional information
No response
Summary
Make Brave search key config symmetric with other providers by using tools.web.search.brave.apiKey as the primary path, while keeping tools.web.search.apiKey as a backward-compatible alias
search.brave.apiKeyfirst, then alias fallbackapplySearchKeyandresolveExistingKeyshould write/read canonical Brave path and support alias readsearch.brave.apiKey; keep top-levelsearch.apiKeyaccepted for compatibilitytools.web.search.brave.apiKeytargetCompatibility behavior:
Problem to solve
Brave is the only search provider using the top-level key path (tools.web.search.apiKey), while others use tools.web.search..apiKey. This asymmetry creates avoidable config confusion and special-case code paths in onboarding, schema/help labels, secret targets, and runtime collectors
Proposed solution
Adopt tools.web.search.brave.apiKey as the canonical Brave key path and keep tools.web.search.apiKey as a deprecated fallback alias for backward compatibility
Alternatives considered
Keep current special-case top-level Brave key. Rejected because it preserves inconsistency, there are 5 other search options!
Impact
Affected: users configuring web search providers and maintainers touching config/runtime/secrets code
Severity: Medium
Frequency: Whenever web search is configured or onboarding/search tooling is changed
Consequence: Higher support/debug cost and increased chance of key-path misconfiguration
Evidence/examples
resolveSearchApiKeyfallback toBRAVE_API_KEYsearch.<provider>.apiKeyAdditional information
No response