Codex falling in a loop `no apply_patch tool available` and cannot call `multi_tool_use.parallel`

[ctkm-aelf]

Mirrored from upstream for consensus-rnd Track A.

Upstream: openai#15642

Summary:

What version of Codex CLI is running?

Acceptance criteria:

• Verify the upstream reproduction against the current checkout.
• Implement the smallest fix that satisfies the expected behavior if the bug still reproduces.
• Add focused regression coverage in codex-apply-patch tests.

Target crate: repo-owned bounded module

Selection rubric:

• Small or medium mechanical bug.
• Clear reproduction and expected behavior.
• Owned by this repository and bounded to identifiable files/modules.
• Implementation scope paths must resolve inside REPO_ROOT; installed skill paths, home-directory paths, and other out-of-repo paths are triage or human-blocked, not implementation candidates.
• Consensus-loop skill-engine fixes must be managed by a skill-source workflow or manual skill patch, not by the ChronoAIProject/codex repo implementation loop.
• Has focused CLI, exec, TUI, config, apply_patch, or local regression test path.
• Avoids auth, app-server, desktop app, extension, iOS, web, broad sandbox policy, account safety, and ambiguous service incidents.

[ctkm-aelf]

🤖 Delete solver abstained on issue #60

TL;DR

• What this is: Delete-solver review for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60, focused on whether the apply_patch / multi_tool_use.parallel failure should be solved by removing code.
• Current state or conclusion: I found apply_patch is active, registered, and covered by focused tests, so deletion would remove a load-bearing capability.
• What the maintainer should do OR what the controller does next: Continue with a minimal or structural fix that verifies the upstream reproduction and targets tool visibility/dispatch.

---

Delete-solver result

I recommend abstain, not deletion. ApplyPatchHandler is the built-in handler that exposes the apply_patch custom/freeform editing tool to the model; deleting it would remove the expected file-edit path instead of fixing the reported loop.

Key evidence:

• codex-rs/core/src/tools/spec_plan.rs:675 registers ApplyPatchHandler when the turn has an environment and the selected model advertises an apply_patch tool type.
• codex-rs/core/src/tools/handlers/apply_patch.rs:308 exposes the active apply_patch tool, and codex-rs/core/src/tools/handlers/apply_patch.rs:337 accepts the freeform custom patch payload.
• codex-rs/core/tests/suite/shell_serialization.rs:155, :197, and :237 cover create, update, and failure behavior for apply-patch custom tool calls.
• codex-rs/tools/src/code_mode.rs:75 and :111 show that code-mode tool definitions include freeform tools, which is the area to inspect if the model-visible tool list is wrong.

This points to a bounded bug-fix investigation around tool visibility, namespace/code-mode exposure, or the upstream reproduction matrix. It does not point to dead code, an orphan feature, or a duplicate implementation that can be safely removed.

📎 Full raw codex output (archival)

---
solver: delete
issue: 60
cluster: issue-60
verdict: abstain
---

## Classification
e) Genuinely needed and right-sized, with no current deletion/collapse justified.

## Recommended action
Abstain from deletion. The remaining `apply_patch` path is not dead code or an orphan feature: it is registered only when the model reports an `apply_patch` tool type and an environment exists, it provides the freeform custom-tool execution path, and it is covered by focused integration tests for create, update, and failure behavior. The issue should be handled as a bounded bug-fix investigation in tool visibility/dispatch, especially around code-mode or namespace exposure for `apply_patch` and `multi_tool_use.parallel`, not by deleting the active apply-patch implementation.

## Concrete plan (if propose)
- Files to delete: none
- Caller migrations: none
- Tests to delete: none
- LOC delta: 0
- Philosophy/CLAUDE.md/SPEC/Tier changes (if any): none
- IssueDecompositionPlan: not needed; the issue is bounded to tool registration, model-visible specs, and apply_patch regression coverage.

## Reverse-evidence (why this is safe to delete)
- No deletion is proposed, because deleting the remaining `apply_patch` handler would remove an active user-facing file-edit tool rather than remove dead code.
- `codex-rs/core/src/tools/spec_plan.rs:675` registers `ApplyPatchHandler` when the turn has an environment and `model_info.apply_patch_tool_type` is present.
- `codex-rs/core/src/tools/handlers/apply_patch.rs:308` exposes `ApplyPatchHandler` as the `apply_patch` tool, and `codex-rs/core/src/tools/handlers/apply_patch.rs:337` requires the freeform custom payload that the model sends for patch bodies.
- `codex-rs/core/src/tools/handlers/apply_patch.rs:377` and `codex-rs/core/src/tools/handlers/apply_patch.rs:561` route verified patches into the shared apply-patch runtime/orchestrator path, so there is not an obvious duplicate implementation to delete.
- `codex-rs/core/tests/suite/shell_serialization.rs:155`, `codex-rs/core/tests/suite/shell_serialization.rs:197`, and `codex-rs/core/tests/suite/shell_serialization.rs:237` cover custom-tool apply_patch create, update, and failure behavior.
- `codex-rs/tools/src/code_mode.rs:75` collects nested code-mode tool definitions, and `codex-rs/tools/src/code_mode.rs:111` maps freeform tools such as `apply_patch` into code-mode definitions. That supports investigating exposure/dispatch, not deleting the implementation.
- Git history shows prior cleanup already removed the obsolete function-style path in `e783341b70 [codex] Delete function-style apply_patch (#21651)`, leaving the current freeform handler as the active path.
- Reference-frame pass: Unix-style "one active implementation per capability" and compatibility-preserving refactoring both argue against deleting the only active freeform apply_patch capability while a reproducer says the tool should be available.

## Risks
- The upstream reproduction was not replayed in this delete-solver pass; a minimal solver should verify whether current `CodeModeOnly`, namespace-tools, or Responses Lite combinations still omit a needed tool spec.
- If another active file-edit path fully supersedes freeform `apply_patch` for every supported model and environment, that replacement was not evident from the local call graph and tests.
- If `multi_tool_use.parallel` is intentionally hidden in a specific surface, the fix may belong in prompt/tool-mode guidance rather than Rust dispatch.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — for meta-judge)
- Why I claim this can be deleted: I do not claim it can be deleted. The correct delete-solver classification is abstain because the feature is active and load-bearing.
- What I checked to verify safety: repository search for `apply_patch`, `multi_tool_use.parallel`, and apply-patch tests; the tool planner registration path; the freeform handler; code-mode tool-definition conversion; focused integration tests; and git history around the current handler and prior function-style deletion.
- What I cannot decide alone: the exact minimal fix for the upstream loop without replaying the upstream reproduction matrix. That belongs to the minimal/structural solver, not the delete solver.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:delete:abstain:apply_patch is active and tested; investigate tool visibility/dispatch instead of deleting it

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Minimal solver proposes request-contract regression

TL;DR

• What this is: Minimal-change design solver output for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60.
• Current state or conclusion: The reported loop maps to the model-visible tool contract, not to the codex-apply-patch parser itself.
• What the controller does next: Use this as one solver input for consensus and verify whether a regression-only implementation is enough.

---

Minimal framing

The smallest repo-owned boundary is a core request-body regression for GPT-5.4. The current checkout already declares GPT-5.4 with apply_patch_tool_type: "freeform" and supports_parallel_tool_calls: true, and prompt construction forwards visible tools plus parallel_tool_calls into the Responses request. A focused test should submit two GPT-5.4 turns and assert both requests still include apply_patch, contain the multi_tool_use.parallel instruction text, and set parallel_tool_calls to true.

codex-apply-patch is the standalone patch parser and executable. It cannot directly observe whether the model was told that the apply_patch tool exists, so adding parser-only coverage would not guard the failure reported upstream.

📎 Full raw codex output (archival)

---
solver: minimal
issue: 60
cluster: issue-60
verdict: propose
---

## Recommended framing
Reference frame: model-visible API contract regression testing. The smallest useful boundary is not the `codex-apply-patch` parser: upstream #15642 reports a GPT-5.4 session losing confidence that `apply_patch` and `multi_tool_use.parallel` are available while shell execution still works. In the current checkout, GPT-5.4 metadata already declares `apply_patch_tool_type = freeform` and `supports_parallel_tool_calls = true`, and prompt construction forwards both the visible tool list and `parallel_tool_calls` into Responses requests. The minimal implementation should therefore add a focused core request regression for GPT-5.4 tool visibility across consecutive turns, plus only a tiny code fix if that test exposes drift in tool planning or model metadata.

## Concrete plan
- Files: `codex-rs/core/tests/suite/prompt_caching.rs` - add one regression that starts a GPT-5.4 session, submits two turns, and asserts both request bodies include `apply_patch`, include the `multi_tool_use.parallel` instruction text in model instructions, and set `parallel_tool_calls` to `true`.
- Files: `codex-rs/core/src/tools/spec_plan.rs` - edit only if the new regression shows `apply_patch` is hidden for a normal local environment; expected change would be limited to the existing `add_core_utility_tools` condition for environment-backed tools.
- Files: `codex-rs/models-manager/models.json` - edit only if the new regression shows the bundled GPT-5.4 metadata lacks `apply_patch_tool_type: "freeform"` or `supports_parallel_tool_calls: true`; current checkout already has both, so no metadata edit is expected.
- LOC delta: ~+45 / -0 for the regression-only path; at most ~+5 / -5 more if a real visibility bug appears.
- Tests to add/modify: one focused integration test in `codex-rs/core/tests/suite/prompt_caching.rs`; run `just fmt`, then `just test -p codex-core prompt_caching` or the nearest supported focused `just test -p codex-core` invocation. The issue asks for `codex-apply-patch` tests, but that crate cannot observe model-visible tool availability; adding parser/CLI coverage there would not guard this failure mode.
- Governance/ruleset change (if any): none.
- Migration path: no migration needed.

