Fixes #5394.

The bug

When a caller combines background=True with local function tools, the agent gets stuck retrieving the same completed response on every tool-loop iteration and tool results are never POSTed. After max_iterations the loop exits with empty text.

Root cause

FunctionInvocationLayer.get_response() builds a single mutable_options = dict(options) dict and threads it through every iteration of the tool loop via super_get_response(options=mutable_options). RawOpenAIChatClient._inner_get_response reads continuation_token from that dict and, when present, takes the responses.retrieve(response_id) branch.

After the very first retrieve returns a completed background response, continuation_token is still sitting in mutable_options. Every subsequent iteration therefore re-enters the retrieve branch and hits the same completed response again — never the responses.create/parse path that would POST the tool results.

The HTTP trace from the issue confirms it: 1 POST followed by ~40 GETs of the same response_id, and no tool-result POSTs.

Fix

In _inner_get_response, after the non-streaming retrieve completes, check whether the returned ChatResponse still carries a continuation_token. If it doesn't (i.e. the background operation is no longer in progress), pop continuation_token and background from the caller's options dict in place. FunctionInvocationLayer passes the same dict reference across iterations, so the mutation makes the next iteration fall through to _prepare_request → responses.create(...) and the tool results flow normally.

This is the same change the reporter (@Laende) verified as a runtime monkeypatch, lifted into _chat_client.py.

Scope

• Non-streaming path only. The streaming continuation branch (responses.retrieve(stream=True)) yields chunks inside an async generator and isn't exercised by the tool loop in the same way; leaving that out until someone sees a real reproduction.
• No public API change; the dict being mutated is the options argument that's already owned and re-used by the caller.

Test plan

• Reporter's repro in Python: [Bug]: background=True causes infinite tool-call loop, tool-result submissions inherit background mode #5394 (agent with background=True + function tools): after this fix the HTTP trace should match the monkeypatched trace in the issue — 1 POST, a few GETs while the background response is in progress, then the tool-result POSTs that let the model produce a final answer.
• Existing agent/chat-client tests pass with ruff check / ruff format green locally; happy to add a regression test if a reviewer points me at the right mock scaffolding for client.responses.retrieve.