# OpenAI Codex preview made sandbox evidence part of code review

OpenAI launched its cloud-based Codex research preview in May 2025. Its sandboxed task model shows why generated code, command evidence and merge authority must remain separate.

Canonical: https://rangoon.ai/insights/archive-openai-codex-preview-sandbox-review/
Author: Rangoon Editorial (https://rangoon.ai/insights/editorial/)
Published: 2026-10-23
Updated: 2026-10-23
Event date: 2025-05-16
Tags: [OpenAI](https://rangoon.ai/insights/tags/openai/), [Codex](https://rangoon.ai/insights/tags/codex/), [software agents](https://rangoon.ai/insights/tags/software-agents/), [code review](https://rangoon.ai/insights/tags/code-review/)
Source note: Historical retrospective: OpenAI launched Codex as a research preview on May 16, 2025, and published a same-day system-card addendum. This article does not claim current Codex product behavior, sandbox settings or availability.

Image: Codex: isolated task review. Original Rangoon explanatory diagram; conceptual relationships, not an event photograph, vendor interface, or measured result.

## Key takeaways
- A sandbox can bound a task environment, but it does not approve a generated change for merge or deployment.
- Command logs and file citations make an agent result inspectable only when they identify the task environment.
- Review should test the proposed diff and the evidence behind it as separate artifacts.

## Codex launched as a cloud software-engineering preview [source 1](https://openai.com/index/introducing-codex/) [source 2](https://openai.com/index/o3-o4-mini-codex-system-card-addendum/)

On May 16, 2025, OpenAI launched Codex as a research preview of a cloud-based software engineering agent powered by codex-1. The launch post said tasks ran in separate cloud sandbox environments preloaded with a repository and described work such as feature implementation, codebase questions, bug fixes and pull-request proposals. A same-day system-card addendum described the container boundary, including a user-defined development environment and disabled internet access after setup. Those are historical provider statements about that preview configuration.
The release did not turn an agent-produced patch into an approved production change. Its own framing placed inspection and refinement after task completion, and its system-card material distinguished the container environment from the user's larger software-delivery process. This distinction is the useful historical lesson: a constrained work area can improve reviewability without replacing code ownership or release judgment.


## The task receipt needs a boundary as well as a diff

A meaningful agent receipt identifies more than changed files. It should capture repository revision, task text, workspace setup, dependency state, command history, test output, generated diff and any network or credential boundary in force. With this material, a reviewer can ask a concrete question: did the evidence come from the same environment that produced the patch? A transcript without a pinned source revision or an unqualified test log leaves that question unresolved.
The receipt should also list what did not run and why. A sandbox may lack a service, test secret, integration target or operating-system dependency needed for full validation. Hiding such gaps behind a successful unit test makes a change look more complete than its evidence supports. Marking them keeps the handoff honest and gives the repository owner a precise next check.


## Retrospective lesson: evidence supports review; it does not grant authority

Review the patch against the stated task and repository contracts, then review its evidence against the claimed validation. A proposed code change may be mechanically sound while still widening a data flow, modifying an untested migration or crossing a protected path. Conversely, a correct fix may need a new integration check because the agent's sandbox did not include the target service. Each case requires a visible decision by the owner of that boundary.
The safe delivery sequence is therefore bounded: agent proposes, deterministic checks report, reviewers inspect, and the authorized release path decides whether a change proceeds. Preserve the task receipt with the reviewed revision so later debugging can distinguish an agent proposal from a merged result. Codex's May 2025 preview is a useful reference for that sequence because it foregrounded task evidence, while leaving human review and downstream authority as separate steps.


## Sources
1. [OpenAI: Introducing Codex](https://openai.com/index/introducing-codex/)
2. [OpenAI: Addendum to o3 and o4-mini system card, Codex](https://openai.com/index/o3-o4-mini-codex-system-card-addendum/)

## Related reading
- [OpenAI’s Codex general availability release paired SDK access with admin controls](https://rangoon.ai/insights/archive-openai-codex-general-availability-october-2025/)
- [Terminal-Bench released version 2.0 with Harbor and renewed task verification](https://rangoon.ai/insights/archive-terminal-bench-two-harbor-verified-terminal-evaluation-november-2025/)
- [OpenAI released PaperBench to evaluate agents replicating AI research](https://rangoon.ai/insights/archive-openai-paperbench-ai-research-replication-april-2025/)

## More information

- [Documentation index](https://rangoon.ai/llms.txt)
- [AI access and policies](https://rangoon.ai/ai/)
- [Source repository](https://github.com/hypler-dev/rangoon)