fix: #425 improve the compatibility for conversationId / previousResponseId + tool calls

[seratch]

This pull request brings openai/openai-agents-python#1827 improvements to TS SDK as well.

Resolves #425

See also: openai/openai-agents-python#1789

[changeset-bot]

🦋 Changeset detected

Latest commit: 9e6afaf

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@openai/agents-core	Patch
@openai/agents-openai	Patch
@openai/agents-realtime	Patch
@openai/agents	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[rm-openai]

@codex review

[seratch]

Since this repo has issues with codex review integration right now, I ran /review command locally, and got the following feedback. This is fair, so need to improve the implementation:

• [P1] Avoid resending prior items when resuming state — packages/agents-core/src/run.ts:352-358 When we resume a run by passing an existing RunState (the documented pattern after handling interruptions/approvals), this newly constructed ServerConversationTracker starts empty. On the very next prepareInput call we therefore resend state._originalInput plus every item already in state._generatedItems before we’ve called trackServerItems. In a server-managed conversation (conversationId or previousResponseId) those items were already sent in the earlier turn, so the resumed request will repeat the previous user message and tool call(s). Concretely, if you run with conversationId, hit a tool approval, approve it, and call runner.run(agent, result.state, { conversationId }), the second invocation will replay the prior tool call back to the API, creating duplicate tool executions / protocol errors. We need to seed the tracker from the existing RunState (or otherwise skip the resend) whenever input is a RunState; without that, approval/resume flows are broken.

Checked Python repo too:

• Python’s runner never accepts an external RunState object—the public entry points Runner.run / run_streamed only take fresh input values and internally start with generated_items: list[RunItem] = [], so
  _ServerConversationTracker.prepare_input always sees an empty list on the first turn of a resume-free run (src/agents/run.py:502-543, src/agents/run.py:147-167).
• Each turn immediately calls server_conversation_tracker.track_server_items(...), repopulating the tracker before the next loop iteration (src/agents/run.py:640-641 and, for streaming, src/agents/run.py:1011-1012). Because
  there’s no API surface that seeds the tracker with historical generated_items, the replay scenario you found in the TypeScript SDK can’t occur in the current Python flow.
• The conversation-id/previous-response-id tests confirm the intended “only send new items” behavior for successive turns within a single invocation (tests/test_agent_runner.py:780-856).

So the TypeScript regression isn’t applicable to the present Python implementation. If we later expose a resumable state similar to TS, we’ll need to seed _ServerConversationTracker with prior items (or skip replay on the
first prepare_input), but that feature doesn’t exist yet.