An approval is meaningful only if it binds to the action
OpenAI’s Python Agents SDK v0.22.3 release, dated September 17, lists a fix to align conditional approvals with validated tool arguments. The release also lists a fix for returning tool-not-found output after a server-managed resume. These are implementation changes in a specific SDK release. They do not establish that every application built with the SDK uses approvals correctly or that a particular workflow is safe.
The useful design question is whether a person reviews the same action the system later executes. If the tool arguments can change after the approval screen is prepared, the approval may describe one operation while the system performs another. A small version update is a reminder to test this handoff directly, especially when tool arguments include account IDs, amounts, recipient addresses, or record changes.
Define the approval object before wiring the UI
Write down the proposed operation in plain terms: who or what will change, what values are involved, and what evidence supports the request. The approval record should identify the exact validated arguments and the version of the action being approved. If a later model turn edits those values, require a new approval. A reviewer should never have to infer whether the approval applies to a changed payload.
Include the reject path. If the arguments are incomplete, invalid, or refer to an unknown tool, the system should stop and show an understandable reason. Do not let a malformed call fall through to a default action or ask a generative model to guess the missing parameter. The error state must be testable as clearly as the allowed path.
Test the data that crosses the boundary
In a sandbox, create one allowed action and one action that should be denied. Inspect the proposed arguments, the validated object, the reviewer’s decision, and the final tool input. Confirm the values match at each step. Then change an argument after the preview and verify that the old approval no longer authorizes the new request. Use synthetic records so a test cannot create a real payment, message, or customer update.
Exercise a resumed or retried session as well. After an interruption, the system may reconstruct state and ask the person to continue. Check that a prior approval is not reused for a different tool, changed values, or stale record. A retry should not be able to turn a blocked action into a successful one by changing how the server represents the arguments.
Treat the SDK patch as a reason to rerun focused checks
Pin the version used by the workflow and add an acceptance test for the approval boundary. Include a recorded example of a valid action, a changed argument, a rejected request, and an unknown tool. Keep the logs limited to what the reviewer needs: action identity, decision, validation result, and outcome. Do not retain sensitive payloads longer than the business requires simply because they are convenient to debug.
Before updating a production agent, inspect the SDK’s full release notes and test the workflows that depend on approvals, sessions, or tool recovery. A changelog item narrows where to look; it is not an attestation. The practical measure of success is that the person sees and approves the action that the system actually performs.