## Risks
- The upstream loop may involve live model behavior after repeated compaction, so request-body coverage can prove the CLI contract but cannot prove the hosted model will never reason incorrectly.
- If maintainers require literal `codex-apply-patch` crate coverage, that test would be a low-signal proxy because the reported failure is that the model believes the tool is unavailable, not that a valid patch fails to parse or apply.
- The current checkout appears to have the GPT-5.4 metadata contract already fixed; the implementation may land as regression coverage only.

## Escalation triggers (if any)
- None.

## Reasoning trace (internal - short, for meta-judge)
- Why this is the minimum: upstream #15642 reports missing/looping tool-use cognition, while current source shows the concrete contract flows through `models.json`, `build_prompt`, and `add_core_utility_tools`; a single request-body regression is the smallest repo-owned proof.
- What I considered but rejected: changing `codex-apply-patch` parser/CLI behavior, because the issue evidence shows no malformed patch or parser failure; adding broad compaction/model-behavior machinery, because existing tests already cover stable tool lists and compact request `parallel_tool_calls` separately.
- What I cannot decide alone: whether the live GPT-5.4 model still loops despite the correct CLI contract; that requires hosted-model observation beyond this repo-owned regression.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:minimal:propose:add GPT-5.4 request-body regression for apply_patch visibility and parallel tool-call contract

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Structural solver proposes a fallback model capability profile

TL;DR

• What this is: Structural design output for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60, covering the no apply_patch tool available and multi_tool_use.parallel loop reported upstream.
• Current state or conclusion: The likely structural defect is fallback model metadata advertising no apply_patch tool and no parallel tool calls while the runtime can expose both.
• What the maintainer should do OR what the controller does next: Compare this with the other solver outputs and choose whether to patch fallback model capabilities or require provider-specific gating.

---

Structural framing

The upstream report points at unknown-model fallback behavior: the user saw Model metadata for gpt-oss:20b not found. Defaulting to fallback metadata, followed by repeated reasoning that apply_patch was missing and multi_tool_use.parallel could not be called correctly. In this checkout, fallback model metadata is constructed in codex-rs/models-manager/src/model_info.rs; that path currently sets apply_patch_tool_type: None and supports_parallel_tool_calls: false.

apply_patch_tool_type matters because codex-rs/core/src/tools/spec_plan.rs only registers the model-visible freeform apply_patch tool when that field is present. supports_parallel_tool_calls matters because codex-rs/core/src/session/turn.rs copies it into the prompt and codex-rs/core/src/client.rs serializes it as the Responses parallel_tool_calls request flag.

The proposed fix is not to add more prompt text. It is to add a private ModelToolCapabilityProfile in codex-models-manager, apply it to fallback metadata, and cover the full contract with tests: fallback metadata values, ToolRouter visibility for apply_patch, and the actual /responses request body containing both the freeform apply_patch tool and parallel_tool_calls: true.

Option	Trade-off
Fallback profile sets apply_patch + parallel true	Smallest structural repair; may need provider compatibility confirmation for third-party endpoints.
Provider-gated fallback profile	Safer for strict providers; requires identifying the provider capability source before implementation.
Prompt-only clarification	Lowest code cost; leaves the tool list/request flags inconsistent and does not fix the reported loop by construction.

📎 Full raw codex output (archival)

---

solver: structural
issue: 60
cluster: issue-60
verdict: propose

PROJECT_RULES clause violated (quoted verbatim)

Resist adding code to codex-core!

Particularly when introducing a new concept/feature/API, before adding to codex-core, consider whether:

• There is an existing crate other than codex-core that is an appropriate place for your new code to live.
• It is time to introduce a new crate to the Cargo workspace for your new functionality. Refactor existing code as necessary to make this happen.

Likewise, when reviewing code, do not hesitate to push back on PRs that would unnecessarily add code to codex-core.

When working with MCP tool calls, prefer using codex-rs/codex-mcp/src/mcp_connection_manager.rs to handle mutation of tools and tool calls. Aim to minimize the footprint of changes and leverage existing abstractions rather than plumbing code through multiple levels of function calls.

Run just fmt (in the codex-rs directory) automatically after you have finished making code changes anywhere in this repository; do not ask for approval to run it. Additionally, run the tests:

1. Do not run cargo test directly. Use just test so test execution follows the repo defaults.
2. Run the test for the specific project that was changed. For example, if changes were made in codex-rs/tui, run just test -p codex-tui.

Recommended framing

Treat the loop as a broken model-visible tool capability contract, not as an apply_patch parser bug or a prompt-only problem. The upstream reproduction shows an unknown/fallback model (gpt-oss) reasoning that apply_patch is unavailable and that multi_tool_use.parallel usage is mandatory or impossible; the local source confirms fallback metadata currently sets apply_patch_tool_type: None and supports_parallel_tool_calls: false in codex-rs/models-manager/src/model_info.rs:89-92. The clean structure is a small ModelToolCapabilityProfile owned by codex-models-manager: fallback model metadata should explicitly declare the conservative editing and parallel-call capabilities that Codex actually exposes, while codex-core continues to consume those fields through the existing ToolSpecPlan and Prompt request path. Reference-frame note: capability negotiation invariant, where the advertised request contract and executable runtime surface must be generated from one bounded profile instead of scattered booleans.

Concrete plan

• New abstractions (if any): ModelToolCapabilityProfile in Layer: model metadata normalization; Project: codex-models-manager; File: codex-rs/models-manager/src/model_info.rs. Interface: private enum/struct with fn fallback() -> Self and fn apply_to(self, model: &mut ModelInfo). It owns only apply_patch_tool_type and supports_parallel_tool_calls for this issue. This is justified by an explicit named extension point: unknown/fallback model metadata is already a first-class path with a TUI warning and a degraded-behavior contract.
• Files:
  • codex-rs/models-manager/src/model_info.rs: replace the raw fallback assignments apply_patch_tool_type: None and supports_parallel_tool_calls: false with the profile-applied values: apply_patch_tool_type: Some(ApplyPatchToolType::Freeform) and supports_parallel_tool_calls: true. Keep used_fallback_model_metadata: true and the warning unchanged.
  • codex-rs/models-manager/src/model_info_tests.rs: add a focused equality-style regression test that model_info_from_slug("gpt-oss:20b") preserves fallback status and exposes the profile values.
  • codex-rs/core/src/tools/spec_plan_tests.rs: add a fallback_model_metadata_exposes_apply_patch_tool test using model_info_from_slug or the test helper so the existing ToolRouter path proves apply_patch is visible when an environment exists. This matters because codex-rs/core/src/tools/spec_plan.rs:675-678 gates the actual freeform apply_patch tool on model_info.apply_patch_tool_type.
  • codex-rs/core/tests/suite/prompt_caching.rs: add one request-level regression for an unknown model slug that asserts the posted /responses body contains an apply_patch freeform tool and parallel_tool_calls: true. This matters because codex-rs/core/src/session/turn.rs:1012-1016 copies supports_parallel_tool_calls into Prompt, and codex-rs/core/src/client.rs:746-750 serializes it into the Responses request.
  • codex-rs/core/src/tools/handlers/apply_patch_spec.rs: no behavior change expected, but tests should assert its existing freeform description still says the patch is not JSON; this is the line the reported model failed to trust (codex-rs/core/src/tools/handlers/apply_patch_spec.rs:18-24).
• LOC delta: ~+30 / -2 in codex-models-manager; ~+55 / -0 tests in codex-models-manager; ~+70 / -0 tests in codex-core; 4 files touched, no new files.
• Tests to add:
  • codex-rs/models-manager/src/model_info_tests.rs: fallback_model_metadata_uses_tool_capability_profile, asserting whole-object equality against model_info_from_slug with only the two capability fields and slug varied from a constructed expected value.
  • codex-rs/core/src/tools/spec_plan_tests.rs: unknown_model_metadata_exposes_apply_patch_freeform_tool, asserting visible specs include apply_patch and the spec is ToolSpec::Freeform.
  • codex-rs/core/tests/suite/prompt_caching.rs: unknown_model_prompt_advertises_apply_patch_and_parallel_tool_calls, asserting the first request body has parallel_tool_calls == true, one apply_patch tool entry, and no appended fallback APPLY_PATCH_TOOL_INSTRUCTIONS duplicate when the tool is visible.
  • Verification commands: just fmt; just test -p codex-models-manager; just test -p codex-core --test prompt_caching unknown_model_prompt_advertises_apply_patch_and_parallel_tool_calls or the repo-supported focused equivalent; because codex-core changed, ask before a full just test per AGENTS.
