fix(openrouter): live settings on status checks, API key in the secret store

[gfsaaser24]

OpenRouter went stale, did not hold the API key, and never refreshed its model list.

Cause

makeProviderSnapshotSettingsSource captures the driver config at create time — mapSettings closes over the config it was seeded with, so every later status check re-probes with the config the instance was born with. That is harmless for drivers whose credentials live outside settings (Claude, Codex), but OpenRouter keeps its API key in that config, so a key saved after boot never reached the probe.

Observed on a live install: checkOpenRouterProviderStatus completing in 0.06 ms, i.e. the "no API key" short circuit, while the provider was configured.

Result: permanent "add an API key", model catalog stuck on the built-in fallback list, snapshot looking stale.

Changes

1. Live settings on every check. The status check now resolves the current config per run, preferring an explicit providerInstances entry over the legacy providers.openrouter block (matching ProviderInstanceRegistryHydration), and rebuilds the OpenRouter-owned process env from it. Falls back to the create-time config if settings are unreadable or fail to decode.

2. API key moves to the secret store. Keyed per instance as provider-<instanceId>-api-key (0600 files under the secrets dir), so multiple instances can hold different accounts. A key typed into settings still wins so an explicit edit applies at once; when settings carry one it is copied into the secret store. The secret store is an optional service, so the driver still builds where none is wired and falls back to the settings key.

Tests

OpenRouterSettingsPersistence.test.ts covers the schema round trip, whole-map replacement not dropping the key, instance-over-legacy precedence, key resolution order (including a trailing newline in the secret file), and per-instance secret naming.

25 OpenRouter tests pass; typecheck clean. ProviderRegistry.test.ts shows 20 failures on Windows against a 21-failure baseline on the same machine — pre-existing environmental, none added.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ad3d6079-338b-4138-873f-cd841f48e2f9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	12.6 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.3 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	51.8 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	16	—	21	✅
Claude	Total thread wire	—	12.6 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.3 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	52.7 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	16	—	21	✅

Baseline: unavailable · PR result: e939e29 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.