spawn_agent(model="gpt-5.4-mini") produces child thread metadata with model="gpt-5.4"

What version of the Codex App are you using (From “About Codex” dialog)?

26.317.21539 (1088)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

## Summary

Codex subagents spawned with `model: "gpt-5.4-mini"` are later recorded in the child thread metadata as `model: "gpt-5.4"`.

This makes the child thread UI show `GPT-5.4`, even though the parent explicitly requested `gpt-5.4-mini`.

## Environment

- Product: Codex desktop app
- Version: `0.116.0-alpha.1`
- Date observed: `2026-03-19`
- Timezone: `America/New_York`

## Expected behavior

When the parent thread calls `spawn_agent` with:

```json
{
  "model": "gpt-5.4-mini",
  "reasoning_effort": "xhigh"
}

the spawned child thread should preserve and display that same model in its persisted metadata and UI.

Actual behavior

The parent thread log shows the subagent was spawned with model: "gpt-5.4-mini", but the child thread’s persisted turn_context records model: "gpt-5.4".

What steps can reproduce the bug?

Minimal repro

1. In Codex desktop, ask the parent agent to spawn a subagent with:

• model: "gpt-5.4-mini"
• reasoning_effort: "xhigh"

1. Open the spawned child thread
2. Check the child thread’s displayed model and persisted session metadata
3. Observe that the child thread is recorded as gpt-5.4

Evidence

Parent thread spawn_agent call:

{
  "agent_type": "explorer",
  "fork_context": true,
  "model": "gpt-5.4-mini",
  "reasoning_effort": "xhigh",
  "message": "Perform a bug-focused review..."
}

Child thread persisted context:

{
  "type": "turn_context",
  "payload": {
    "model": "gpt-5.4",
    "collaboration_mode": {
      "mode": "plan",
      "settings": {
        "model": "gpt-5.4",
        "reasoning_effort": "xhigh"
      }
    }
  }
}

Notes

This proves that:

• the parent requested gpt-5.4-mini
• the child thread metadata was recorded as gpt-5.4

It does not prove from logs alone whether inference actually ran on mini or was remapped before execution.

So the issue appears to be in one of:

• spawn_agent model handling
• child-thread metadata persistence
• UI provenance/display of spawned model

Impact

This makes it hard to trust or verify delegated model selection for:

• cost-sensitive fan-out reviews
• performance comparisons
• debugging subagent behavior differences

Suggested investigation

Please check whether:

• spawn_agent.model is being dropped or normalized during child-thread creation
• child turn_context.model is defaulting to the parent model
• the UI is reading thread-default model instead of actual spawned-run model provenance

```md
### Sanitized log excerpts

Parent session:
```json
{"type":"response_item","payload":{"type":"function_call","name":"spawn_agent","arguments":"{\"agent_type\":\"explorer\",\"fork_context\":true,\"model\":\"gpt-5.4-mini\",\"reasoning_effort\":\"xhigh\",\"message\":\"Perform a bug-focused review...\"}"}}

Child session:

{"type":"turn_context","payload":{"model":"gpt-5.4","collaboration_mode":{"mode":"plan","settings":{"model":"gpt-5.4","reasoning_effort":"xhigh"}}}}

### What is the expected behavior?

_No response_

### Additional information

When a parent thread spawns a subagent with an explicit model override like `model: "gpt-5.4-mini"` and `reasoning_effort: "xhigh"`, the spawned child thread should preserve that exact model in its persisted metadata and display it consistently in the UI.

Concretely, I expect:
- the child thread metadata to record `gpt-5.4-mini`
- the child thread UI/model picker to show `GPT-5.4-mini`
- no silent normalization or fallback to `gpt-5.4` unless Codex explicitly reports that fallback to the user