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

Sandbox mount redaction clears caller-owned exceptions in place

Open
  • Is something wrong?
#5,337 0 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
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, security

Research direction

Start in redact_mount_error_data and _discard_exception_graph in agents/sandbox/_mount_security.py, then check the same helper in agents.exceptions. Run the reproduction script from the issue to confirm that the saved exception and the one reachable only through __context__ are both emptied. Done means the caller still gets the redacted RuntimeError, the caller's exceptions keep their __dict__, __cause__ and __context__, and the threat-model question about clearing frames is settled by a maintainer decision.

Written by the indexing model from the issue text.

Description

Summary

When a sandbox call fails and its manifest has configured mount authority, redact_mount_error_data replaces the error with a generic RuntimeError. That part works as intended. But before replacing it, _discard_exception_graph mutates the original exception, and every exception reachable from it through __cause__, __context__, args and instance attributes. It clears each one's __dict__ and __cause__/__context__ in place.

Those objects often belong to the caller: an error it saved to raise again, or an unrelated exception it handled earlier that is now in the __context__ chain. After the sandbox call they are empty, so later code that reads them fails in ways that are hard to trace.

Reproduction

Reproduced on openai-agents 0.22.3, 0.23.1 (latest release) and main at 125efa029b4b, with Python 3.13:

import asyncio

from agents.sandbox._mount_security import redact_mount_error_data
from agents.sandbox.entries.mounts import (
    InContainerMountStrategy,
    RcloneMountPattern,
    S3Mount,
)
from agents.sandbox.manifest import Manifest


class AppError(Exception):
    def __init__(self, message: str) -> None:
        super().__init__(message)
        self.message = message


saved = AppError("sandbox start failed")
saved.__cause__ = ValueError("root cause")

held_elsewhere = KeyError("handled earlier, still held by the caller")
held_elsewhere.note = "important"


@redact_mount_error_data
async def start(manifest: Manifest) -> None:
    try:
        raise held_elsewhere
    except KeyError:
        raise saved


async def main() -> None:
    manifest = Manifest(
        entries={
            "data": S3Mount(
                bucket="b",
                access_key_id="AKIA",
                secret_access_key="secret",
                mount_strategy=InContainerMountStrategy(pattern=RcloneMountPattern()),
            )
        }
    )
    try:
        await start(manifest)
    except Exception as raised:
        print("raised:  ", type(raised).__name__, "-", raised)
    print("saved.__dict__: ", saved.__dict__)
    print("saved.__cause__:", repr(saved.__cause__))
    print("saved.message:  ", getattr(saved, "message", "<missing>"))
    print("held_elsewhere.__dict__:", held_elsewhere.__dict__)


asyncio.run(main())

Output:

raised:   RuntimeError - sandbox operation failed while using a protected mount configuration
saved.__dict__:  {}
saved.__cause__: None
saved.message:   <missing>
held_elsewhere.__dict__: {}

Expected: the caller gets the redacted RuntimeError, and saved and held_elsewhere are unchanged.

Actual: both are cleared. held_elsewhere was never raised out of the sandbox call; it is only reachable through __context__.

Impact

We hit this in a Temporal workflow. When sandbox acquisition failed, we saved the temporalio.exceptions.ActivityError and raised it again on later calls, so every call after a failed acquisition failed the same way. The first raise went through BaseSandboxSession.start (decorated with redact_mount_error_data), which emptied the saved object. When we raised it again later, it had no _message or cause, and reading .message raised AttributeError. That error happened in workflow code, so Temporal failed the workflow task and retried it on every replay instead of letting the workflow handle the failure.

Our workaround is to save a detached copy and raise a new copy each time. Any other caller that keeps an exception, or holds one that ends up in a __context__ chain, can hit the same problem.

The same mutation applies to every method decorated with redact_mount_error_data (start, stop, shutdown, aclose, exec, apply_manifest, and others), and to the _discard_exception_graph calls in agents.exceptions.

Suggested fix

The redaction goal can probably be met without mutating objects the SDK doesn't own:

  • Raise the safe replacement with no link to the original (raise safe_error from None, so __cause__ is None and __suppress_context__ is True), and drop the SDK's own references to the original.
  • If frames have to be cleared because locals may hold credentials, clearing the tracebacks (traceback.clear_frames) may be enough on its own, without also clearing each exception's __dict__ and links.
  • If clearing instance state is still needed, limit it to exceptions the SDK created, or document clearly that any exception reachable from a failed sandbox call may be wiped.

We may be missing a threat-model reason for clearing in place. If so, documenting that behaviour on BaseSandboxSession would still help.

Dominant language
Python
Stars
29.9k
Forks
4.8k
Avg merge
1d 3m
Merged PRs (30d)
213

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.