Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Approval decision transfers across runs when call ID is reused

Open
  • Is something wrong?
#5,413 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
53/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend, security

Research direction

Start in agents/run_state.py at RunState.approve() and trace how approval records are stored and checked when a run resumes. Reproduce the issue with the scripted two-run example in the report, then inspect the existing changed-arguments and no-decision cases. Done when an approval from the first run cannot authorize the repeated call in the second run, while approvals within the issuing run still work.

Written by the indexing model from the issue text.

Description

Description

In the OpenAI Agents SDK (tested on v0.23.1), an approval decision issued in one run can authorize a protected tool call in a different run when the same call_id is used with identical arguments. The approval record is keyed by call_id but not bound to the run lineage.

Location: agents/run_state.py — RunState.approve() accepts a ToolApprovalItem from a previous run.

Reproduction (offline, scripted model)

# Run 1: request approval for write_marker(path="A"), approve it
result1 = await Runner.run(agent, "do it", context=ctx1)
state1 = result1.to_state()
state1.approve(result1.interruptions[0])  # approve args=A
result1b = await Runner.run(agent, state1)  # executes args=A ✓

# Run 2: NEW run, same agent, same tool, same call_id, same args
result2 = await Runner.run(agent, "do it again", context=ctx2)
state2 = result2.to_state()
state2.approve(old_approval_item)  # ← passes the OLD approval item
result2b = await Runner.run(agent, state2)  # executes AGAIN ✓ ← bug

The second run executes the protected callback without a fresh approval decision, because state2.approve() accepts the ToolApprovalItem object from run 1.

Boundaries (verified)

  • Changed arguments are correctly rejected: if args differ, the approval does not transfer
  • No decision → stays interrupted: without any approval, the run correctly waits
  • The issue is specifically the cross-run transfer of the approval object

Impact

In scenarios where serialized sessions are replayed, or a proxy/load balancer reassigns call IDs, a stale approval from a previous interaction can authorize a new execution. The SDK documents call IDs as unique within a run, but does not bind approval records to the issuing run's lineage.

Suggested fix

Bind approval records to the run that issued them (e.g., include a run ID in the approval record and validate it in RunState.approve()). This would prevent cross-run approval transfer without affecting the per-call binding that already works correctly.

Dominant language
Python
Stars
30.2k
Forks
4.9k
Avg merge
12h 35m
Merged PRs (30d)
144

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/openai-agents-python

All issues in openai/openai-agents-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.