-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
RunConfig
to readtrace_include_sensitive_data
from 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
RunConfig
instances. - 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)