Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Sandbox mount redaction clears caller-owned exceptions in place

Abierto
  • ¿Algo no está bien?
#5,337 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
29.9k
Forks
4.8k
Merge medio
1 d 3 min
PR fusionados (30 d)
213

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openai/openai-agents-python

Todos los issues de openai/openai-agents-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.