This is a clean, well-cut deletion. The env-based AI provider config was a second control plane for data the DB already owns via UI/API, and it's removed at the root: no dangling references to the removed symbols, go build/go vet green, the encryption-at-rest test was rewritten to seed via the API instead of being deleted, the LockIDAIProvidersEnvSeed iota slot is reserved rather than deleted (so advisory-lock IDs don't shift under a rolling fleet), and the GetAIProviders lock drop plus the backfill context de-detach are both correct now that the only seeder is gone. Hisoka put it well: "It is a boring, well-cut deletion, and boring is a compliment from me."

One finding blocks: the deprecated options weren't only env vars. Six of them (openai_base_url, anthropic_base_url, bedrock_base_url, bedrock_region, bedrock_model, bedrock_small_fast_model) had YAML names and non-empty defaults, so coder server --write-config emits them for every deployment. serpent hard-fails on unknown YAML keys and unknown flags (env vars alone are silently ignored), so a deployment that pins a written config file or passes a removed flag will not start after upgrade. This needs a human decision: keep the removed options as hidden, ignored stubs for one deprecation release (the codebase already does this for inject_coder_mcp_tools and CODER_AIBRIDGE_ENABLED), or document a required pre-upgrade config edit and call it out in the release notes.

Severity count: 1 P1, 2 P3, 2 Nit, 1 Note, 1 P4. The P4 is pre-existing and out of scope, flagged only so it isn't assumed to have a follow-up.

Process note: the PR description accurately inventories the diff but omits the one operator-facing consequence a release-notes author needs. Consider adding: "Operators must remove any provider CLI flags or YAML config keys before upgrading, or the server will not start; leftover env vars are ignored."

docs/ai-coder/ai-gateway/rebranding-migration.md:24

Nit [CRF-4] The "At a glance" table still promises every CODER_AIBRIDGE_* env var survives as a working alias, which is now false for the provider vars this PR removed. (Leorio)

The row reads Environment variables | CODER_AIBRIDGE_* | CODER_AI_GATEWAY_* | Yes (deprecated alias). A reader scans it, sees "old name still works," and keeps e.g. CODER_AIBRIDGE_ANTHROPIC_KEY, which now fails startup as a flag/YAML key and is silently dropped as an env var. The NOTE above states providers are removed, but the table contradicts it three lines later and tables get read first. Qualify the "still works?" cell: "Yes, except provider options (removed, see note above)."

🤖

docs/install/releases/esr-2.29-2.34-upgrade.md:190

Note [CRF-6] The ESR upgrade row still describes env seeding and drift-based startup failure as live, and cross-links to a providers.md page this PR rewrites to say the opposite. (Mafu-san P2, Netero/Mafuuu/Kite Note)

The row states env vars "seed the database once on first startup" and "Coderd fails to start if env vars drift from the seeded database row," then links to a page now saying these vars are "no longer supported." Downgraded from P2 to Note: the ESR guide is version-scoped to the 2.29-2.34 upgrade window, where seeding genuinely existed, and this removal ships in v2.36.0 (verified against the repo .version), so the row is accurate for its scope and the row's own Action column already directs operators to remove the env vars and manage providers via the DB. The residual issue is a cross-document mechanism-description drift that the release-notes owner for the removal version should reconcile, not a defect this PR introduces.

🤖

🤖 This review was automatically generated with Coder Agents.

Round 2. The round-1 fixes landed cleanly and I verified each: the providers.md WARNING block names the exact six YAML keys and both groups (checked against the golden config), the rebranding table now says "Yes, except provider setup," the dead //nolint is gone, and manifest.json dropped "seeds." The docs work is genuinely good; Leorio's words: "Whoever wrote this stopped guessing and opened the config." CRF-2 through CRF-5 are resolved.

One finding re-raised, and it's the P1. Six of the nine reviewers independently re-raised CRF-1 with new evidence the round-1 close didn't weigh: the documentation-only remedy does not change the parser behavior, so a config file that still carries any removed key still hard-fails startup on upgrade. The author's own WARNING confirms the blast radius is every operator who ran coder server --write-config, "even if you never configured an AI provider", not just AI Gateway users. That remedy lives on an AI-Gateway feature page an affected operator has no reason to open, and there is no v2.36 upgrade/release note carrying it, so unattended Helm/GitOps upgrades hit an outage with nothing pointing at the fix. Meanwhile the compat-shim pattern that makes the failure impossible already lives in this same file: aiGatewayProxyDomainAllowlist and inject_coder_mcp_tools are kept as Hidden: true, deprecated, parse-and-discard stubs ("Setting this value has no effect. This option will be removed in a future release."). The PR diverged from that pattern for the provider options specifically.

