MCP request metadata omits the issuing step's effective service tier

Aperta Adatta ai principianti
  • Qualcosa non va?
#59,838 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
77/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend-api-design

Direzione di ricerca

Inizia in codex-rs/core/src/mcp_tool_call.rs, in build_mcp_tool_call_request_meta, e verifica come costruisce i metadati a partire da ResolvedStepSettings.service_tier del passaggio acquisito. Leggi prima la costante Default esistente del protocollo e i test correlati di tool_call_request_meta. Il lavoro è terminato quando i metadati riportano esplicitamente default se il livello acquisito è assente, le stringhe dei livelli diversi da default vengono conservate e i test mirati passano.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug mcp subagent
What issue are you seeing?

MCP tool calls do not carry the issuing step's effective service tier. A delegated worker can therefore select a faster tier from its own configuration even when its launching turn uses Default.

This is the remaining host-side integration behind codex-security#2171. The consumer fix in codex-security#2231 already reads _meta["codex/turn-service-tier"] and persists it for fresh and resumed workers.

What steps can reproduce the bug?
  1. Configure a worker home with a non-default tier, such as service_tier = "priority".
  2. Launch an MCP-backed worker from a turn whose effective speed is Default.
  3. Inspect the MCP tools/call metadata. The host forwards model and reasoning settings but omits codex/turn-service-tier.
  4. A consumer that falls back to its own configuration when that field is absent selects the configured tier instead of the launching turn's Default.

The source-level regression is smaller: build the production MCP request metadata from a captured step with settings.service_tier = None. The required field should be "default"; the current builder does not emit it.

What is the expected behavior?

MCP metadata should include the captured issuing step's effective tier. Default should be explicit, so the consumer can override its own faster configuration. Non-default tier strings should pass through unchanged. A later step's settings must not alter metadata for an earlier captured step.

Additional information

Root cause: build_mcp_tool_call_request_meta does not emit this field, although the effective value is already available in ResolvedStepSettings.service_tier. I inspected both rust-v0.166.0 and main at faeb379646bdbad016e11f7c9ca91113cad4bc9d.

Tested proposed patch: commit and diff, patch file.

The patch emits the host-owned field from the issuing step and uses the existing protocol Default constant for an absent effective tier. Tests cover Default, non-default and future tier strings, captured-step stability, and metadata for custom servers, plugins, Apps, and guardian calls.

Validation:

  • cargo +1.95.0 test --locked --profile ci-test -p codex-core --lib tool_call_request_meta: 13 passed, 0 failed on Windows x64.
  • Codex Security's targeted runtime-settings/store checks: 10 passed.
  • Pinned Rust formatting and diff checks passed.
  • The fork's required Rust CI gate passed. Advisory Bazel checks were unsuccessful on the fork: Windows lacked the configured runner group, and macOS/Linux jobs were cancelled after their time limits.

Validation used synthetic fixtures. A production-account scan was not exercised. This is an issue with a reference patch, following the repository's issue-based contribution policy.

Lingua principale
Rust
Stelle
133k
Fork
21.1k
Merge medio
1m
PR unite (30g)
997

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openai/codex

Tutte le issue di openai/codex

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.