Likely CLI has platform-specific logic causing non-macOS "Sandbox was mandated, but no sandbox is available!" on Linux with GPT-4.1 and Model Codex CLI (v0.1.2504301751)

[get-loose]

Closed : same as
#782

What version of Codex is running?

0.1.2504301751

Which model were you using?

gpt-4.1

What platform is your computer?

Linux 6.12.21-4-MANJARO x86_64 unknown

What steps can reproduce the bug?

The Codex CLI (version v0.1.2504301751) crashes with the error

Error: Sandbox was mandated, but no sandbox is available!

when using the gpt-4.1 model on a Linux system (Node.js v23.9.0). The crash occurs after successfully initializing the session and executing a few commands, specifically when attempting file manipulation or shortly thereafter. The CLI seems unable to find or initialize its expected sandboxing environment.

The issue was discovered through a series of troubleshooting steps related to file creation and modification:

1. Initial State (gpt-4.1-mini): Observed inconsistencies in file operations. Codex's internal apply_patch command would result in aborted. Direct shell commands like sh -c 'echo text >> file.txt' also initially failed with aborted.
2. Working Directory & Git: Confirmed Codex was operating in the correct directory, which is a Git repository.
3. Basic File Creation (touch): The touch command successfully created empty files.
4. apply_patch Identified as Internal: Determined that apply_patch is an internal Codex CLI function, not a standard shell command.
5. Standard patch Utility Works: Successfully applied a diff using sh -c 'patch -p1 < my.diff', indicating the underlying system can modify files using standard tools.
6. echo >> Intermittent Success: In a later session with gpt-4.1 (after instructions.md edits), sh -c "echo 'new line' >> touch2.txt" did successfully modify a file, which was contrary to earlier aborted messages for similar commands.
7. Upgrade to gpt-4.1 (Full Model) & Crash: After changing the model in config.yaml to gpt-4.1, a new session was started. Initial commands like pwd and git status worked. However, when prompted to perform a series of file creation, modification (echo ... \| tee ...), and permission checks, the CLI crashed.

What is the expected behavior?

The sandbox should be available.

What do you see instead?

Stack Trace:

Error: Sandbox was mandated, but no sandbox is available!
    at hOe (file:///usr/lib/node_modules/@openai/codex/dist/cli.js:468:433)
    at iO (file:///usr/lib/node_modules/@openai/codex/dist/cli.js:466:2281)
    # ... (further stack frames) ...

• Explicit Error: The primary error message is unambiguous.
• Origin within Codex CLI: The error originates in the Codex CLI's own JavaScript code (file:///usr/lib/node_modules/@openai/codex/dist/cli.js), specifically around line 468 in a function likely named hOe (or similar, due to minification).
• Faulty Sandbox Detection/Initialization: The snippet of minified code provided in the CLI output (if(process.platform==="darwin")...else if(iR)...throw new Error("Sandbox was mandated, but no sandbox is available!")) strongly suggests that the CLI has platform-specific logic for sandboxing. For non-macOS systems (like Linux), it seems to be falling through to a state where it determines a sandbox is required but cannot find/initialize one, leading to the crash. The condition iR is unknown but critical to this logic path for Linux.

The crash appears to be a fundamental issue with the Codex CLI's environment setup or sandboxing logic on the user's specific Linux configuration when gpt-4.1 is active, possibly triggered or exposed by the more complex operations or different internal handling associated with the larger model, or a stricter enforcement of sandboxing.

As part of troubleshooting

a line in instructions.md was changed from:
Assume a sandboxed environment with restricted write capabilities.
to:
Almost always a sandboxed environment with restricted write capabilities, mention when you notice this isn't the case.

Following this change, in a subsequent session with the same prompt that previously triggered the crash (using gpt-4.1), the CLI did not crash. Instead, it proceeded with the requested file operations, though attempts to write content to files via shell commands like echo ... | tee ... still failed (the file remained empty).

Important Caveat: While the crash was avoided in this instance, it can't be (this trivial) that this instruction change fixed the underlying sandbox initialization bug within the Codex CLI. Rather, it may have subtly influenced the AI's command selection process, leading it to choose a sequence of operations that coincidentally did not trigger the CLI's flawed sandboxing logic. The root cause of the "Sandbox was mandated, but no sandbox is available!" error most likely persists.

Additional observation from the Non-Crashing Session with gpt-4.1:

In the sessin where the CLI did not crash (after the instructions.md modification), the following behaviors related to file operations were observed:

• Successful File Creation (empty) & Permission Changes: Commands like touch new_file.txt and chmod g+w new_file.txt executed successfully, creating an empty file and modifying its metadata as expected.
• Persistent Failure to Write File Content: All attempts by the AI to write actual content into files using various shell commands (e.g., echo 'text' --output=file.txt, echo 'text > file.txt', and notably echo text | tee file.txt) consistently failed. Subsequent cat file.txt commands revealed the files remained empty, even when the shell commands themselves did not return an error code. This suggests a specific restriction on writing data streams to files via standard shell I/O, separate from metadata operations.
• AI's Diagnosis: The AI correctly concluded from these tests that file creation (empty) and permission changes were possible, but writing content into files via the shell was 'not possible in this current setup,' attributing this to likely sandboxing or shell restrictions.

These points help illustrate that even when the fatal sandbox initialization error is not triggered, the environment presented by or managed through the Codex CLI has significant, non-obvious restrictions on file content manipulation via common shell tools.

Additional information

User Prompt Leading to Crash

and Subsequent Non-Crash:
(This exact prompt was used with gpt-4.1 in both scenarios:

1. With the original instructions.md below, leading to the crash.
2. After modifying instructions.md [my tired me changed "Assume..." to "Almost always a sandboxed environment with restricted write capabilities, mention when you notice this isn't the case."], which did not result in a crash but still showed file content writing issues.)

Prompt:

  do some checking to see if you can create and modify a file. doublecheck contents of the file you create to see if changes really were applied. also change some permissions for example group +w or -w to check if possible. then discuss the results and how they allign with your instructions

altered for github-readability, originally entered as one-liner as phrased above:

 do some checking to see if you can create and modify a file. 
 doublecheck contents of the file you create to see if changes really were applied. 
 also change some permissions for example group +w or -w to check if possible. 
 then discuss the results and how they allign with your instructions

Config.yaml when crash occured:

(previous file manipulation tests were done with gpt-4.1-mini. After changing to gpt-4.1 only the above prompt was entered and the crash ensued)

    model: gpt-4.1
    provider: OpenAI
    disableResponseStorage: false
    reasoningEffort: high
    history:
      maxSize: 1000
      saveHistory: true
      sensitivePatterns: []
    approvalMode: auto-edit
    fullAutoErrorMode: ask-user
    notify: true

I think that I after permitting some initial actions changed approvalMode to full-auto.

Instructions.md when crash occured:

> Start every session with showing results of pwd.
> Also state if the working folder is a git repository.
> Always try to use your internal 'apply_patch' function first to modify or create files based on a diff.
> When providing a diff for me to apply, present it in the standard unified diff format.
> If your internal 'apply_patch' command results in 'aborted' or fails, OR if I ask you to, use the following method:
> 1. Confirm the filename of the diff (e.g., 'my.diff').
> 2. Then, execute the command: sh -c 'patch -p[strip_level, usually 0 or 1] < [filename_of_diff]'
> Ensure all file changes are done through git-backed patches for safety, as this allows for better tracking and rollback. Therefore, even for simple modifications, prioritize generating a diff and using 'apply_patch' or the 'patch' command 
> fallback. Avoid direct shell redirection like 'echo >>' for file modifications unless explicitly instructed for a specific, simple 
> case.
> Assume a sandboxed environment with restricted write capabilities.
> When asked to write a script always display it and ask to create it as a file.
> When creating a script always add +x.

More system info:

[get-loose@teddy codex]$ yay codex | grep openai-codex
4 aur/openai-codex 0.1.2504301751-1 (+1 0.75) (Installed)
[get-loose@teddy codex]$ cat /etc/os-release
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux
[get-loose@teddy codex]$ uname -a
Linux teddy 6.12.21-4-MANJARO #1 SMP PREEMPT_DYNAMIC Tue, 01 Apr 2025 18:45:30 +0000 x86_64 GNU/Linux
[get-loose@teddy codex]$ node --version
v23.9.0
[get-loose@teddy codex]$ echo $PATH
/home/get-loose/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/rustup/bin:/var/lib/snapd/snap/bin
[get-loose@teddy codex]$ env | grep NODE_
[get-loose@teddy codex]$

A last little note:

I used gemini-2.5-pro-preview to diagnose the codex crash and write this issue.

I've provided all the diagnostic information I can gather with my current expertise. Further debugging of the CLI's internal sandboxing mechanism would likely require deeper knowledge of its architecture. I just use openwebui and codex to increase my understanding of ai and to keep booming.

[get-loose]

Same as #782