• Schema/protocol changes (if any): none. Existing ModelInfo.apply_patch_tool_type, ModelInfo.supports_parallel_tool_calls, ToolSpec::Freeform, and Responses parallel_tool_calls are reused.
• Governance/ruleset changes (if any): none.
• Runtime cost: 0 added filesystem calls; 0 network calls; 0 latency hops. One private profile construction and two field assignments per fallback-model resolution, below 1 us and no meaningful allocation beyond the already constructed ModelInfo.
• If the structural answer is issue decomposition, use the controller-private IssueDecompositionPlan boundary and child body artifacts; forbid solver/judge/worker GitHub lifecycle, public issue factories, and any wakeup_plan.py decompose action/projection.
• Do not author helper-owned decomposition tracking comments or child fingerprint lines; the checked-in refactor(history-overlay): split into modular functions & add tests (fixes #402) openai/codex#403 helper is the only writer for the parent tracking grammar and per-child idempotency fingerprints.

Risks

• Enabling parallel_tool_calls for unknown local models assumes the provider endpoint accepts the field. The request already sends the field for known capable models and suppresses it for Responses Lite in client.rs, so the bounded risk is third-party non-Lite endpoints that reject parallel_tool_calls: true. If that is observed, keep the profile but gate it behind a provider capability instead of reverting to scattered prompt guidance.
• Enabling freeform apply_patch for fallback models assumes the model can emit custom/freeform tools. If a provider lacks freeform tool support, the safer structural fallback is ApplyPatchToolType::Function only if such a variant exists; current source evidence points to Freeform as the actual registered implementation.
• The profile could grow into a dumping ground for model defaults. Keep it scoped to tool-contract fields and require each new field to have a request-level regression.

Escalation triggers (if any)

• none

Reasoning trace (internal — for meta-judge)

• Why this structure beats a documented exception: the reported failure is a reasoning loop caused by contradictory or missing capabilities. More instructions saying “you have apply_patch” still leave the request body saying no apply_patch for fallback models; fixing the profile makes the model-visible tool list and executable router agree by construction.
• Why I picked this abstraction over alternatives: changing codex-core directly would violate the “resist adding code to codex-core” rule because the bad defaults originate in codex-rs/models-manager/src/model_info.rs. Changing only apply_patch_spec.rs would not affect fallback metadata. Changing multi_tool_use.parallel runtime scheduling would miss that the request-level parallel_tool_calls flag is currently false for fallback models.
• What I cannot decide alone: whether every unknown third-party model should receive supports_parallel_tool_calls: true, or whether the profile should be conditional on provider capabilities. The upstream report’s loop specifically mentions fallback metadata degrading tool behavior, so the proposed default is structurally coherent but should be confirmed against provider compatibility.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:structural:propose:add a fallback model tool capability profile so unknown models advertise apply_patch and parallel tool calls consistently

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Meta-judge requests round 2 convergence

TL;DR

• What this is: Meta-judge arbitration for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60 after reading the minimal, structural, and delete solver outputs.
• Current state or conclusion: No implementation consensus yet because the two implementation solvers target different root causes.
• What the controller does next: Re-run design solvers for round 2 with the narrowed question below.

---

Consensus decision

Round 1 established that the existing implementation is active and should not be deleted. The remaining disagreement is specific: the minimal solver says the current checkout already has the GPT-5.4 tool contract and needs request-body regression coverage, while the structural solver says the real reproduction is fallback model metadata such as and needs production capability defaults changed.

Option	Trade-off
GPT-5.4 regression-only path	Smallest change, but may miss the fallback-model warning shown in the upstream report.
Fallback metadata repair	Addresses unknown-model degradation, but changes defaults for third-party providers and needs safety evidence.
Delete apply_patch path	Rejected for now because the delete solver found it active, registered, and covered by tests.

The round-2 question is: which reproduction target is supported by current evidence: known GPT-5.4 request-contract drift that only needs regression coverage, or unknown/fallback model metadata that must advertise and ; and what exact local test should fail before any production capability default is changed?

Each solver should explicitly address the current-checkout source lines for model capability metadata, tool visibility, instruction text, and serialized . If implementation is proposed, round 2 should converge on one set and explain whether crate coverage is a valid proxy for model-visible tool availability.

---

📎 Full raw codex output (archival)

---
issue: 60
cluster: issue-60
convergence_round: 1
solver_verdicts:
  minimal: propose
  structural: propose
  delete: abstain
decision: converge
action_mode: plan
canonical_key: openai/codex#15642
next_action: plan
---

## Decision
Reference-frame note: capability-negotiation contract. A model-visible tool surface must be judged by the same capability facts that drive request serialization and executable dispatch. Round 1 does not reach implementation-bearing consensus: the delete solver is a compatible neutral abstain for Path A issue-driven work, but the two implementation-bearing solvers do not agree on the same concrete plan. The minimal solver frames the current checkout as already correct for GPT-5.4 and proposes regression-only coverage in `codex-rs/core/tests/suite/prompt_caching.rs`, with source edits only if the regression fails. The structural solver frames the bug as unknown/fallback model metadata and proposes changing `codex-rs/models-manager/src/model_info.rs` plus fallback/tool/request tests. Those differ in root cause, scope paths, LOC, and compatibility risk, so the controller should run round 2 with a narrower evidence question rather than dispatch implementation.

## If converge
- Convergence question (specific): Which reproduction target is supported by current evidence: known GPT-5.4 request-contract drift that only needs regression coverage, or unknown/fallback model metadata that must advertise `apply_patch` and `parallel_tool_calls`; and what exact local test should fail before any production capability default is changed?
- What each solver should address explicitly:
  - State whether upstream #15642 reproduces through a known model profile such as GPT-5.4, an unknown/fallback model slug such as `gpt-oss:20b`, or both.
  - Identify the exact current-checkout source lines that determine `apply_patch_tool_type`, `supports_parallel_tool_calls`, visible `apply_patch` specs, `multi_tool_use.parallel` instruction text, and serialized `parallel_tool_calls`.
  - Decide whether changing fallback metadata to `ApplyPatchToolType::Freeform` and `supports_parallel_tool_calls: true` is safe for unknown third-party providers, or whether round 2 should authorize only request-body regression coverage.
  - If proposing implementation, provide one agreed `scope_paths` set and focused tests; explain why `codex-apply-patch` crate coverage is or is not a valid acceptance-criteria proxy for model-visible tool availability.
  - Delete solver should confirm whether its abstain remains compatible with either implementation path or whether one path introduces a deletable/collapsible duplicate.
- Round number this fires: 2; marker payload uses source round `1`
- Progress since prior round: Round 1 established that `apply_patch` itself is active/load-bearing, but exposed a named disagreement between GPT-5.4 regression-only coverage and fallback-model capability repair.
- Human-intervention threshold: not reached

## Round audit trail (links to local artifacts)
- solver-minimal: .refactor-loop/logs/phase9-issue60-r1-minimal.log
- solver-structural: .refactor-loop/logs/phase9-issue60-r1-structural.log
- solver-delete: .refactor-loop/logs/phase9-issue60-r1-delete.log
- work-unit-producer: manual-issue (prompt-only provenance)
- work-unit-source-ref: gh-issue-60
- action_mode: plan
- canonical_key: openai/codex#15642
- duplicate_search_summary: scoped to router-provided issue snapshot and the three listed round-1 solver logs; no sibling artifacts were read under the prompt boundary
- branch: none
- PR: none
- commit: none
- unique_diff_status: not-applicable
- tests_verification: not run; this judge role only arbitrated solver artifacts
- resolution: converge
- next_action: plan

⟦AI:AUTO-LOOP⟧
META_JUDGE_DONE:converge:round-1:Resolve whether issue #60 targets GPT-5.4 request-contract regression coverage or fallback-model capability defaults for apply_patch and parallel_tool_calls

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Meta-judge requests round 2 convergence (corrected)

TL;DR

• What this is: Corrected meta-judge arbitration for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60 after reading the minimal, structural, and delete solver outputs.
• Current state or conclusion: No implementation consensus yet because the two implementation solvers target different root causes.
• What the controller does next: Re-run design solvers for round 2 with the narrowed question below.

---

Consensus decision

Round 1 established that the existing apply_patch implementation is active and should not be deleted. The remaining disagreement is specific: the minimal solver says the current checkout already has the GPT-5.4 tool contract and needs request-body regression coverage, while the structural solver says the real reproduction is fallback model metadata such as gpt-oss:20b and needs production capability defaults changed.

Option	Trade-off
GPT-5.4 regression-only path	Smallest change, but may miss the fallback-model warning shown in the upstream report.
Fallback metadata repair	Addresses unknown-model degradation, but changes defaults for third-party providers and needs safety evidence.
Delete apply_patch path	Rejected for now because the delete solver found it active, registered, and covered by tests.

The round-2 question is: which reproduction target is supported by current evidence: known GPT-5.4 request-contract drift that only needs regression coverage, or unknown/fallback model metadata that must advertise apply_patch and parallel_tool_calls; and what exact local test should fail before any production capability default is changed?

Each solver should explicitly address the current-checkout source lines for model capability metadata, tool visibility, multi_tool_use.parallel instruction text, and serialized parallel_tool_calls. If implementation is proposed, round 2 should converge on one scope_paths set and explain whether codex-apply-patch crate coverage is a valid proxy for model-visible tool availability.

---

📎 Full raw codex output (archival)

---
issue: 60
cluster: issue-60
convergence_round: 1
solver_verdicts:
  minimal: propose
  structural: propose
  delete: abstain
decision: converge
action_mode: plan
canonical_key: openai/codex#15642
next_action: plan
---

## Decision
Reference-frame note: capability-negotiation contract. A model-visible tool surface must be judged by the same capability facts that drive request serialization and executable dispatch. Round 1 does not reach implementation-bearing consensus: the delete solver is a compatible neutral abstain for Path A issue-driven work, but the two implementation-bearing solvers do not agree on the same concrete plan. The minimal solver frames the current checkout as already correct for GPT-5.4 and proposes regression-only coverage in `codex-rs/core/tests/suite/prompt_caching.rs`, with source edits only if the regression fails. The structural solver frames the bug as unknown/fallback model metadata and proposes changing `codex-rs/models-manager/src/model_info.rs` plus fallback/tool/request tests. Those differ in root cause, scope paths, LOC, and compatibility risk, so the controller should run round 2 with a narrower evidence question rather than dispatch implementation.

## If converge
- Convergence question (specific): Which reproduction target is supported by current evidence: known GPT-5.4 request-contract drift that only needs regression coverage, or unknown/fallback model metadata that must advertise `apply_patch` and `parallel_tool_calls`; and what exact local test should fail before any production capability default is changed?
- What each solver should address explicitly:
  - State whether upstream #15642 reproduces through a known model profile such as GPT-5.4, an unknown/fallback model slug such as `gpt-oss:20b`, or both.
  - Identify the exact current-checkout source lines that determine `apply_patch_tool_type`, `supports_parallel_tool_calls`, visible `apply_patch` specs, `multi_tool_use.parallel` instruction text, and serialized `parallel_tool_calls`.
  - Decide whether changing fallback metadata to `ApplyPatchToolType::Freeform` and `supports_parallel_tool_calls: true` is safe for unknown third-party providers, or whether round 2 should authorize only request-body regression coverage.
  - If proposing implementation, provide one agreed `scope_paths` set and focused tests; explain why `codex-apply-patch` crate coverage is or is not a valid acceptance-criteria proxy for model-visible tool availability.
  - Delete solver should confirm whether its abstain remains compatible with either implementation path or whether one path introduces a deletable/collapsible duplicate.
- Round number this fires: 2; marker payload uses source round `1`
- Progress since prior round: Round 1 established that `apply_patch` itself is active/load-bearing, but exposed a named disagreement between GPT-5.4 regression-only coverage and fallback-model capability repair.
- Human-intervention threshold: not reached

## Round audit trail (links to local artifacts)
- solver-minimal: .refactor-loop/logs/phase9-issue60-r1-minimal.log
- solver-structural: .refactor-loop/logs/phase9-issue60-r1-structural.log
- solver-delete: .refactor-loop/logs/phase9-issue60-r1-delete.log
- work-unit-producer: manual-issue (prompt-only provenance)
- work-unit-source-ref: gh-issue-60
- action_mode: plan
- canonical_key: openai/codex#15642
- duplicate_search_summary: scoped to router-provided issue snapshot and the three listed round-1 solver logs; no sibling artifacts were read under the prompt boundary
- branch: none
- PR: none
- commit: none
- unique_diff_status: not-applicable
- tests_verification: not run; this judge role only arbitrated solver artifacts
- resolution: converge
- next_action: plan

⟦AI:AUTO-LOOP⟧
META_JUDGE_DONE:converge:round-1:Resolve whether issue #60 targets GPT-5.4 request-contract regression coverage or fallback-model capability defaults for apply_patch and parallel_tool_calls

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Delete solver abstains on issue #60 round 2

TL;DR

• What this is: Round-2 delete-solver review for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60, focused on whether the reported tool loop should be solved by removing code.
• Current state or conclusion: Deletion is not justified because apply_patch is active, tested, and gated by model capability metadata rather than dead or duplicate code.
• What the controller does next: Converge on a model-visible capability contract test before changing fallback model defaults.

---

Delete-solver result

I recommend abstain, not deletion. The current checkout shows two different capability paths:

Reproduction target	Evidence	Trade-off
Known GPT-5.4 profile	codex-rs/models-manager/models.json:101, :112, and :118 already advertise freeform apply_patch, parallel calls, and slug gpt-5.4.	Best handled with a core request-body regression if maintainers want guard coverage.
Unknown/fallback profile	codex-rs/models-manager/src/model_info.rs:89 and :92 set fallback metadata to no apply_patch and no parallel calls.	A production default change needs provider compatibility evidence and a failing local contract test first.
Delete apply_patch path	codex-rs/core/src/tools/handlers/apply_patch.rs:308 exposes the active handler, and codex-rs/core/src/tools/spec_plan.rs:675 registers it when the model advertises the capability.	Would remove the expected editing capability rather than fix the reported loop.

multi_tool_use.parallel is instruction text in codex-rs/core/gpt_5_2_prompt.md:252; the serialized request flag comes from codex-rs/core/src/session/turn.rs:1015 and codex-rs/core/src/client.rs:749. codex-apply-patch parser tests cannot observe either the model-visible tool list or the Responses parallel_tool_calls request field, so they are not a valid proxy for this bug.

---

📎 Full raw codex output (archival)

---
solver: delete
issue: 60
cluster: issue-60
verdict: abstain
---

## Classification
e) Genuinely needed and right-sized; no current deletion/collapse is justified.

