-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Description
Please read this first
- Have you read the docs? Agents SDK docs => yes
- Have you searched for related issues? => yes
Describe the feature
Here’s a template for a feature request you could submit to the upstream openai/openai-agents-python library. This template is tailored to your use case (wanting a global or environment-based way to set trace_include_sensitive_data for all RunConfig and Runner.run calls):
Hello!
Description and Motivation:
In our usage of the library, we want to ensure that trace_include_sensitive_data is always set to False for all agent runs, to avoid accidentally leaking sensitive data in traces. Currently, this requires us to pass a custom RunConfig with trace_include_sensitive_data=False to every call to Runner.run or similar entry points, which is error-prone and adds boilerplate.
Proposed Solution:
It would be extremely helpful to support a way to set the default value of trace_include_sensitive_data globally, or via an environment variable, so that this setting is consistently applied across the application without needing to modify every callsite.
Possible options include:
- Allowing
RunConfigto readtrace_include_sensitive_datafrom an environment variable (e.g.,OPENAI_AGENTS_TRACE_INCLUDE_SENSITIVE_DATA=false) if not explicitly set. - Adding a global configuration method or context manager that sets the default for all subsequent
RunConfiginstances. - Accepting a default value via a module-level setter, e.g.,
set_trace_include_sensitive_data_default(False).
Example:
# Option 1: environment variable
# export OPENAI_AGENTS_TRACE_INCLUDE_SENSITIVE_DATA=false
# Option 2: programmatic global default
from openai.agents import set_trace_include_sensitive_data_default
set_trace_include_sensitive_data_default(False)Benefits:
- Reduces risk of leaking sensitive data due to missing config at a single callsite.
- Makes application-wide security posture easier to enforce.
- Reduces code duplication and boilerplate.
Alternatives considered:
- Creating local wrappers for
Runner.run(works, but error-prone and easy to miss in large codebases). - Monkey-patching (brittle and discouraged).
Would you consider adding this feature, or is there an existing pattern recommended for this use case?
Thank you for your excellent work on the library!
(PS: I've obviously used an LLM to write this Feature request, it's hard to beat the clarity of an LLM)