Remove default Gemini key pass-through from local MCP configs

Context

The 2026-06-08 Gemini cost incident showed that rotating/deleting a key stops immediate billing, but the local harness templates can still re-expose the same class once a new key is present. Local MCP server processes inherit GEMINI_API_KEY by default today, including servers that can perform synthesis work.

V-B-A evidence:

• .codex/config.template.toml:38 configures the Knowledge Base MCP server.
• .codex/config.template.toml:41-52 passes GEMINI_API_KEY into the Knowledge Base MCP server environment by default.
• .codex/config.template.toml:57 configures the Memory Core MCP server.
• .codex/config.template.toml:60-72 passes GEMINI_API_KEY into the Memory Core MCP server environment by default.
• Local ignored config copies mirror that shape, so restart alone can keep propagating a remote key into KB/Memory Core children unless the template and local copy are corrected.
• The incident session found NEO_MODEL_PROVIDER unset in local environments while GEMINI_API_KEY was present, which allowed provider-default remote calls.

Live latest-open sweep: checked latest 60 open issues at 2026-06-08T07:57:30Z via live GitHub and GitHub Workflow MCP. Targeted live search for GEMINI_API_KEY pass through spend cap returned no equivalent open issue. Related but non-equivalent tickets: #12740 incident epic, #12741 KB ask provider routing, #12743 spend reconciliation, #12742 summarization default-local.

Semantic duplicate sweep: used non-synthesis query_documents(type='ticket') because ask_knowledge_base synthesis is part of the incident surface. It surfaced historical harness/restart and provider-default tickets, but no open key-pass-through / spend-hygiene leaf.

The Problem

Local harness config currently treats GEMINI_API_KEY as a generic environment variable to pass into Agent OS MCP servers. That is too permissive after this incident.

A paid remote model key is not just a harmless credential. When it is present in a child process with provider defaults still pointing at Gemini, normal maintenance and knowledge-query paths can become billable remote API traffic. Worse, the hazard survives key rotation: the next valid key reintroduces the same spend path unless local pass-through is opt-in and the restart/key-clear procedure is explicit.

This is separate from provider routing. Even after #12741/#12742 make the default local, local templates should not expose paid remote keys to every server by default.

The Architectural Reality

• Codex Desktop local MCP config template is a repo substrate at .codex/config.template.toml; the ignored .codex/config.toml is operator-local and not committed.
• Knowledge Base and Memory Core are the relevant server blocks because they can run synthesis/summary work.
• Provider defaults are owned by AiConfig / ADR 0019, but key exposure is owned by harness config and local operator runbooks.
• The post-incident restart path must account for stale already-running MCP/orchestrator children: removing a key from the environment does not change processes that are already alive.

The Fix

Make paid remote key exposure explicit and operationally visible for local harnesses.

Expected implementation shape:

• Remove GEMINI_API_KEY from default local MCP server env_vars in .codex/config.template.toml unless a server truly requires it for a default local path.
• Provide an opt-in path for remote Gemini work, such as a documented local-only config override or a named remote-AI profile.
• Add a short restart/key-clear procedure for local incident recovery: clear key, restart affected MCP/orchestrator children, verify provider/key state, and confirm no stale process still carries the old key.
• Add a lightweight config/template guard if feasible so default local templates do not accidentally reintroduce broad paid-key pass-through.
• Record spend-cap / billing-alert expectation as operator-run guidance, not as code pretending it can configure Google Cloud billing.

Contract Ledger Matrix

Decision Record impact

aligned-with ADR 0019 for provider-default separation. This ticket does not add a new provider SSOT; it narrows which secrets local harnesses expose by default.

Acceptance Criteria

• Default Codex local MCP config template no longer passes GEMINI_API_KEY into Knowledge Base and Memory Core server blocks by default, or the PR documents a narrower exception with evidence.
• A documented opt-in path exists for local remote-Gemini work.
• A restart/key-clear procedure tells operators how to stop stale child processes and verify the key is no longer inherited.
• A guard or focused test prevents default local templates from reintroducing broad GEMINI_API_KEY pass-through silently.
• Spend-cap/billing-alert guidance is recorded as human-owned operational control without exposing secrets.
• The change does not remove explicit remote-provider support for deployments that intentionally use Gemini.

Out of Scope

• Provider-routing code changes (#12741, #12742).
• Quantitative cost reconciliation (#12743).
• Cloud Console automation; billing limits are human-owned unless a future operator-approved integration exists.
• Editing ignored local .codex/config.toml in the PR; local copies can be refreshed manually after merge.

Avoided Traps

• Assuming key deletion is durable protection. The next key would recreate the same inherited-secret hazard.
• Removing Gemini support entirely. The target is default local safety with explicit remote opt-in.
• Committing local secrets or private process command lines as evidence.
• Treating docs-only guidance as sufficient if the template still passes the key by default.

Related

Parent: #12740 Related: #12741, #12742, #12743, #12713

Origin Session ID: e8f07ef9-ef7e-4815-8ff4-7abe13720621 Retrieval Hint: "GEMINI_API_KEY env_vars Codex config template key clear restart spend cap incident"