A local diagnostic that checks whether your current Codex setup actually enforces the Windows sandbox boundary and how your user-level execpolicy rules classify common deletion commands.
It uses only disposable synthetic files. It does not open, scan, modify, or delete files from a real project.
Version: 0.1.0-alpha.11
Alpha status: This is an early test build. It produces evidence about a specific Codex version and configuration; it does not certify that a computer is secure.
Unofficial project. Not affiliated with, endorsed by, or supported by OpenAI.
All screenshots contain synthetic or redacted demo data only.
Codex uses several safety and execution-control layers, each with a different role:
- the Windows sandbox controls filesystem and network boundaries;
- permission and approval settings control when Codex may proceed or must ask;
- execpolicy rules classify commands that request execution outside the sandbox.
Those layers are easy to confuse. A rule can appear strict while a writable workspace still permits file creation, modification, and deletion. Conversely, a command can fail because the Windows sandbox itself blocked the target path, regardless of how the command was spelled.
Codex Safety Canary reports those distinctions instead of collapsing them into a vague “safe” or “unsafe” result.
The Canary records only selected non-secret facts:
- Windows and Node.js versions;
- Codex CLI version;
- effective
CODEX_HOME; - whether
config.tomlandauth.jsonexist; - selected safety-relevant settings such as
sandbox_mode,approval_policy,default_permissions, andwindows.sandbox; - user-level
.rulesfiles under%CODEX_HOME%\rules.
It never reads or prints the contents of auth.json.
Using the official, currently experimental codex execpolicy check command, the Canary evaluates common deletion forms against the detected user-level rule files:
- PowerShell
Remove-Item; - PowerShell 7 wrapper commands;
cmd.exe del;- Node.js
fs.rmSync; git clean -fd;git reset --hard.
Execpolicy rules govern commands that request execution outside the sandbox. They do not make files inside a writable workspace undeletable.
Codex Safety Canary distinguishes these installation layouts without repairing or mixing them:
| Layout | What the Canary records | What it does not assume |
|---|---|---|
| Classic bundle | codex.exe and sandbox helpers beside the same executable. |
A boundary pass without completed live probes. |
| Standalone package | Resources under %CODEX_HOME%\packages\standalone\current and %CODEX_HOME%\packages\standalone\releases\*. |
That the active launcher can resolve those helpers at runtime. |
| Doctor output | Read-only inventory hints from codex doctor --json when available. |
Sandbox readiness or filesystem-boundary protection. |
On Windows, the codex.exe resolved through PATH can exist in a different directory from matching sandbox helper files. The Canary records file layout, helper resolution, runtime startup, and boundary evidence separately.
If the active bundle is incomplete, it searches these known local installation roots and standalone package locations:
%LOCALAPPDATA%\OpenAI\Codex\bin
%LOCALAPPDATA%\Programs\OpenAI\Codex\bin
%CODEX_HOME%\packages\standalone\current
%CODEX_HOME%\packages\standalone\releases\*
For standalone packages, helper resources such as codex-windows-sandbox-setup.exe, codex-command-runner.exe, and rg.exe are recorded separately from launcher resolution. Resource layout, helper resolution, runtime startup, and boundary verdict are reported as separate states. If multiple probe-eligible local executables exist, the Canary presents a deduplicated list and keeps the active PATH CLI first as the recommended choice. A same-version or newer alternative must be selected explicitly, and its result applies only to that executable. A newer alternative also carries a version-mismatch warning.
The Canary may report STANDALONE_RESOURCES_FOUND, SANDBOX_SETUP_HELPER_NOT_RESOLVED, COMMAND_RUNNER_PROCESS_CREATION_FAILED, or DOCTOR_OK_BUT_RUNTIME_FAILED to separate package inventory from runtime startup. The Canary uses an alternative executable only for disposable live probes. It does not copy files, create symlinks, modify PATH, run automatic repair, or change the Codex installation. Older or sandbox-unavailable bundles are not offered.
Before any deletion probe, a harmless sandbox smoke test runs cmd.exe /c echo through the selected Codex executable. Each PowerShell, cmd.exe, and Node.js deletion runner is also calibrated against its own synthetic control file outside the Codex sandbox. An outside-boundary PASS requires that method's host calibration to pass. If sandbox setup fails, no deletion probes are attempted.
The optional live test uses the installed CLI's general codex sandbox -- <COMMAND> interface directly. It does not call a model and does not consume Codex tokens.
The Canary creates a temporary workspace and a separate control folder under:
%LOCALAPPDATA%\CodexSafetyCanary\runs\
It tests three runtime paths in matched pairs:
- PowerShell deletion inside and outside the workspace;
cmd.exedeletion inside and outside the workspace;- Node.js filesystem deletion inside and outside the workspace.
The current codex sandbox developer command is invoked with the built-in :workspace permission profile and the disposable workspace is supplied explicitly with --cd. A boundary PASS requires the complete structured PowerShell, cmd.exe, and Node.js matrix (3/3): every runtime must delete its inside file and produce target-bound access-denied evidence for its outside file. Successful individual methods inside an incomplete, interrupted, or contradictory matrix do not establish any boundary protection. Such technical evidence is reported as TEST ERROR / INCOMPLETE; NOT TESTED means that no boundary conclusion was produced. PARTIAL describes only an assessment flow that stopped before live probes, such as an explicit decline, and its boundary remains NOT TESTED. The run folder is cleaned up before the final reports are written, so the structured cleanup status is included consistently in every report format.
Requirements to start the Canary:
- native Windows;
- Node.js 18 or newer in
PATH, or a compatible Node runtime available in a recognized Codex desktop runtime cache.
Node.js 22 or 24 is recommended. Node.js 18 and 20 remain compatibility targets, but both release lines are end-of-life and should not be preferred for new installations.
For the full Codex assessment, a working Codex CLI callable as codex is
required. Alpha 11 may additionally list alternative local executables, but it
never selects one silently.
Then double-click:
codex-safety-canary.cmd
Choose:
[1] Run the safe guided assessment
The guided assessment first performs a read-only configuration scan and rule check. Before any live probe, it states exactly where the disposable files will be created and asks for confirmation. When more than one probe-eligible executable is available, Guided and Sandbox-only assessments show the source, version, exact path, resource layout, and sandbox status for each choice. The active PATH CLI remains the recommended default. Every alternative executable, including a same-version bundle, is clearly labeled as a separate test that does not validate the active CLI; a newer alternative also shows a version warning.
Do not run the launcher as Administrator. The live test intentionally refuses to run elevated because that would not represent a normal Codex user session.
Reports are written outside projects:
%LOCALAPPDATA%\CodexSafetyCanary\reports\
Each assessment creates:
- a detailed readable
.txtreport with local diagnostic paths; - a detailed machine-readable
.jsonreport; - a share-safe
-support.txtreport without usernames, executable paths, project paths, credential paths, or raw configuration contents; - a corresponding share-safe
-support.jsonreport.
The support reports intentionally retain diagnostic version, installation, runtime, and security-status information needed for troubleshooting. “Share-safe” describes a risk-reduced support representation, not an anonymity or secrecy guarantee, and does not remove all diagnostic host context. The detailed text report opens automatically in Notepad. Menu option 6 opens the latest share-safe support report. Automatic redaction reduces disclosure risk, but review the support report before attaching it to a public issue.
A method-level PASS means that one complete runtime pair behaved as expected: its inside-workspace file was deleted and its outside-workspace file remained with target-bound access-denied evidence.
An overall sandbox-boundary PASS requires the complete structured PowerShell, cmd.exe, and Node.js matrix (3/3). Successful individual methods inside an incomplete, interrupted, or contradictory matrix do not establish an overall boundary pass.
A synthetic file outside the active workspace was deleted. This is a serious boundary failure for the tested configuration and Codex version.
A file inside the writable workspace was deleted. This demonstrates that workspace-write protects the boundary around a workspace – not every file inside it.
The tested command is covered by the detected execpolicy rules when it requests execution outside the sandbox.
NO_MATCH is a valid execpolicy result: the CLI returned an empty matchedRules array and no restrictive rule covered that command. This does not by itself prove a sandbox bypass; rules and filesystem sandboxing are separate layers. A result such as 0/6 describes only additional user-level execpolicy coverage. It is not the sandbox boundary score.
The report evaluates installations separately:
ACTIVE CLI
Version: 0.145.0
Resource layout: MISSING
Helper resolution: NOT_TESTED
Runtime startup: NOT_TESTED
Boundary status: NOT TESTED
TESTED BUNDLE
Version: 0.146.0-alpha.3
Resource layout: COMPLETE
Helper resolution: CONFIRMED
Runtime startup: READY
Boundary status: PASS
Methods tested: 3/3
A passing alternative bundle does not validate an incomplete codex.exe resolved through PATH. When a split installation is detected, the report recommends updating or reinstalling the official Codex CLI, opening a new non-administrator PowerShell session, and rerunning the Canary. Do not manually mix helper executables from different Codex versions.
Codex Safety Canary is:
- a local diagnostic;
- Windows-first;
- Codex CLI-specific in version 0.1 – it does not yet test the desktop app or IDE extension;
- designed to use only disposable synthetic test files;
- read-only with respect to real projects and Codex credentials.
It is not:
- a backup or undelete system;
- a command blocker;
- a replacement for Codex sandboxing or approvals;
- a malware scanner;
- a security certification;
- proof that every possible command form is covered.
The Canary distinguishes a sandbox command that exists from a sandbox runtime that actually starts. A failed helper launch is TEST ERROR, never PASS.
Results are version-specific. Re-run the Canary after changing Codex, Windows sandbox settings, permission profiles, or rule files.
Windows may mark a downloaded ZIP as originating from the internet. Before extracting it:
- right-click the ZIP;
- choose Properties;
- enable Unblock / Zulassen, if shown;
- extract the ZIP again.
Do not disable Smart App Control and do not routinely run the launcher as Administrator.
- Codex sandbox and approvals: https://developers.openai.com/codex/agent-approvals-security
- Codex permissions: https://developers.openai.com/codex/permissions
- Codex rules and
execpolicy check: https://developers.openai.com/codex/rules - Codex CLI reference: https://developers.openai.com/codex/cli/reference
npm test
npm run checkAutomated tests cover parsing, valid execpolicy no-match output, safe path cleanup, selected configuration extraction, rule-decision normalization, version comparison, split-installation bundle selection, fail-closed probe planning, alternative-bundle attribution, separate active/tested-bundle reporting, share-safe report generation, and report semantics. The actual native Windows sandbox can only be validated on a Windows machine with Codex installed.
MIT License. See LICENSE.