OpenAI Agents SDK 0.17.3 Patches the Sandbox Leaks That Make Agent Runtimes Hard to Trust

OpenAI’s latest Agents SDK patch is not the kind of release that wins a demo. Good. The agent stack already has enough demos. What it needs, urgently, is fewer places where credentials leak into command logs, fewer ambiguous sandbox paths, and fewer framework helpers that silently mutate the caller’s state.

That is the useful reading of openai-agents-python v0.17.3. The release lands as a maintenance patch, but the pattern is bigger than the version number: OpenAI is hardening the runtime layer around agent execution. Sandboxes, guardrails, schemas, resumes, and mounts are becoming the real product surface for coding agents. The model loop is just one part of the system now.

The dangerous part was not the mount. It was the instrumentation around the mount.

The most operator-relevant fix is PR #3429, which changes how mountpoint-backed S3 and GCS mounts handle temporary cloud credentials. Previously, credentials could be embedded directly in the mount-s3 shell command. That is a classic “works in development, leaks in production” design: commands get captured by exec instrumentation, logged by wrappers, surfaced in trace tools, pasted into bug reports, or exposed in failure output. Secrets rarely escape through the happy path. They escape through the debugging path.

The patch writes credentials into an owner-only runtime environment file under the sandbox workspace, sources that file from a credential-free command, redirects mount output away from exec instrumentation, and redacts known credential values from mount failure stderr before raising MountCommandError. That is exactly the right kind of inelegant engineering. Passing everything inline is simpler. Not spraying temporary AWS credentials across every observable surface is better.

For teams running agents inside CI or letting agents mount user data, this is not cosmetic. A sandbox with cloud mounts is a small distributed system: the model requests work, the SDK builds commands, the sandbox executes them, the tracer records them, the orchestrator reports errors, and humans inspect the run after something breaks. Every hop is an opportunity to turn a temporary credential into durable evidence. The fix narrows that surface.

Path roots are policy, not string formatting.

PR #3422 rejects relative sandbox workspace roots in WorkspacePathPolicy. The bug sounds small: with root="workspace", normalizing file.py could produce workspace/file.py rather than an absolute sandbox path. The security problem is that path policy depends on invariants. If a helper promises “this path is under the workspace,” that promise should not depend on process current working directory, caller assumptions, or a later normalization step remembering to do the right thing.

Rejecting relative roots is the boring answer and therefore the correct one. Coding agents do not just read and write files. They generate filenames, run commands, inspect repositories, mount storage, and hand paths to tools that may have their own interpretations. A relative root makes every downstream call slightly more conditional. An absolute root makes the boundary explicit enough to test.

The release notes say #3422 was validated with uv run pytest tests/sandbox/test_workspace_paths.py, uv run ruff check src/agents/sandbox tests/sandbox, and uv run pyright. That validation detail matters because these are exactly the bugs that disappear under broad “agent smoke tests.” You find them by writing targeted path-policy tests and trying the weird inputs.

Guardrails that fail silently are not guardrails.

The guardrail and schema changes are less flashy, but they point at another maturity line. PR #3411 logs exceptions raised by individual realtime output guardrails instead of swallowing them with except Exception: continue. A swallowed guardrail failure is worse than no guardrail in some deployments because it creates false confidence. The team believes a check is active. The runtime knows it failed. The user sees neither.

Two schema fixes land in the same patch train. PR #3382 prevents direct FunctionTool(...) construction from mutating the caller’s params_json_schema dict in place while applying strict JSON schema normalization. PR #3385 applies the same deep-copy discipline to the experimental Codex output-schema path, where shallow copying allowed strict-mode side effects such as additionalProperties: false and generated required lists to leak into nested caller-owned objects.

That sounds like framework housekeeping until you put it in a long-lived service. Agent applications reuse tool schemas. They create multiple agents from shared definitions. They run tests that assume one tool declaration does not change because another tool was normalized. In-place schema mutation turns a configuration object into ambient state. The agent may still “work,” but a later run is now operating on a contract the caller did not write. Deep-copying before strict conversion should be the default in agent frameworks because tool definitions are policy surfaces, not scratchpads.

The Vercel sandbox fix, PR #3410, is in the same category of operational hygiene. resume() previously waited around 45 seconds for a terminal stopped or failed sandbox to become RUNNING, which cannot happen. The patch reconnects immediately if a sandbox is already running, waits only for transient states, and closes/recreates terminal sandboxes immediately. Reliability bugs like this become cost bugs in CI and trust bugs in interactive coding tools. A user watching an agent “think” for 45 seconds while the runtime waits on an impossible transition learns the wrong lesson: that agents are flaky, not that a state machine branch was wrong.

There was little public reaction during the research window. Hacker News searches for the release and sandbox credential terms returned nothing useful; Reddit surfaced one adjacent post about OpenAI Agents SDK sandbox providers, with no release-specific discussion. That silence is normal for maintenance patches. It is also why they matter. The most important agent-runtime work often shows up as a PR description, not a keynote.

Practitioners should treat v0.17.3 as a checklist prompt. Mount S3 or GCS storage and inspect every command, stderr path, trace, and error object for secret exposure. Try relative and malformed workspace roots and confirm the SDK rejects them. Kill and resume sandboxes in running, transient, stopped, and failed states. Deliberately break a guardrail and make sure the failure is observable. Reuse schema dicts across tools and verify strict conversion does not mutate caller-owned structures.

The editorial take: OpenAI’s agent SDK is maturing in the only direction that matters for production use. Fewer secret leaks. Stricter sandbox path invariants. More honest guardrail failures. Less schema side-effect magic. “Which coding agent is best?” is becoming the wrong first question. The better one is: which runtime keeps its boundaries intact when the demo path ends?

Sources: OpenAI Agents SDK v0.17.3 release, PR #3429, PR #3422, PR #3410, PR #3411, PR #3382, PR #3385