Fix potential infinite tool call loop by resetting tool_choice after …

[mini-peanut]

Fix potential infinite tool call loop by resetting tool_choice after tool execution

Summary

This PR fixes an issue where setting tool_choice to "required" or a specific function name could cause models to get stuck in an infinite tool call loop.

When tool_choice is set to force tool usage, this setting persists across model invocations. This PR automatically resets tool_choice to "auto" after tool execution, allowing the model to decide whether to make additional tool calls in subsequent turns.

Unlike using tool_use_behavior="stop_on_first_tool", this approach lets the model continue processing tool results while preventing forced repeated tool calls.

Test plan

• Added tests to verify tool_choice reset behavior for both agent and run_config settings
• Added integration test to verify the solution prevents infinite loops
• All tests pass

Checks

• I've added new tests for the fix
• I've updated the relevant documentation (added comment in code)
• I've run make lint and make format
• I've made sure tests pass

[rm-openai]

This is a good idea! What do you think about making it a configurable param, default to reset=True?

[mini-peanut]

This is a good idea! What do you think about making it a configurable param, default to reset=True?

@rm-openai Thanks for the feedback! I considered adding a config parameter, but wonder if it might add complexity without clear use cases. Most users would want to prevent infinite loops by default, and those with specific needs could already implement custom behaviors through the existing API.

Unless you have specific scenarios in mind where maintaining forced tool calls is beneficial, perhaps the simpler approach is better?

[rm-openai]

@mini-peanut, yeah one use case I had in mind was this:

Setup:

agent = Agent(
  instructions="Use the find_company tool to find the company info. Then use the search_directory tool to get the CEO's email.",
  tools=[find_company, search_directory],
  tool_choice="required",
  tool_use_behavior={"stop_at_tool_names": "search_directory"},

If we reset tool_choice, then we can't trust the Agent to reliably call the second tool.

Thoughts?

[mini-peanut]

@mini-peanut, yeah one use case I had in mind was this:

Setup:

agent = Agent(
  instructions="Use the find_company tool to find the company info. Then use the search_directory tool to get the CEO's email.",
  tools=[find_company, search_directory],
  tool_choice="required",
  tool_use_behavior={"stop_at_tool_names": "search_directory"},

If we reset tool_choice, then we can't trust the Agent to reliably call the second tool.

Thoughts?

@rm-openai Thanks for sharing that use case. I'd like to refine my approach to focus on the specific problem we're solving.

The Problem: Setting tool_choice to "required" or a specific function name can inadvertently cause infinite loops.

Core Hypothesis: When a user forces a single specific function call, they rarely intend for that same function to be repeatedly called in an infinite loop. This differs from intentional sequential calling of different functions.

Problem Scenario: This issue typically manifests in two specific cases:

1. When tool_choice is set to a specific function name, causing the same function to be called repeatedly
2. When tool_choice="required" with only one available tool, which functionally behaves the same way

Concerns with Adding a Configuration Parameter:
Users with legitimate sequential tool usage would need to explicitly set reset_tool_choice_after_use to False.

Targeted Solution: We can address these specific scenarios without disrupting legitimate use cases:

# Only reset in the problematic scenarios where loops are likely unintentional
if (isinstance(tool_choice, str) and tool_choice not in ["auto", "required", "none"]) or 
   (tool_choice == "required" and len(tools) == 1):
    # Reset to "auto"

This approach precisely targets the infinite loop problem without affecting the multi-tool sequential calling pattern you described, and without requiring additional configuration.

[rm-openai]

lgtm - but would you mind fixing lint/typechecking please? can't merge without that

[mini-peanut]

@rm-openai Fixed, and the code should pass the checks. Thanks for your patience

[rm-openai]

Unfortunately looks like typechecking is still not passing

[baderalfahad]

As mentioned earlier, it looks like the original agent instance is being modified. This means the agent may not be guaranteed to use the tool in subsequent runs. This may not be the intended behavior.

Example:

agent = Agent(
    ...
    tools=[custom_tool],
    model_settings=ModelSettings(tool_choice="required"),
)

await Runner.run(agent, "first run")   # starts run with tool_choice="required"
await Runner.run(agent, "second run")  # starts run with tool_choice="auto"

[baderalfahad]

@rm-openai Thoughts?

[rm-openai]

hmm that's true, does feel like an issue with this solution. Maybe we should save it as internal state.

[mini-peanut]

@baderalfahad @rm-openai I've fixed the issue by creating new copies of the agent and model settings objects instead of modifying the original instances. The linting errors have also been resolved. This should pass the type checking now.

[baderalfahad]

If modifying the agent model settings is necessary, this should ideally only be done after checking the run config first. This is because the run config overrides agent-specific settings for a run.

[mini-peanut]

Good point. These two operations should actually be parallel rather than sequential, but putting the run_config check first does make more sense. I've made this change in the latest commit.

[rm-openai]

I'm merging this because it's mostly great. I think it will need a couple of followups:

1. Instead of copying the agent, we should do internal bookkeping of the resets
2. I still think this should be configurable
3. I'm not sure it makes sense to reset the RunConfig ModelSettings.

I'll follow up with all of those!