Proposal: host-authenticated, consent-gated automatic model dispatch for Codex

Open 💬 1 comment Opened Jul 24, 2026 by SizheCheng
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

I am proposing a host-owned integration point for consent-gated automatic model dispatch in Codex. A local router should remain advisory by default and must never self-authorize a model switch.

Problem

Task complexity profiles can make automatic model selection useful, but a local component cannot safely decide whether a real Codex model launch is permitted. That decision depends on host-owned facts including the signed-in account or workspace entitlement, the current model catalog, explicit user consent, launch identity, and auditability.

Proposed direction

Provide a host-authenticated capability interface that is injected by Codex and remains owned by the host. A preparation request would be fail-closed unless the host validates a short-lived capability bound to:

  • the component identity and audience;
  • repository and invocation context;
  • requested model and command scope;
  • explicit user consent and current entitlement/catalog;
  • expiry and a replay-resistant nonce; and
  • the host process responsible for the actual launch.

The local router would only emit an advisory decision and a prepared request. It would have no local signing key, no fallback issuer, and no ability to bypass the host verifier or launch a model itself.

Local evidence

An offline R17 candidate was validated locally with the following redacted results:

  • 9 host-capability conformance vectors, covering verifier absence, identity/context/command drift, expiry, and authorization that outlives its capability;
  • 29 JSON contract documents loaded successfully;
  • 17 focused tests passed; 317 full tests passed both in the source candidate and in a fresh clean clone;
  • patch application and changed-file SHA-256 reproduction checks passed;
  • offline runtime self-test recorded 0 product-model starts and 0 network requests; and
  • privacy validation passed. No prompts, credentials, raw ledger records, or local paths are included here.

Candidate patch SHA-256: 815e57acf52c9436e372f3543055abb629f6c8586264a6da7be7148dfeacf7db

Request for maintainer direction

  1. Is a host-authenticated, consent-gated model-dispatch capability a direction the Codex team would consider?
  2. If so, where should the public extension point and data model live across Codex surfaces?
  3. What additional consent, entitlement, catalog, telemetry, or security requirements should the capability contract include?
  4. If the direction is accepted, would the team invite a minimal PR limited to the contract and adapter surface?

Non-goals

  • This is not a request for a local hook, configuration file, or Router JSON to gain model-launch authority.
  • This does not change routing policy, install anything, deploy anything, or request network access from the component.
  • This proposal intentionally leaves issuance, verification, consent, entitlement, catalog selection, and process launch under Codex host control.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34278
  • #34388

Powered by Codex Action