Reference-frame note: capability negotiation contract. A tool should be deleted only when it is dead, redundant, or orphaned; here `apply_patch` is an active model-visible capability gated by model metadata and environment availability, while `parallel_tool_calls` is a request capability flag driven by the same metadata boundary.

## Recommended action
Abstain from deletion. The current-checkout evidence does not support deleting or collapsing the `apply_patch` path, the `multi_tool_use.parallel` instruction, or the fallback metadata path. The known GPT-5.4 profile already advertises `apply_patch_tool_type: "freeform"` and `supports_parallel_tool_calls: true`, while unknown/fallback model metadata currently advertises neither capability. That means round 2 should converge around a model-visible capability contract test, not around deletion: a production fallback-default change should require a failing local test proving that an unknown/fallback model session should expose `apply_patch` and serialize `parallel_tool_calls: true`. `codex-apply-patch` parser coverage is not a valid proxy for this failure because it cannot observe the model-visible tool list or the Responses request body.

## Concrete plan (if propose)
- Files to delete: none
- Caller migrations: none
- Tests to delete: none
- LOC delta: 0
- Philosophy/CLAUDE.md/SPEC/Tier changes (if any): none
- IssueDecompositionPlan: not applicable; this issue is bounded to model capability metadata, tool visibility, and request serialization, not to a delete/collapse opportunity.

## Reverse-evidence (why this is safe to delete)
- Deletion is not safe. `codex-rs/core/src/tools/handlers/apply_patch.rs:308` names the active `apply_patch` handler, `:313` exposes its freeform spec, and `:337` accepts the custom/freeform payload that patch calls use.
- `codex-rs/core/src/tools/spec_plan.rs:675` registers `ApplyPatchHandler` only when the turn has an environment and `turn_context.model_info.apply_patch_tool_type.is_some()`. Removing this path would remove the expected file-editing tool rather than fix a visibility bug.
- `codex-rs/core/src/tools/spec_plan_tests.rs:602` covers environment-controlled visibility and asserts `apply_patch` is visible when an environment exists and the model advertises `ApplyPatchToolType::Freeform`.
- `codex-rs/core/src/tools/handlers/apply_patch_spec_tests.rs:5` covers the expected freeform tool spec shape.
- `codex-rs/core/tests/suite/shell_serialization.rs:155`, `:197`, and `:237` cover create, update, and failure behavior for custom `apply_patch` tool calls.
- `codex-rs/models-manager/models.json:101`, `:112`, and `:118` show GPT-5.4 already has `apply_patch_tool_type: "freeform"`, `supports_parallel_tool_calls: true`, and slug `gpt-5.4`.
- `codex-rs/models-manager/src/model_info.rs:89` and `:92` show fallback model metadata currently sets `apply_patch_tool_type: None` and `supports_parallel_tool_calls: false`; this is the only local evidence matching the upstream warning about defaulting to fallback metadata for an unknown slug such as `gpt-oss:20b`.
- `codex-rs/core/gpt_5_2_prompt.md:252` contains the `multi_tool_use.parallel` instruction text; this is instruction visibility, not executable dispatch.
- `codex-rs/core/src/session/turn.rs:1015` copies `turn_context.model_info.supports_parallel_tool_calls` into the prompt.
- `codex-rs/core/src/client.rs:749` serializes `parallel_tool_calls` as `prompt.parallel_tool_calls && !model_info.use_responses_lite`.
- No public API deletion is safe to claim because the affected path is an active tool surface and has focused tests.
- External repo dependencies were untouched; this solver only inspected the current checkout.

## Risks
- If upstream #15642 actually reproduces on a known GPT-5.4 profile despite the current metadata, the right fix is request-contract regression coverage in `codex-rs/core`, not deletion.
- If maintainers decide unknown/fallback model metadata should expose `apply_patch` and parallel calls by default, that is a compatibility-sensitive production default change for third-party/provider-specific model slugs. It should be guarded by a failing local contract test that builds an unknown-model/fallback session and asserts the request includes the freeform `apply_patch` tool and `parallel_tool_calls: true`.
- If strict third-party Responses-compatible providers reject freeform tools or parallel tool calls, a broad fallback default could break them; a provider-gated capability profile may be required.

## Escalation triggers (if any)
- none

## Reasoning trace (internal - for meta-judge)
- Why I claim this can be deleted: I do not claim it can be deleted. The code path is active, tested, and user-facing.
- What I checked to verify safety: searched for `apply_patch_tool_type`, `supports_parallel_tool_calls`, `multi_tool_use.parallel`, `parallel_tool_calls`, and `ApplyPatchHandler`; inspected current-checkout lines for known GPT-5.4 metadata, fallback metadata, tool registration, prompt instructions, prompt construction, request serialization, apply-patch handler dispatch, and focused tests; reviewed `git log -p -S` evidence showing the fallback metadata path inherited conservative `apply_patch_tool_type: None` and `supports_parallel_tool_calls: false` defaults when offline fallback model definitions were removed.
- What I cannot decide alone: whether fallback metadata should be globally permissive for unknown model slugs, provider-gated, or kept conservative while adding only request-contract regression coverage for known models. That is an implementation-solver/meta-judge choice, not a deletion choice.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:delete:abstain:apply_patch and parallel-call tooling are active capability surfaces; issue #60 needs model-visible contract evidence, not deletion

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Structural solver targets fallback model capabilities

TL;DR

• What this is: Round-2 structural solver output for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60.
• Current state or conclusion: Current evidence supports the unknown/fallback model path, not GPT-5.4 request-contract drift.
• What the controller does next: Compare solvers on a fallback-metadata fix guarded by a failing request-body regression.

---

Structural result

The key source-of-truth split is in model metadata. Bundled gpt-5.4 already advertises apply_patch_tool_type: "freeform" and supports_parallel_tool_calls: true in codex-rs/models-manager/models.json:101-118, so a GPT-5.4-only regression would not reproduce the missing-tool contract on this checkout.

The fallback model path does reproduce the contract defect: codex-rs/models-manager/src/model_info.rs:89 sets apply_patch_tool_type to None, and codex-rs/models-manager/src/model_info.rs:92 sets supports_parallel_tool_calls to false. Those two fields directly drive the user-visible behavior: codex-rs/core/src/tools/spec_plan.rs:675-679 only exposes ApplyPatchHandler when the model metadata has an apply-patch tool type, while codex-rs/core/src/session/turn.rs:1012-1016 and codex-rs/core/src/client.rs:743-750 carry supports_parallel_tool_calls into the serialized Responses request.

