Deferred interrupted-turn session items are never persisted when an approval resume goes through next_step_run_again, leaving an orphaned function_call_output

[dixso]

Summary

Since the blocked-output deferral landed (#4507, released in 0.22.0), an agent that has
both output_guardrails and tool_use_behavior != "run_llm_again" defers the
interrupted turn's session items when a needs_approval tool parks
(_should_defer_interrupted_session_items in run_internal/blocked_output.py). The park-time
session write for that turn is [] by design.

But when the approval is resumed and the approved tool is not a terminal tool (so the
resolved turn's next step is next_step_run_again), no code path ever persists the deferred
items: the resume-side write (_save_resumed_items → save_resumed_turn_items) only carries
the resolved turn's new_step_items (the tool output), and the final-output sweep
(_final_turn_items_for_persistence) only covers the final response's items.

The result in the Session: a function_call_output whose function_call was never written.
On the next Runner.run(..., session=session) the provider rejects the whole conversation:

openai.BadRequestError: Error code: 400 - No tool call found for function call
output with call_id call_ORPHAN

Since the orphan is durable in the Session, every subsequent turn fails the same way; the
conversation is permanently dead.

Debug information

• Agents SDK version: main @ 89c02c8 (also affects released 0.22.0, which fails earlier with Serialized approval checkpoints cannot be resumed with output guardrails when the interruption follows an earlier model response #4611)
• Python version: 3.12
• Operating system: Linux (python:3.12-slim container) and macOS
• Model and model provider: none needed, agents.testing.ScriptedModel
• Does the issue reproduce with the latest Agents SDK release? 0.22.0 cannot reach it: the resume dies first with Serialized approval checkpoints cannot be resumed with output guardrails when the interruption follows an earlier model response #4611. On main (where fix: preserve serialized approval resume ownership #4613 fixed that) it reproduces.
• Does the issue occur consistently or intermittently? Consistently, 100% deterministic.

Version matrix (same reproducer, three versions)

Version	Outcome
0.21.1	OK: the parked function_call is written at interruption time, pair complete
0.22.0	resume dies first with UserError: Cannot resume a serialized approval checkpoint with output guardrails… (#4611)
main @ 89c02c8	resume proceeds (#4613), tool executes, but the parked function_call is never persisted → orphaned output, session permanently rejected by the API

So 0.22.0 hid this behind #4611; #4613 unblocks the resume and exposes it.

Minimal reproducer

No API key, no network (ScriptedModel, SQLiteSession). The only thing it does beyond
tests/test_hitl_session_scenario.py is (a) the agent has output_guardrails and
StopAtTools, matching the deferral gate, and (b) the RunState round-trips through JSON,
as any app that parks the approval in its own store (Redis, a DB row) and resumes in a later
process must do.

import asyncio
import json

from agents import (
    Agent,
    GuardrailFunctionOutput,
    Runner,
    RunState,
    SQLiteSession,
    StopAtTools,
    function_tool,
    output_guardrail,
)
from agents.testing import ModelStep, ScriptedModel, assistant_message, function_call


@function_tool(name_override="write_thing", needs_approval=True)
def write_thing(query: str) -> str:
    return f"wrote:{query}"


@function_tool(name_override="look_up", needs_approval=False)
def look_up(query: str) -> str:
    return f"schema for {query}"


@output_guardrail
async def always_fine(ctx, agent, output) -> GuardrailFunctionOutput:
    return GuardrailFunctionOutput(output_info=None, tripwire_triggered=False)


def make_model() -> ScriptedModel:
    # Two model turns, like a real agent: an ungated lookup first, THEN the gated write.
    return ScriptedModel(
        [
            ModelStep(output=[function_call("look_up", {"query": "x"}, call_id="call_LOOKUP")]),
            ModelStep(output=[function_call("write_thing", {"query": "x"}, call_id="call_ORPHAN")]),
            ModelStep(output=[assistant_message("done")]),
        ]
    )


async def run_streamed(agent, inp, session):
    result = Runner.run_streamed(agent, inp, session=session)
    async for _ in result.stream_events():
        pass
    return result


async def main() -> None:
    session = SQLiteSession("repro", ":memory:")
    agent = Agent(
        name="repro",
        instructions="Always call write_thing.",
        model=make_model(),
        tools=[look_up, write_thing],
        # The two conditions that open _should_defer_interrupted_session_items:
        # output guardrails AND tool_use_behavior != "run_llm_again". The approved
        # tool is NOT in the stop list, so the resume goes through next_step_run_again.
        output_guardrails=[always_fine],
        tool_use_behavior=StopAtTools(stop_at_tool_names=["finish"]),
    )

    first = await run_streamed(agent, "do the thing", session)
    assert len(first.interruptions) == 1

    # Park in an external store and resume from it, as a multi-process app must.
    serialized = json.dumps(first.to_state().to_json())
    state = await RunState.from_json(agent, json.loads(serialized))
    state.approve(state.get_interruptions()[0])

    await run_streamed(agent, state, session)

    items = await session.get_items()
    calls = {i.get("call_id") for i in items if i.get("type") == "function_call"}
    outputs = [i for i in items if i.get("type") == "function_call_output"]
    orphans = [o for o in outputs if o.get("call_id") not in calls]

    for i in items:
        print(f"  {i.get('type') or i.get('role'):22} {i.get('call_id', '')}")
    print(f"ORPHANED OUTPUTS: {len(orphans)}")
    assert not orphans, "the Session now poisons every future run with a 400"


asyncio.run(main())

Output on main (89c02c8):

  user
  function_call          call_LOOKUP
  function_call_output   call_LOOKUP
  function_call_output   call_ORPHAN     <-- its function_call was never written
  message
ORPHANED OUTPUTS: 1

Expected (and what 0.21.1 does):

  user
  function_call          call_LOOKUP
  function_call_output   call_LOOKUP
  function_call          call_ORPHAN
  function_call_output   call_ORPHAN
  message

Mechanism (as far as we traced it)

1. Park: run_loop.py → _finalize_streamed_interruption(items=[] if _should_defer_interrupted_session_items(...) else turn_session_items). With guardrails +
   non-default tool_use_behavior, the interrupted turn's items (the function_call and the
   approval item) are deferred: RunState._session_items carries them,
   current_turn_persisted_item_count == 0.
2. Resume after state.approve(...): resolve_interrupted_turn executes the tool; next step
   is next_step_run_again (approved tool is not terminal). The write that runs is
   _save_resumed_items(list(turn_session_items)) where turn_session_items = session_items_for_turn(turn_result) = the resolved turn's new_step_items = the tool
   output only. The deferred function_call is in run_state._session_items but is
   never part of any write.
3. The final output arrives on a later model response, so
   _final_turn_items_for_persistence (the deferral's final sweep) only considers that
   response's items and cannot recover the earlier deferred call.

Note the non-streamed Runner.run resume path has the same shape (run.py, the
save_resumed_turn_items call guarded by the same _should_defer_interrupted_session_items).

Impact

Any app that (a) uses needs_approval tools with a client-managed Session, (b) has output
guardrails, (c) uses StopAtTools or any non-default tool_use_behavior, and (d) resumes an
approval where the approved tool is not terminal, ends up with a Session the API permanently
rejects. The failure is delayed (the approving turn itself succeeds), which makes it hard to
trace back.

Fix

We have a candidate fix with a regression test, verified against our integration and against
the full test suite (no new failures): once the resume commits to continuing the run
(run-again / handoff), it persists the deferred prefix — located via the already-computed
resumed response boundary — ahead of the resolved turn's items, in both the streamed and
non-streamed paths. PR incoming right after this issue; happy to adjust it to whatever design
you prefer.

[dixso]

Root cause: the deferral is never declared, and the SDK already has the slot for it

Working on the fix (#4828) turned into a sequence of ever-narrower edge cases — a resume
that ends in a terminal tool, a detached resume reconnected later, a partial approval that
re-interrupts, an after-turn cancellation. Each one had the same shape, and that shape is
the actual bug.

_should_defer_interrupted_session_items holds back the interrupted turn's write and
leaves no record that it did. Nothing downstream can then distinguish

• "this response was never written", from
• "this response had nothing to write",

so every resume exit has to infer it — from _current_turn_persisted_item_count, from
item content, from the Session tail. Every inference has a blind spot, because the
counter can be legitimately reset (the detached-resume path in
_validate_resumed_session_output_guardrail_safety), content repeats verbatim across
turns, and the tail is not stable across cancellation. That is precisely the invariant
AGENTS.md asks about at a mutation boundary — ownership/serialization — and it is missing
at the park, not at the resume.

The SDK already has the durable slot for exactly this. RunState._pending_session_write
is documented as "one canonical resumed-output append awaiting acknowledgement": it is
serialized by to_json, validated and restored by from_json, and settled by
resume_pending_session_write with an ordered reconciliation that tolerates an
already-committed batch. save_result_to_session uses that register-then-settle pattern
today for the resumed-write case (#4630).

So the natural fix looks like: when the park defers, record the withheld batch in
_pending_session_write instead of silently dropping it, and settle it on the next resume
that has the original Session attached. The whole family of edge cases collapses, because
the fact survives serialization, a detached resume and a cancellation by construction,
instead of being re-derived at each exit.

I prototyped it. It works for the streamed park and for a resume that continues the run,
but it is not complete as an external change: RunResult.to_state() builds a fresh
RunState from the result via _populate_state_from_result, which does not carry
_pending_session_write. Making the deferral survive that path means extending the
result's serialized surface — a public-contract decision that is yours to make, and one
AGENTS.md explicitly asks to be traced through every construction and consumption path.

Happy to finish it in whichever direction you prefer, or to hand over the prototype if you
would rather own that part. The reproducer in this issue is unchanged and still fails on
main.

[dixso]

One more data point, since I took the prototype further and hit the design decision head-on.

Recording the withheld batch in _pending_session_write and settling it on the next
attached resume does remove the orphan on every path I could construct (terminal-tool
resume, detached-then-reattached, partial approval that re-interrupts, streamed and
non-streaming alike). Two things were needed beyond the park itself:

1. RunResult.to_state() builds a fresh RunState via _populate_state_from_result,
   which only carries _pending_session_write when the result happens to hold a
   _state. The deferral has to travel with the result the same way
   _current_turn_persisted_item_count already does, or the very first park loses it.
2. The batch's persisted_count has to be the count as it will stand after the batch
   lands (mirroring what save_result_to_session records for a resumed write), otherwise
   the final-turn sweep writes the same response a second time.

And that second point runs straight into an existing invariant:

UserError: Cannot resume an approval checkpoint with output guardrails after
current-turn items were persisted. Start a new run from safe input.

which is exactly what settling a deferred batch makes true. So "declare the deferral and
settle it on resume" needs a deliberate answer to how it coexists with that guard —
whether settling counts as "persisted current-turn items" for the purpose of that check,
or whether the deferred batch is a distinct category the guard should ignore. That is a
call about your own invariants, not something I can safely infer from outside.

Which is why I have stopped there rather than pushing a guess. The prototype is small
(it deletes more of #4828 than it adds) and I am happy to send it as a separate PR, adapt
it to whichever answer you prefer, or drop it entirely if you would rather fix this at the
park with a different shape. #4828 as it stands closes the case the reproducer shows; this
is about closing the whole class.

[dixso]

One framing that may help place this, since the repo has already accepted the mirror image
of it.

#4615 ("RunState retry after an approved tool's Session write fails leaves an orphan tool
call") reported a Session left with a function_call whose function_call_output never
landed, and #4630 fixed it by recovering the failed write before the next model call. That
established the principle this issue relies on: a Session write that does not happen must
not leave the history inconsistent.

What is reported here is the same principle in the opposite direction:

	missing item	consequence
#4615 (fixed)	the output	the SDK prunes the unmatched call from model input; the completed action silently disappears from context
this issue	the call	the provider rejects the entire conversation with 400 No tool call found for function call output, on that turn and every later one

The second is the harsher of the two: pruning loses context, while an orphaned output makes
the Session permanently unusable, and it is durable — every replay hits the same 400.

The two also differ in origin, which is why #4630 does not cover this one. There the write
was attempted and failed; here it is never attempted at all, because
_should_defer_interrupted_session_items withholds it by design and nothing later knows it
was withheld. That is the gap the reproducer in this issue exercises, and it is why the fix
belongs at the park (declare what was withheld) rather than in the retry path.

Worth noting for anyone weighing severity: the orphaned-output shape is reachable on 0.21.1
too, whenever the interruption-time write itself fails — we reproduced that separately
against a deliberately degraded backend, with the 0.22 defect already fixed. So this is not
purely a 0.22 regression; 0.22 just makes the common path produce it every time.