feat: configurable Pi provider priority for OpenAI web search

[hank-warren]

openai-search.ts hardcodes which Pi providers it resolves auth from:

const SEARCH_PROVIDERS = ["openai-codex", "openai"] as const;

Since openai-codex is tried first and wins whenever it's signed in, there's no way to route search spend anywhere else — e.g. to a metered openai API key instead of the Codex subscription's weekly limit, or to a second Codex account slot registered via pi.registerProvider() (my case: I keep a separate account for background/automation traffic and wanted web_search billed there rather than against my main subscription).

Everything downstream of the list already generalizes: auth resolves through getApiKeyAndHeaders, the endpoint is chosen by inspecting the token (isCodexJwt), and chatgpt-account-id is extracted from the JWT itself. The provider list is the only hardcoded piece, so this PR just makes it configurable:

{ "openaiSearchProviders": ["openai-codex-work", "openai-codex"] }

Purely additive:

• unset → exactly today's behavior (["openai-codex", "openai"])
• entries that aren't registered or signed in are skipped by the existing loop
• [] skips Pi credentials entirely, so the openaiApiKey / OPENAI_API_KEY fallback applies (useful for "signed into Codex, but bill searches to my API key")
• anything that isn't an array of non-empty strings fails with the same error style as the other config fields

Added two tests in test/search-providers.test.mjs covering priority order (including skipping an unregistered entry) and config validation. npx tsc and node --test pass, plus a README note and a changelog line.

[greptile-apps]

Greptile Summary

The PR makes Pi provider priority configurable for OpenAI web search while preserving the existing default order.

• Adds validated openaiSearchProviders configuration, including support for an empty list that forces API-key fallback.
• Applies the configured order to authentication and availability checks.
• Adds priority, unregistered-provider, and malformed-config coverage.
• Documents the new option in the README and changelog.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
openai-search.ts	Adds unconditional provider-list validation and routes Pi credential resolution through the configured priority order; the previously reported context-gated validation issue is fixed.
test/search-providers.test.mjs	Covers provider priority, skipping an unregistered provider, and malformed configuration with and without an extension context.
README.md	Documents defaults, priority behavior, skipped providers, and empty-list API-key fallback.
CHANGELOG.md	Records the new configurable OpenAI search provider priority.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Load web-search configuration] --> B[Validate openaiSearchProviders]
    B --> C{ExtensionContext available?}
    C -->|Yes| D[Try configured Pi providers in order]
    D --> E{Pi credentials resolved?}
    E -->|Yes| F[Use selected Pi provider credentials]
    E -->|No| G[Try configured or environment OpenAI API key]
    C -->|No| G
    G --> H{API key available?}
    H -->|Yes| I[Use API-key credentials]
    H -->|No| J[Report OpenAI search unavailable]

Loading

_{Reviews (3): Last reviewed commit: "fix: validate openaiSearchProviders on t..." | Re-trigger Greptile}

[hank-warren]

Fair catch on the context-gated validation — malformed openaiSearchProviders could silently fall through to the API-key path when no extension context was passed. Fixed in 898ad77: the config is now validated unconditionally in both resolveOpenAIAuth and isOpenAISearchAvailable, matching how openaiResponsesUrl is handled. Extended the invalid-config test to cover the context-free path and assert no request is ever sent with the fallback key.