ApplyPatchHandler is the core handler that exposes the freeform apply_patch tool; the parser crate cannot observe whether this handler was advertised to the model. For that reason, codex-apply-patch tests are not a valid proxy for issue #60's model-visible tool availability. The useful regression is a core request-body test with an unknown slug such as gpt-oss:20b.

Option	Trade-off
Fallback metadata capability profile	Addresses the upstream warning path and fixes both apply_patch visibility and serialized parallel_tool_calls; carries provider compatibility risk for strict third-party endpoints.
GPT-5.4 regression only	Smaller and low risk, but current checkout already has both GPT-5.4 capability bits, so it misses the observed fallback warning path.
codex-apply-patch parser test	Useful for patch parsing bugs, but cannot validate model-visible tools, instructions, or parallel_tool_calls.

Recommended implementation boundary: add a private fallback tool capability profile in codex-rs/models-manager/src/model_info.rs, add a models-manager unit test for fallback metadata, and add one core integration test that captures the first /v1/responses body for gpt-oss:20b and asserts apply_patch is present, multi_tool_use.parallel guidance remains in instructions, and parallel_tool_calls == true.

📎 Full raw codex output (archival)

    ---
    solver: structural
    issue: 60
    cluster: issue-60
    verdict: propose
    ---
    
    ## PROJECT_RULES clause violated (quoted verbatim)
    > Resist adding code to codex-core!
    >
    > Particularly when introducing a new concept/feature/API, before adding to codex-core, consider whether:
    >
    > - There is an existing crate other than codex-core that is an appropriate place for your new code to live.
    > - It is time to introduce a new crate to the Cargo workspace for your new functionality. Refactor existing code as necessary to make this happen.
    >
    > Likewise, when reviewing code, do not hesitate to push back on PRs that would unnecessarily add code to codex-core.
    >
    > Features that change the agent logic MUST add an integration test:
    >
    > - Provide a list of major logic changes and user-facing behaviors that need to be tested.
    
    ## Recommended framing
    Reference-frame note: capability negotiation contract. The supported reproduction target is the unknown/fallback model path, not known GPT-5.4 request drift. In the current checkout, bundled `gpt-5.4` already advertises `apply_patch_tool_type: "freeform"` and `supports_parallel_tool_calls: true` in `codex-rs/models-manager/models.json:101-118`, while fallback metadata built by `model_info_from_slug` disables both at `codex-rs/models-manager/src/model_info.rs:89` and `:92`. That fallback then suppresses the model-visible `apply_patch` tool because `codex-rs/core/src/tools/spec_plan.rs:675-679` only registers `ApplyPatchHandler` when the model metadata has an apply-patch tool type, and it serializes `parallel_tool_calls: false` because `codex-rs/core/src/session/turn.rs:1012-1016` copies the metadata bit into the prompt and `codex-rs/core/src/client.rs:743-750` writes it into `/v1/responses`. Structurally, the fix should make fallback tool capability an explicit models-manager profile and then prove the full request contract through one core integration test. That keeps the capability source outside `codex-core` while still testing the actual model-visible surface.
    
    ## Concrete plan
    - New abstractions (if any): `FallbackToolCapabilityProfile`, a private struct or enum-owned function in Layer: model metadata, Project: `codex-models-manager`, file: `codex-rs/models-manager/src/model_info.rs`. Interface shape: `FallbackToolCapabilityProfile::default_for_unknown_model() -> Self` and `apply_to(&self, model: &mut ModelInfo)`, or an equivalent private helper returning the two fields. It owns only fallback `apply_patch_tool_type` and `supports_parallel_tool_calls` defaults; it should not become provider routing or policy logic.
    - Files:
      - `codex-rs/models-manager/src/model_info.rs`: replace the inline fallback `apply_patch_tool_type: None` and `supports_parallel_tool_calls: false` literals with the private fallback tool capability profile, setting unknown-model fallback to freeform apply_patch and parallel tool calls if the request-contract regression fails as expected.
      - `codex-rs/models-manager/src/model_info_tests.rs`: add one unit test for `model_info_from_slug("gpt-oss:20b")` asserting the whole expected capability slice: fallback marker true, `apply_patch_tool_type == Some(Freeform)`, and `supports_parallel_tool_calls == true`. This is a source-of-truth test, not the only acceptance test.
      - `codex-rs/core/tests/suite/prompt_caching.rs` or `codex-rs/core/tests/suite/tools.rs`: add one integration regression that starts a session with an unknown model slug such as `gpt-oss:20b`, submits a normal local turn, captures the first `/v1/responses` request with `ResponseMock::single_request().body_json()`, and asserts the `tools` array contains `apply_patch`, the instructions still contain the `multi_tool_use.parallel` guidance from `codex-rs/core/gpt_5_2_prompt.md:250-252`, and `parallel_tool_calls == true`.
      - `codex-rs/tools/src/tool_config_tests.rs`, `codex-rs/tools/src/image_detail_tests.rs`, `codex-rs/models-manager/src/manager_tests.rs`, `codex-rs/core/src/config/config_tests.rs`, and similar fixture tests: update expected `ModelInfo` literals only where the fallback or default model-info constructors now intentionally include the new fallback capability values.
    - LOC delta: ~+55 / -8 in `codex-models-manager`; ~+45 / -0 in one core integration test; ~+10 / -10 fixture churn if existing expected structs assert the previous fallback booleans. Total expected change ~+110 / -18.
    - Tests to add: 2 tests. First, a models-manager unit test proving unknown fallback metadata carries the capability profile. Second, a core integration request-body test proving `gpt-oss:20b` fallback sends model-visible `apply_patch` and serialized `parallel_tool_calls: true`. Existing `codex-apply-patch` parser/CLI tests are not a valid proxy because they cannot observe tool visibility, instructions, or request serialization.
    - Schema/protocol changes (if any): none. `ModelInfo` already has `apply_patch_tool_type` and `supports_parallel_tool_calls`; the change is default values for unknown-model fallback metadata.
    - Governance/ruleset changes (if any): none. The plan follows the existing "resist adding code to codex-core" rule by locating capability ownership in `codex-models-manager` and adding only an integration regression in `codex-core`.
    - Runtime cost: 0 network calls, 0 actor hops, 0 protocol round trips. The capability helper is evaluated once when fallback `ModelInfo` is constructed; expected allocation delta is at most the existing `Option<ApplyPatchToolType>` field assignment and no additional heap allocation beyond the already allocated `ModelInfo`.
    - If the structural answer is issue decomposition, use the controller-private `IssueDecompositionPlan` boundary and child body artifacts; forbid solver/judge/worker GitHub lifecycle, public issue factories, and any `wakeup_plan.py` decompose action/projection.
    - Do not author helper-owned decomposition tracking comments or child fingerprint lines; the checked-in #403 helper is the only writer for the parent tracking grammar and per-child idempotency fingerprints.
    
    ## Risks
    - This trades the minimal GPT-5.4 regression-only path for a production fallback default change. The evidence supports that trade because GPT-5.4 already has both capability bits in the current checkout, while the upstream issue snapshot cites a fallback warning for `gpt-oss:20b`.
    - The compatibility risk is third-party or local providers whose unknown models reject freeform custom tools or `parallel_tool_calls`. Keep the implementation bounded by first adding the failing `gpt-oss:20b` request-contract test; if that test cannot be made to reproduce the missing tool and false parallel flag before the production change, do not change fallback defaults.
    - The named profile could be over-engineering if implemented as a public policy layer. Keep it private, two fields only, with exactly one production caller and two tests; do not add provider-specific configuration without separate evidence.
    
    ## Escalation triggers (if any)
    - None.
    
    ## Reasoning trace (internal — for meta-judge)
    - Why this structure beats a documented exception: Prompt text already tells the model to use `apply_patch` and `multi_tool_use.parallel`, but the machine-readable tool list and request flag can contradict that text. Capability defaults must be data, not a documentation exception.
    - Why I picked this abstraction over alternatives: The abstraction has one explicit extension point, unknown-model fallback metadata, and separates model capability ownership from core request assembly. A core-only patch would make `codex-core` override a models-manager fact after the fact.
    - What I cannot decide alone: Whether all supported third-party Responses-compatible endpoints accept freeform custom tools and parallel calls for unknown slugs. If maintainers require provider-specific safety, the same test should first fail on the current checkout and the implementation should add a provider-gated fallback profile rather than global true defaults.
    
    ⟦AI:AUTO-LOOP⟧
    SOLVER_DONE:structural:propose:target unknown-model fallback metadata with a private tool capability profile and a core request-body regression for apply_patch plus parallel_tool_calls

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Minimal solver targets fallback model metadata for issue #60

TL;DR

• What this is: Round-2 minimal-change solver output for the apply_patch and multi_tool_use.parallel loop.
• Current state or conclusion: Current evidence points to unknown/fallback model metadata, not a GPT-5.4-only request-contract drift.
• What the controller does next: Use a failing unknown-model request/spec regression before changing fallback defaults for apply_patch and parallel_tool_calls.

---

Minimal round-2 result

The smallest supported target is the unknown-model path. The bundled gpt-5.4 entry already advertises apply_patch_tool_type: "freeform" and supports_parallel_tool_calls: true, while fallback metadata for slugs such as gpt-oss:20b currently disables both fields. That matters because apply_patch_tool_type gates whether the model sees the freeform apply_patch tool, and supports_parallel_tool_calls becomes the serialized /responses parallel_tool_calls flag.

Option	Trade-off
Unknown/fallback model regression, then two-field fallback repair	Matches the reported fallback warning and gives a local failing test before changing defaults.
GPT-5.4 regression only	Smaller, but current checkout already has the relevant GPT-5.4 metadata and known-model tool consistency coverage.
codex-apply-patch parser coverage	Useful for parser bugs, but not a valid proxy for model-visible tool availability.

