If your app pins openai in requirements or a lockfile, read this before you bump the version, not after something breaks.
The Breaking Change: Local Shell Output Now Needs a Call ID
The headline item is a genuine BREAKING CHANGES entry: local shell tool output must now declare a call ID. If your code uses the local shell tool and constructs tool output manually without one, that code needs updating before it works against 3.17.0.
This only bites teams using that specific feature, but for those teams it’s not optional. The fix landed as both a breaking change and a bug fix in the same release, which is the SDK’s way of saying the old behavior, accepting output with no call ID, was itself a latent bug. Check your integration before you upgrade.
Six Feature Areas in One Release
Past the breaking change, 3.17.0 is a genuinely full release:
- External storage configuration management. New API surface for controlling where data gets stored outside the default setup, useful for data residency or retention requirements.
- Safety case retrieval. A new way to pull safety case data through the API.
- Safety warning and deactivation webhook events. New webhook types that fire on safety warnings and account deactivation, so your app can react instead of polling for status.
- Session environment reset events. New events tied to resetting a session’s environment, relevant if you’re building persistent or stateful agent sessions.
- SIP media security for incoming call events. Security additions to how incoming call events are handled, relevant to voice and telephony integrations.
- Environment variable vault credentials. Pull credentials from an environment variable vault instead of hardcoding or manually injecting them.
Two smaller fixes round it out: parse_response now treats null message content as empty instead of erroring, and an internal log.warn call was replaced with log.warning.
The “Security” Flag Here Is a False Positive
If you triage changelogs by scanning for CVEs, this release isn’t one. “Security” shows up because of feature names, safety case retrieval, safety warning events, SIP media security, not a vulnerability fix. The breaking change is what needs your attention, not a patch.
How Scout Sees What Changes After You Upgrade
Python is one of the fastest-growing places for teams to wire LLM calls into an existing app, often sitting right next to a Django, Flask, FastAPI, or Celery backend that’s already handling web traffic and background jobs. A breaking change like this one is exactly the kind of thing that shows up as a confusing production error days after a routine dependency bump, not at upgrade time.
Scout Monitoring doesn’t instrument the OpenAI SDK directly, but it traces your Python application’s own request handling, background jobs, and database queries, the code that calls into it. If this upgrade causes an unexpected error path, Scout’s trace and error views show you exactly where it surfaced in your own code, which is usually the fastest way back to the dependency bump that caused it.
If your app uses the local shell tool, check your integration against the new call ID requirement before you upgrade. Either way, once you have, start a 14-day free trial and see what your application is actually doing in production.
For application monitoring with errors, logs, and traces, Scout Monitoring provides the fastest insights without the bloat.