pydantic-settings-guard-must-share-source
When a guard function fail-closes on a config flag (e.g., provider name, region, mode), the guard MUST read through the same Settings layer as the value it’s protecting. Common bug: guard reads os.getenv("FLAG") directly while the paired value reader uses settings.flag via Pydantic. Pydantic Settings loads .env files and resolves secret:// URIs at boot — os.getenv sees only literal shell exports. An operator setting the flag via .env will bypass the guard silently (guard sees default; value reader sees real value). The Codex round-7 finding on r-dash wave-16 caught exactly this pattern in _assert_provider_supported() vs _token(). Fix: route the guard through settings.<flag> so both reads share one source. Audit rule: grep -n "os.getenv" apps/api/app/modules/**/*.py — any hit that mirrors a Settings field is suspect.