Preserve runtime model provider when applying subagent roles
Summary
When applying a subagent role with agent_type, the role's model / model_reasoning_effort settings are reflected in the child thread snapshot.
However, the runtime-configured model_provider instance was not preserved during role application. As a result, the child request could be routed using the post-reload provider configuration instead of the active provider.
Cause
The config reload preserves model_provider_id, but loses the runtime model_provider instance when the role does not explicitly specify model_provider.
Expected Behavior
If a role does not override model_provider, the current runtime provider should be preserved.
Change Made
I updated the role-application path to preserve the current provider instance and added tests covering:
- provider preservation across reload
- wire-level propagation of role
model/reasoning.effortinto the child request body
Verification
just fmtjust test -p codex-core apply_role_preserves_current_model_provider_without_override subagent_role_model_and_reasoning_reach_child_request_body responses_api_parent_and_subagent_requests_include_identity_headers spawn_agent_role_overrides_requested_model_and_reasoning_settings
Diff
Fork compare:
https://github.com/keishimizu26629/codex/compare/main...fix-subagent-role-provider
Upstream PR could not be created because openai/codex restricts PR creation to collaborators.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for flagging. This appears related to #27624, but I do not think it is an exact duplicate.
#27624 reports that
model_reasoning_effortis ignored in Codex App and subagents are spawned withmedium.This issue is narrower: during role application, the config reload preserves
model_provider_idbut does not preserve the runtimemodel_providerinstance. The linked fork diff includes a fix for preserving the provider instance and wire-level test coverage that verifies the subagent child/v1/responsesrequest body contains the role'smodelandreasoning.effort.So this may be related or complementary to #27624, but the proposed change targets a specific provider-preservation issue in the role application path.