[codex] Add model tool mode selector

[aibrahim-oai]

Why

Some models need to select their code-execution behavior through model catalog metadata. Models without that metadata must continue to follow the existing CodeMode and CodeModeOnly feature flags, including when a newer server sends an enum value this client does not recognize.

What changed

• add optional ModelInfo.tool_mode metadata with direct, code_mode, and code_mode_only
• treat omitted and unknown wire values as None
• resolve None from the existing feature flags
• carry the resolved ToolMode directly on TurnContext, outside Config
• use the resolved value for turn creation, model switches, review turns, tool planning, and code execution

Coverage

• add protocol coverage for omitted, known, and unknown enum values
• add focused coverage for flag fallback and explicit metadata overriding feature flags
• add core integration coverage that fetches remote model metadata through /v1/models and verifies the outbound /responses tools for explicit direct and code_mode_only selectors

Stack

• followed by [codex] Add model multi-agent version selector #25032

[aibrahim-oai]

This change is part of the following stack:

• [codex] Add model tool mode selector #25031 ◀
  • [codex] Add model multi-agent version selector #25032

_{Change managed by git-spice.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7c264fbbd2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep metadata-driven code mode behind a context cap

When the /models payload sets tool_mode to code_mode or code_mode_only, this overrides the local CodeMode feature flags, so model metadata can now expose the codex freeform tool even in sessions where code mode was not locally enabled. In code_mode_only, build_exec_tool_description expands every visible nested tool, including MCP/extension/dynamic tool descriptions, into one model-visible tool description with no hard cap; that new individual context item can exceed the >1k-token manual-review threshold and has no 10K-token bound. Please keep CodeMode as a local gate or cap/truncate the generated description before exposing metadata-driven code mode.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve tool_mode in lockfile replays

When config-lock replay is used with the default save_fields_resolved_from_model_catalog = true, the lockfile drops model_catalog_json after saving resolved catalog-derived fields, but this new tool_mode selector is not saved anywhere. In that replay/resume context, a later remote catalog change for the same model can make this line choose a different mode and override the lockfile’s materialized feature flags, so the same locked session can gain or lose the code-mode tool surface while validation still passes; persist the resolved selector or encode it into the locked feature state.

Useful? React with 👍 / 👎.

[jif-oai]

I maintain my comment on the other side that we probably need something more generic to control the config from the model

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2261e0814d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Cover the code_mode catalog selector

The new code_mode selector is a distinct wire value, but the added integration coverage only drives remote metadata through direct and code_mode_only; existing Code Mode tests still reach this path via local feature flags. A regression that deserializes or resolves tool_mode: "code_mode" incorrectly for remote models would pass the current suite, so please add a focused integration test that feeds code_mode metadata and asserts the resulting outbound Code Mode tools/worker behavior.

Useful? React with 👍 / 👎.