The proposed scope is codex-rs/models-manager/src/model_info.rs, codex-rs/models-manager/src/manager_tests.rs, codex-rs/core/src/tools/spec_plan_tests.rs, and codex-rs/core/tests/suite/prompt_caching.rs. The exact local discriminator is an unknown-model request-body/spec test that currently fails because apply_patch is absent and parallel_tool_calls is false; only after that failure should fallback metadata change to ApplyPatchToolType::Freeform and supports_parallel_tool_calls: true.

📎 Full raw codex output (archival)

---
solver: minimal
issue: 60
cluster: issue-60
verdict: propose
---

## Recommended framing
参考框架：capability negotiation contract。当前证据更支持 unknown/fallback model reproduction，而不是 GPT-5.4 request-contract drift：`codex-rs/models-manager/models.json:101-118` 已为 `gpt-5.4` 声明 `apply_patch_tool_type: "freeform"` 和 `supports_parallel_tool_calls: true`，但 `codex-rs/models-manager/src/model_info.rs:65-92` 的 unknown slug fallback 明确把 `apply_patch_tool_type` 设为 `None`、把 `supports_parallel_tool_calls` 设为 `false`。最小可行边界应先增加一个 unknown-model 本地 contract test，证明当前 checkout 的 `/responses` request 不包含 model-visible `apply_patch` 且 `parallel_tool_calls` 为 `false`；只有这个测试失败后，才把 fallback metadata 的两个字段改成 runtime 已能支持的 `Freeform`/`true`。`codex-apply-patch` crate coverage 不能作为这个问题的有效代理，因为它只能验证 patch parser/CLI/runtime，不能观察模型请求里是否广告了 `apply_patch` 或 `multi_tool_use.parallel`。

## Concrete plan
- Files: `codex-rs/models-manager/src/model_info.rs` - after adding the failing regression, change fallback metadata at `model_info_from_slug` from `apply_patch_tool_type: None` to `Some(ApplyPatchToolType::Freeform)` and from `supports_parallel_tool_calls: false` to `true`; add the needed `ApplyPatchToolType` import if not already in scope. Do not add a new abstraction for a two-field fallback repair.
- Files: `codex-rs/models-manager/src/manager_tests.rs` - extend `get_model_info_tracks_fallback_usage` or add one adjacent test asserting the whole fallback capability contract for an unknown slug: `used_fallback_model_metadata == true`, slug preserved, `apply_patch_tool_type == Some(ApplyPatchToolType::Freeform)`, and `supports_parallel_tool_calls == true`. This is the direct failing test for the fallback metadata source.
- Files: `codex-rs/core/src/tools/spec_plan_tests.rs` - add one focused spec-plan regression that uses fallback model metadata or sets `turn.model_info = codex_models_manager::model_info::model_info_from_slug("gpt-oss:20b")`, keeps an environment present, and asserts `apply_patch` appears in `router.model_visible_specs()`. This proves `codex-rs/core/src/tools/spec_plan.rs:675-678` sees the repaired metadata.
- Files: `codex-rs/core/tests/suite/prompt_caching.rs` - add one unknown-model request-body regression, using a model such as `gpt-oss:20b`, that asserts the captured `/responses` request has `parallel_tool_calls == true`, includes an `apply_patch` tool entry, and keeps the existing `multi_tool_use.parallel` instruction text from `codex-rs/core/gpt_5_2_prompt.md:244-253` in the instructions. This is the exact local test that should fail before production fallback defaults are changed.
- LOC delta: ~+55 / -2 if using existing helpers; ~+80 / -2 if the prompt-caching assertion needs a small local helper for finding tool names.
- Tests to add/modify: 3 tests total: one `codex-models-manager` fallback metadata test, one `codex-core` spec-plan visibility test, one `codex-core` request-body integration test. Run `just fmt`; run `just test -p codex-models-manager`; run focused `just test -p codex-core` targets for `spec_plan_tests` and `prompt_caching` if supported, otherwise `just test -p codex-core`. Because `codex-core` is touched, ask before running full workspace `just test`.
- Governance/ruleset change (if any): none.
- Migration path: no migration needed; unknown models receive the repaired default metadata on next resolution.

## Risks
- Setting `supports_parallel_tool_calls: true` for every unknown non-Lite model may expose third-party Responses-compatible providers that reject the field. The implementation should not broaden beyond the two fallback fields until a provider capability source exists.
- Setting fallback `apply_patch_tool_type` to `Freeform` assumes unknown model endpoints accept custom/freeform tool specs. The local runtime can execute `apply_patch`, but provider acceptance is not proven by parser tests.
- The original live loop may still include hosted-model reasoning behavior after compaction; the proposed tests prove the CLI contract, not model cognition.
- `codex-apply-patch` acceptance criteria in the mirrored issue is misleading for this reproduction. Adding parser-only tests would create false confidence because the failure is in model-visible tool availability, not patch parsing.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — short, for meta-judge)
- Why this is the minimum: GPT-5.4 is already configured correctly at `models.json:101-118`, while unknown fallback metadata disables both capabilities at `model_info.rs:89-92`; changing only those two fallback fields after one failing request/spec test is smaller than adding a profile abstraction or broad prompt changes.
- What I considered but rejected: regression-only coverage for GPT-5.4, because the current checkout already has that model metadata and `prompt_caching.rs` already has visible-tool consistency coverage for known models. I also rejected `codex-apply-patch` tests because they cannot inspect request serialization.
- What I cannot decide alone: whether all third-party unknown models should receive `parallel_tool_calls: true` and freeform custom tools, or whether a provider-gated fallback policy is needed after the first compatibility report.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:minimal:propose:add failing unknown-model request/spec regressions, then repair fallback metadata to advertise apply_patch freeform and parallel tool calls

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Meta-judge requests round 3 convergence for issue #60

TL;DR

• What this is: Round-2 meta-judge arbitration for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60.
• Current state or conclusion: The solvers now agree on the unknown/fallback model reproduction, but not on the exact implementation shape.
• What the controller does next: Re-run design solvers for round 3 with a narrow question on direct fallback field edits vs a private fallback capability profile.

---

Consensus decision

Reference frame: capability negotiation contract. Round 2 made real progress: both implementation solvers now point at unknown/fallback model metadata, such as gpt-oss:20b, rather than a GPT-5.4-only request-contract drift. The delete solver remains a compatible abstain because it shows apply_patch is active, tested, and not a deletion target.

There is still no implementation-bearing consensus. The minimal solver wants a direct two-field fallback metadata repair after a failing unknown-model request/spec test. The structural solver wants a private fallback capability profile/helper in codex-models-manager, plus a slightly broader test and fixture boundary. Those are close, but they differ in abstraction choice, exact scope_paths, expected line count, and test boundary.

Option	Trade-off
Direct two-field fallback repair	Smallest implementation; avoids a new abstraction for two fields, but may leave the capability policy implicit.
Private fallback capability profile/helper	Makes fallback capability policy explicit in codex-models-manager; may be more structure than the current change needs.
Dispatch implementation now	Premature because the two implementation-bearing plans still differ on files, abstraction, and test scope.

The round-3 convergence question is: for issue #60's unknown/fallback model reproduction, should implementation be a direct two-field fallback metadata repair with existing ModelInfo construction, or a private fallback capability helper/profile, and what exact shared scope_paths plus failing tests authorize that production default change?

Each solver should explicitly state whether a new abstraction is allowed, converge on one scope_paths list, name the exact local test that must fail before changing fallback defaults, decide whether fixture churn is in scope, and reconfirm whether codex-apply-patch coverage is not a valid proxy for model-visible tool availability.

📎 Full raw codex output (archival)

---
issue: 60
cluster: issue-60
convergence_round: 2
solver_verdicts:
  minimal: propose
  structural: propose
  delete: abstain
decision: converge
action_mode: plan
canonical_key: openai/codex#15642
next_action: plan
---

## Decision
参考框架：capability negotiation contract。第 2 轮已经产生实质进展：minimal 和 structural 都从第 1 轮的 GPT-5.4-vs-fallback 分歧收敛到 unknown/fallback model metadata 复现路径，delete 的 abstain 也与 Path A issue-driven greenfield 例外兼容，因为它只证明 `apply_patch` 是活跃能力而非删除对象；但尚未达到 implementation-bearing consensus，因为 minimal 明确要求不要为两字段 fallback repair 新增抽象并给出 `spec_plan_tests.rs` 覆盖，而 structural 要求在 `codex-models-manager` 中新增私有 `FallbackToolCapabilityProfile` 并允许不同 core integration test 位置及 fixture churn，二者在 abstraction choice、scope_paths、LOC delta 和测试边界上仍有可执行差异，所以本轮只能继续 converge，而不能 dispatch implement。

## If converge
- Convergence question (specific): For issue #60's unknown/fallback model reproduction, should implementation be a direct two-field fallback metadata repair with existing `ModelInfo` construction, or a private fallback capability helper/profile, and what exact shared `scope_paths` plus failing tests authorize that production default change?
- What each solver should address explicitly:
  - State whether the implementation may add any new abstraction in `codex-rs/models-manager/src/model_info.rs`; if yes, specify the exact private helper/profile shape and why it is worth more than two inline field assignments, and if no, state the exact direct edit.
  - Converge on one `scope_paths` list, including whether `codex-rs/core/src/tools/spec_plan_tests.rs` is required in addition to a core `/responses` request-body regression.
  - Name the exact local test that must fail before changing fallback defaults for `apply_patch_tool_type` and `supports_parallel_tool_calls`.
  - Decide whether fixture churn outside `models-manager`, `core/src/tools`, and `core/tests/suite` is expected implementation scope or only incidental follow-up if tests expose it.
  - Reconfirm that `codex-apply-patch` parser/CLI coverage is not a valid proxy for model-visible tool availability, or identify a concrete parser-facing assertion if any solver still requires that crate.