This is a breaking-change-policy decision that belongs to a human, not to the author or reviewer by default. Either keep the six options (and their flag/env forms) as hidden, ignored stubs for one deprecation release and delete them later, or consciously accept the upgrade outage and put a breaking-change entry in a v2.36 upgrade note so the warning reaches the people who hit it. A silent documentation-only close is not sufficient for a startup-outage-on-upgrade.

One new finding this round (P3): the consolidated test recut dropped the only end-to-end coverage of the bedrock provider-build path. Also verified and dropped: a claim that the env-var path never had a deprecation warning; warnIfAIProvidersConfiguredFromEnv existed at base and did warn, so the commit rationale is accurate. CRF-6 (ESR cross-doc, Note) and CRF-7 (vacuous subtest, P4) remain open with round-1 dispositions unchanged.

Severity count this round: 1 P1 (re-raised), 1 P3 (new).

🤖 This review was automatically generated with Coder Agents.

Round 3. The blocker is resolved and I'm dismissing the previous REQUEST_CHANGES. Both fixes landed and I verified each.

CRF-1 (the P1) is closed. The author took remedy (b), the path this panel named as acceptable in round 2: a breaking-change note carried by the canonical upgrade guide, reaching the operators who hit the crash. It now sits at the top of docs/install/upgrade.md, applies "even if you don't use AI Gateway," names the exact unknown flag/unknown option failure, and links a providers.md section that enumerates the six YAML keys. All three round-2 P1 re-raisers on the panel accepted it, and none could produce new evidence that the delivered remedy fails, so the re-raise gate isn't met. One residual is real and worth stating plainly: a fully-unattended GitOps upgrade that reads no docs will still crash-loop on first boot until a human removes the keys. That is inherent to any documentation remedy and was known when (b) was offered; the failure is loud, self-describing, and reversible (no data loss). The hidden+deprecated ignored-stub pattern already in this file (aiGatewayProxyDomainAllowlist, inject_coder_mcp_tools) remains the strictly-safer zero-outage option if maintainers want unattended upgrades to survive untouched. That's a maintainer call, not a blocker.

CRF-8 (bedrock coverage) is fully fixed. The consolidated test now adds a keyless bedrock row asserting it resolves to aibridge.ProviderAnthropic with a nil KeyPool, plus a BedrockWithoutSettings subtest pinning the credential-guard error. Five reviewers independently confirmed the previously-dead branch is now exercised on both paths. Bisky: "Root cause of the coverage gap, not the symptom. Clean."

Two new minor docs items this round (non-blocking): the upgrade-guide section is version-agnostic in a permanent guide, and the note references CLI flags while the linked section lists only YAML keys. CRF-6 (ESR cross-doc, Note) and CRF-7 (vacuous subtest, P4) remain open with their round-1 dispositions unchanged.

Severity count this round: 1 P3 (new), 1 Nit (new). No blocking findings remain.

🤖 This review was automatically generated with Coder Agents.

Round 4. Both round-3 docs findings are fixed at the root, and there are no blocking findings left on this PR. All seven reviewers verified the fixes.

CRF-10: the upgrade-guide section is now conditional ("If your deployment configuration still contains deprecated AI provider CLI flags or YAML keys, remove them before upgrading" plus "No action is needed if those options are absent"), so it no longer misdirects future upgraders whose configs never carried the keys.

CRF-11: the linked providers.md section now enumerates the CLI flags too. I had the panel check the list one-for-one against the removed options in codersdk/deployment.go: all ten --ai-gateway-* flags plus the ten --aibridge-* aliases and the six YAML keys are covered, and the flag-vs-YAML count asymmetry is correct (the four secret options have no YAML tag, so write-config never emits them). Pariston: "Nothing that can crash startup is missing from the instructions."

One optional Note remains (CRF-12): the 10-flag vs 6-key asymmetry is accurate but unexplained, so a reader cross-checking the two lists might wonder if the YAML list is short. One clause would remove the apparent gap. Not worth blocking.

For the record, two findings stay open and non-blocking, unchanged since round 1: CRF-6 (the ESR upgrade row's cross-doc drift, a release-notes owner's call) and CRF-7 (the pre-existing vacuous NonNilDeploymentValues subtest, out of scope for this PR). And the CRF-1 residual remains a maintainer's call: a fully-unattended GitOps upgrade that reads no docs still hard-fails on a config carrying the removed keys; the hidden-stub compat pattern already in this file is the zero-outage alternative if you want that path closed. None of these block.

The core change remains a clean, well-cut deletion. Nice work iterating it to this state.

🤖 This review was automatically generated with Coder Agents.