exec-server: successful sandbox exits build output for a false classification

Open 💬 0 comments Opened Aug 3, 2026 by MikeeI

What variant of Codex are you using?

CLI (exec-server)

What feature would you like to see?

This is a potential performance concern in current exec-server source, not a confirmed user-visible bug: a successful sandboxed process exit rebuilds retained output into an ExecToolCallOutput only to run sandbox-denial classification, although the classifier returns false before inspecting output when exit_code == 0.

Please consider a behavior-preserving fast path that leaves sandbox_denied false for successful exits and constructs the classification input only for nonzero exits.

Additional information

Evidence

  • local_process.rs:923-957 takes the process-map mutex, then for every sandboxed exit rebuilds retained chunks into separate stdout, stderr, and aggregated Vec<u8> values and converts all three to owned strings before calling the classifier.
  • Inner stores the process map behind a shared mutex. Retained output is deterministically capped at 1 MiB per process, with eviction performed while processing output here. For a full retained buffer of valid UTF-8, the constructed vector payloads contain at most about 2 MiB in total (stdout plus stderr, and the aggregate); the owned string payloads contain another about 2 MiB. That is roughly 4 MiB of payload copying/allocation per successful exit while the mutex is held. This is static size accounting, not a benchmark: Vec capacity growth/reallocation and non-UTF-8 replacement can make actual allocator traffic differ.
  • is_likely_sandbox_denied returns false for exit code zero before reading any output, so none of those reconstructed strings can affect the successful-exit result.
  • A realistic source-level scenario is a sandboxed remote command that successfully emits generated source, build/test diagnostics, or another text result near the retained-output cap. The work occurs on every such successful exit; concurrent processes can also wait on the shared process-map mutex.

Impact

Not measured. Exit latency, allocation throughput, and mutex contention have not been measured. The approximately 4 MiB figure above is a valid-UTF-8 payload-size bound derived from the 1 MiB retention limit, not measured latency or production impact.

Question

Would it make sense to gate ExecToolCallOutput construction and sandbox-denial classification on exit_code != 0, while preserving the existing false result for successful sandboxed exits?

I checked all relevant issues, comments, pull requests, discussions, and release notes; this report is not a duplicate.

I am reporting this finding only and am not proposing a pull request unless a maintainer invites one.

Disclosure

Investigated thoroughly with GPT-5.6 Sol (runtime-default reasoning effort), using Oh My Pi as the agent framework.

This report is not generic or unreviewed AI-generated output. Its claims were checked against the cited evidence, and it includes the relevant detail intended to help maintainers resolve the issue.

If reports like this are not useful to the project, please let me know and I will refrain from submitting similar ones. My intent is to help without wasting maintainer time or energy or discouraging their work.

Thank you for your work.

View original on GitHub ↗