- Round number this fires: 3; marker payload uses source round `2`
- Progress since prior round: substantial; both implementation solvers now support the unknown/fallback model metadata reproduction and reject GPT-5.4-only regression as insufficient, while delete remains compatible-neutral and documents active `apply_patch` evidence.
- Human-intervention threshold: not reached; round 2 produced new agreement and a narrower remaining implementation-shape question.

## Round audit trail (links to local artifacts)
- solver-minimal: .refactor-loop/logs/phase9-issue60-r2-minimal.log
- solver-structural: .refactor-loop/logs/phase9-issue60-r2-structural.log
- solver-delete: .refactor-loop/logs/phase9-issue60-r2-delete.log
- work-unit-producer: manual-issue (prompt-only provenance)
- work-unit-source-ref: gh-issue-60
- action_mode: plan
- canonical_key: openai/codex#15642
- duplicate_search_summary: router-injected issue snapshot references upstream openai/codex#15642; round-2 solver artifacts checked only through the three allowed paths; no sibling judge artifacts or unlisted solver outputs were used.
- branch: none
- PR: none
- commit: none
- unique_diff_status: not-applicable
- tests_verification: not run; this is design-consensus arbitration only, and no source implementation was authorized.
- resolution: converge
- next_action: plan

⟦AI:AUTO-LOOP⟧
META_JUDGE_DONE:converge:round-2:Decide direct two-field fallback metadata repair vs private fallback capability profile, with one shared scope_paths/test set.

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Delete solver abstains on issue #60 round 3

TL;DR

• What this is: Round-3 delete-solver result for the \ and \ loop.
• Current state or conclusion: Deletion is still unsafe; the active paths are load-bearing, and the delete frame favors direct fallback field edits over a new helper/profile.
• What the controller does next: Converge on direct unknown-model fallback metadata repair guarded by failing metadata, spec-plan, and request-body tests.

---

Delete-solver result

I recommend abstain, not deletion. The local value chain is active: \ is the runtime executor for the model-visible \ tool, \ advertises it only when model metadata says the model supports it, and the Responses request serializes \ from the same metadata contract.

For the round-3 implementation-shape question, the delete framing argues against adding a new private fallback capability profile/helper for this issue. The bug candidate is two fallback metadata fields, so the smaller design is a direct edit in \ after first adding failing contract tests.

Option	Trade-off
Direct two-field fallback repair	Smallest production change; matches the current defect at \ and .
Private fallback capability profile/helper	Makes policy explicit, but is a one-caller wrapper around two fields today.
Delete \ or prompt/request paths	Breaks expected editing and parallel-call behavior instead of fixing missing model-visible capabilities.

Shared scope I would converge on: , , , and . The required pre-change failure should prove that an unknown slug such as \ currently lacks model-visible \ and serializes ; only then should fallback metadata change to freeform \ and .

\ parser/CLI coverage is not a valid proxy here because it cannot observe the model-visible tool list, the \ instruction text, or the Responses \ request field.

📎 Full raw codex output (archival)

---
solver: delete
issue: 60
cluster: issue-60
verdict: abstain
---

## Classification
e) Genuinely needed and right-sized, with no current deletion/collapse justified for the existing `apply_patch`, prompt-guidance, or request-serialization paths. The only overbuild risk in the round-3 question is prospective: adding a new fallback capability profile/helper for two fallback fields would be unnecessary structure unless more capability policy is introduced.

Reference-frame note: capability negotiation contract. A model-visible tool contract should keep runtime dispatch, tool advertisement, and request flags consistent; deleting the active tool or its prompt guidance would make that contract less consistent, not simpler.

## Recommended action
删除求解器应 abstain：不要删除 `ApplyPatchHandler`、`multi_tool_use.parallel` 指令、`parallel_tool_calls` 序列化路径，或 unknown-model fallback metadata 路径；这些都是当前能力协商链路的一部分。若控制器进入实现阶段，我建议采用 direct two-field fallback metadata repair，而不是新增 private fallback capability profile/helper：在 `codex-rs/models-manager/src/model_info.rs` 直接把 unknown fallback 的 `apply_patch_tool_type` 改为 `Some(ApplyPatchToolType::Freeform)`、把 `supports_parallel_tool_calls` 改为 `true`，并用失败优先的 metadata/spec/request-body contract tests 授权该生产默认值变更。`codex-apply-patch` parser/CLI 覆盖不能代理这个问题，因为它看不到模型可见工具列表、prompt instruction text 或 Responses request 的 `parallel_tool_calls` 字段。

## Concrete plan (if propose)
- Files to delete: none
- Caller migrations: none
- Tests to delete: none
- LOC delta: 0
- Philosophy/CLAUDE.md/SPEC/Tier changes (if any): none
- IssueDecompositionPlan: not applicable; issue #60 is bounded to model capability metadata, visible tool planning, and request serialization.

Delete-role convergence guidance for implementation:
- New abstraction: do not add one for this issue. A private `FallbackToolCapabilityProfile` would be a one-caller wrapper around two `ModelInfo` fields today. If later provider-specific fallback policy expands beyond these fields, that later diff can justify a named policy object with more evidence.
- Shared `scope_paths`: `codex-rs/models-manager/src/model_info.rs`, `codex-rs/models-manager/src/manager_tests.rs`, `codex-rs/core/src/tools/spec_plan_tests.rs`, and `codex-rs/core/tests/suite/prompt_caching.rs`.
- Exact failing local tests before production default change: add a `codex-models-manager` fallback metadata test for `model_info_from_slug("gpt-oss:20b")` expecting `used_fallback_model_metadata == true`, `apply_patch_tool_type == Some(ApplyPatchToolType::Freeform)`, and `supports_parallel_tool_calls == true`; add a core spec-plan test that the fallback model exposes `apply_patch` when an environment exists; add a core `/responses` request-body regression that an unknown model request includes the `apply_patch` tool, keeps the `multi_tool_use.parallel` instruction text, and serializes `parallel_tool_calls: true`. These should fail on the current checkout before changing the fallback fields.
- Fixture churn: keep it incidental and only inside the shared paths unless a focused test exposes an expected `ModelInfo` literal that must be updated for the same fallback default contract.

## Reverse-evidence (why this is safe to delete)
- No deletion is safe here. `codex-rs/core/src/tools/handlers/apply_patch.rs:308` implements the active `ToolExecutor` for `apply_patch`, `:313` returns the freeform tool spec, and `:337` requires the custom/freeform payload that model calls use.
- `codex-rs/core/src/tools/spec_plan.rs:675` registers `ApplyPatchHandler` when an environment exists and `turn_context.model_info.apply_patch_tool_type` is present. Deleting the handler or planner condition would remove the file-editing capability that the issue expects to be available.
- `codex-rs/core/src/session/turn.rs:1014` sends `router.model_visible_specs()` into the prompt, and `:1015` copies `turn_context.model_info.supports_parallel_tool_calls` into the prompt contract. `codex-rs/core/src/client.rs:749` serializes that flag as Responses `parallel_tool_calls` unless the model uses Responses Lite.
- `codex-rs/core/gpt_5_2_prompt.md:252` instructs the agent to use `multi_tool_use.parallel`; removing that guidance would hide a desired tool-use pattern rather than repair the missing request capability.
- The known `gpt-5.4` entry already has `apply_patch_tool_type: "freeform"` at `codex-rs/models-manager/models.json:101` and `supports_parallel_tool_calls: true` at `:112`, so a GPT-5.4-only deletion or collapse does not match the current evidence.
- The unknown fallback path is the local defect candidate: `codex-rs/models-manager/src/model_info.rs:89` sets `apply_patch_tool_type: None`, and `:92` sets `supports_parallel_tool_calls: false`. Those are live metadata facts, not dead code.
- Existing integration coverage in `codex-rs/core/tests/suite/shell_serialization.rs:155`, `:197`, and `:237` exercises apply-patch custom tool create, update, and failure behavior. Tests covering this path are load-bearing because they prove runtime dispatch still works once the model-visible contract exposes the tool.
- Git history shows prior cleanup already deleted an obsolete offline fallback/model table and function-style apply-patch paths, leaving the current freeform handler and metadata-driven planner as the active implementation shape.

## Risks
- If unknown third-party endpoints reject freeform custom tools or `parallel_tool_calls`, a direct fallback-default repair could need provider gating. That compatibility question belongs to the implementation solver and tests; it does not make the active `apply_patch` path deletable.
- If future fallback capability policy expands beyond two fields, avoiding a helper now could require a later extraction. That is an acceptable future refactor, not a reason to introduce an abstraction before the policy exists.
- The live upstream loop may include hosted-model reasoning after compaction. Local request-body tests can prove the CLI contract but cannot guarantee the model will never reason incorrectly.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — for meta-judge)
- Why I claim this can be deleted: I do not claim deletion is justified. The correct delete-solver outcome is abstain because every cited path is active and part of the expected capability contract.
- What I checked to verify safety: issue #60 body and comments, fallback metadata source, `gpt-5.4` bundled metadata, `ApplyPatchHandler`, tool planning, prompt construction, Responses request serialization, `multi_tool_use.parallel` prompt guidance, focused apply-patch integration tests, and git history for the relevant files.
- What I cannot decide alone: whether the implementation should globally enable unknown fallback tools for all providers or add provider-specific gating. From the delete frame, the smallest acceptable implementation shape is direct two-field repair with the shared tests above, not deletion and not a new abstraction for two assignments.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:delete:abstain:existing apply_patch and parallel-tool-call paths are active; prefer direct fallback metadata repair plus contract tests over deletion or a new helper

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Structural solver converges on fallback capability policy

TL;DR

• What this is: Round-3 structural design output for issue Codex falling in a loop no apply_patch tool available and cannot call multi_tool_use.parallel #60.
• Current state or conclusion: I recommend a private fallback capability helper in codex-models-manager, with tests at metadata, tool-planning, and request serialization boundaries.
• What the controller does next: Compare this against the other round-3 solvers and dispatch implementation only after the unknown-model tests fail on the current checkout.

---

Structural result

The reproduction target is the unknown-model fallback path, not bundled gpt-5.4. Bundled gpt-5.4 already advertises apply_patch_tool_type: "freeform" and supports_parallel_tool_calls: true, while fallback metadata still disables both capabilities.

ModelInfo is the metadata object that tells codex-core which tools and request flags a model supports. For unknown slugs such as gpt-oss:20b, codex-rs/models-manager/src/model_info.rs:89 currently sets apply_patch_tool_type to None, which prevents codex-rs/core/src/tools/spec_plan.rs:675 from registering the model-visible apply_patch tool. codex-rs/models-manager/src/model_info.rs:92 currently sets supports_parallel_tool_calls to false, which flows through codex-rs/core/src/session/turn.rs:1015 and becomes the serialized /v1/responses parallel_tool_calls flag in codex-rs/core/src/client.rs:749.

I recommend a tiny private helper, FallbackToolCapabilities, inside codex-rs/models-manager/src/model_info.rs. It should set fallback apply_patch_tool_type to Some(ApplyPatchToolType::Freeform) and supports_parallel_tool_calls to true, then keep those two coupled fallback defaults auditable without adding public API or new codex-core branching.

Option	Trade-off
Private fallback capability helper	Makes the two-field fallback policy explicit where unknown-model metadata is built; adds ~18 LOC of private structure.
Direct two-field edit	Smallest code change, but leaves the coupled fallback policy implicit across two downstream consumers.
codex-apply-patch test	Not a valid proxy here because parser tests cannot see the model-visible tool list, instructions, or parallel_tool_calls request flag.

The shared implementation scope should be codex-rs/models-manager/src/model_info.rs, codex-rs/models-manager/src/model_info_tests.rs, codex-rs/core/src/tools/spec_plan_tests.rs, and one request-body integration test in either codex-rs/core/tests/suite/prompt_caching.rs or codex-rs/core/tests/suite/client.rs. No model fixture, schema, or snapshot churn is needed.

📎 Full raw codex output (archival)

---
solver: structural
issue: 60
cluster: issue-60
verdict: propose
---

## PROJECT_RULES clause violated (quoted verbatim)
> Resist adding code to codex-core!
>
> Particularly when introducing a new concept/feature/API, before adding to `codex-core`, consider whether:
>
> - There is an existing crate other than `codex-core` that is an appropriate place for your new code to live.
> - It is time to introduce a new crate to the Cargo workspace for your new functionality. Refactor existing code as necessary to make this happen.
>
> Likewise, when reviewing code, do not hesitate to push back on PRs that would unnecessarily add code to `codex-core`.
>
> Features that change the agent logic MUST add an integration test:
>
> - Provide a list of major logic changes and user-facing behaviors that need to be tested.

## Recommended framing
Reference-frame note: capability negotiation contract. The structurally clean fix is to make unknown-model fallback capability policy explicit in `codex-models-manager`, because fallback `ModelInfo` is the single fact source that drives two separate downstream behaviors: `apply_patch_tool_type` controls whether `codex-core` exposes the freeform `apply_patch` tool, while `supports_parallel_tool_calls` controls whether `/v1/responses` receives `parallel_tool_calls: true`. Use a tiny private helper/profile in `codex-rs/models-manager/src/model_info.rs`, not a new crate and not more `codex-core` branching, then verify the contract at the source, spec-planning boundary, and serialized request boundary. This keeps the policy where the metadata is built, avoids treating `codex-apply-patch` parser tests as a proxy for model-visible tools, and makes the two-field fallback default auditable without fixture churn.

## Concrete plan
- New abstractions (if any): `FallbackToolCapabilities`, a private zero-copy helper in Layer: model metadata, Project: `codex-models-manager`, File: `codex-rs/models-manager/src/model_info.rs`. Shape: `struct FallbackToolCapabilities { apply_patch_tool_type: Option<ApplyPatchToolType>, supports_parallel_tool_calls: bool }` plus `impl Default` returning `Some(ApplyPatchToolType::Freeform)` and `true`; `model_info_from_slug` binds `let tool_capabilities = FallbackToolCapabilities::default();` and assigns both fields from it. This abstraction is allowed because one explicit extension point exists: unknown-model fallback capability policy spans multiple independent `ModelInfo` fields consumed by different crates. Keep it private and do not add public API.
- Files: `codex-rs/models-manager/src/model_info.rs` - import `ApplyPatchToolType`, add the private helper/profile, and wire fallback `ModelInfo` to `Some(ApplyPatchToolType::Freeform)` plus `supports_parallel_tool_calls: true` through that helper.
- Files: `codex-rs/models-manager/src/model_info_tests.rs` - add or extend one fallback metadata test asserting the whole fallback object contract for an unknown slug, including `used_fallback_model_metadata == true`, slug preservation, `apply_patch_tool_type == Some(ApplyPatchToolType::Freeform)`, and `supports_parallel_tool_calls == true`. This is the exact local source test that must fail before changing fallback defaults.
- Files: `codex-rs/core/src/tools/spec_plan_tests.rs` - add one focused model-visible tool test that sets `turn.model_info = codex_models_manager::model_info::model_info_from_slug("gpt-oss:20b")` with a local environment and asserts visible/registered tools contain `apply_patch`. This proves the metadata change reaches `codex-rs/core/src/tools/spec_plan.rs:675-679`, where `ApplyPatchHandler` is registered only when the model advertises an apply-patch type.
- Files: `codex-rs/core/tests/suite/prompt_caching.rs` or `codex-rs/core/tests/suite/client.rs` - add one request-body integration test using `.with_model("gpt-oss:20b")` that captures the first `/v1/responses` POST and asserts `body["model"] == "gpt-oss:20b"`, the serialized `tools` include `apply_patch`, `instructions` contain `multi_tool_use.parallel`, and `body["parallel_tool_calls"] == true`. Prefer `prompt_caching.rs` if reusing `assert_tool_names`; prefer `client.rs` if the local suite conventions around request serialization make the test smaller.
- LOC delta: ~+85 / -2 total: ~+18 / -2 in `model_info.rs`, ~+18 in `model_info_tests.rs`, ~+20 in `spec_plan_tests.rs`, ~+30 in the core integration test.
- Tests to add: 3 behavior tests. `codex-models-manager` unit test for fallback metadata; `codex-core` spec-plan test for model-visible `apply_patch`; `codex-core` integration test for serialized `/v1/responses` `tools`, instructions, and `parallel_tool_calls`.
- Exact failing tests before production default change: the metadata test and request/spec tests should fail on the current checkout because `codex-rs/models-manager/src/model_info.rs:89` sets `apply_patch_tool_type: None` and `:92` sets `supports_parallel_tool_calls: false`. After the helper/profile is wired, those tests should pass.
- `codex-apply-patch` coverage: not in scope and not a valid proxy. That crate can test patch parsing and applying, but it cannot observe whether the model saw the `apply_patch` tool, the `multi_tool_use.parallel` instruction text, or the serialized `parallel_tool_calls` flag.
- Fixture churn: none. Do not edit `codex-rs/models-manager/models.json`, generated schemas, or snapshots; bundled `gpt-5.4` already has `apply_patch_tool_type: "freeform"` at `codex-rs/models-manager/models.json:101` and `supports_parallel_tool_calls: true` at `:112`.
- Schema/protocol changes (if any): none. Existing `ModelInfo` fields and existing Responses request fields are reused.
- Governance/ruleset changes (if any): none. The plan follows the existing rule to keep new capability policy outside `codex-core` where possible and adds integration coverage for changed agent-visible behavior.
- Runtime cost: zero additional request latency, zero extra network hops, one stack allocation for a two-field private helper per unknown-model fallback construction, and no per-turn cost beyond the existing `ModelInfo` field reads.
- If the structural answer is issue decomposition, use the controller-private `IssueDecompositionPlan` boundary and child body artifacts; forbid solver/judge/worker GitHub lifecycle, public issue factories, and any `wakeup_plan.py` decompose action/projection.
- Do not author helper-owned decomposition tracking comments or child fingerprint lines; the checked-in #403 helper is the only writer for the parent tracking grammar and per-child idempotency fingerprints.

## Risks
- This changes defaults for unknown third-party model slugs. If a provider rejects freeform custom tools or parallel tool calls, the fallback could surface provider compatibility failures that were previously hidden by conservative defaults. The mitigation is to keep the change behind fallback metadata only, preserve explicit model catalog/override behavior, and ensure `use_responses_lite` still disables parallel calls at serialization time.
- A private helper/profile could be over-structure for two field assignments. It stays bounded because it is private, zero-copy, not exported, not configurable, and exists only to make one cross-crate fallback capability policy explicit.
- The request-body test proves the CLI contract, not live model reasoning. It can prevent the model being told the wrong thing, but it cannot prove a hosted model will never hallucinate missing tools.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — for meta-judge)
- Why this structure beats a documented exception: The reported loop comes from inconsistent capability facts, so documenting an exception or adding prompt text would leave `tools` and `parallel_tool_calls` inconsistent. Putting policy in fallback metadata fixes the source by construction.
- Why I picked this abstraction over alternatives: Direct two-field edits are acceptable, but the two fields have separate consumers in `codex-core`: `spec_plan.rs` checks `apply_patch_tool_type`, while `turn.rs` and `client.rs` serialize `supports_parallel_tool_calls`. A tiny private helper gives that coupled fallback policy a name without adding public surface.
- What I cannot decide alone: Whether all supported non-OpenAI compatible providers accept freeform custom tools and `parallel_tool_calls`. If maintainers know a provider rejects either capability for unknown slugs, implementation should gate fallback capability by provider before landing the production default.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:structural:propose:use a private fallback capability helper in codex-models-manager, tested at metadata, spec-plan, and request-body boundaries

⟦AI:AUTO-LOOP⟧