OpenAI’s Codex coding agent can read files, edit a repository, run commands, and interact with development tools on a user’s machine. Those ...
OpenAI’s Codex coding agent can read files, edit a repository, run commands, and interact with development tools on a user’s machine. Those capabilities make it useful for long-running engineering work, but they also mean that its safety depends heavily on the permissions and sandbox boundaries selected by the user.
AIBase reported that OpenAI had investigated a small number of cases in which Codex deleted files from a user’s home directory. According to the report, the affected sessions were running with Full Access enabled and without sandbox protection.
The specific technical explanation reported by AIBase involved temporary-directory logic interacting incorrectly with the $HOME environment variable. OpenAI has not yet published a public postmortem confirming that exact sequence.
What OpenAI has confirmed publicly is broader and still important: its official Codex documentation warns that Full Access removes the project-directory boundary and may allow unintended destructive actions that result in data loss.
The immediate recommendation is therefore straightforward: keep Codex inside a sandboxed workspace unless unrestricted access is genuinely required and protected by another isolation layer.
The supplied AIBase report describes the issue as occurring under a specific combination of settings:
$HOME environment variable allegedly caused the user’s home directory to be treated as a deletion target.On macOS and Linux, $HOME normally points to the current user’s home directory. That directory may contain:
A recursive deletion aimed at the wrong path can therefore affect far more than the active project.
OpenAI’s current Windows sandbox documentation states that running Codex in Full Access means the agent is no longer limited to the project directory. It may perform unintended destructive actions that lead to data loss.
OpenAI’s permissions documentation defines three built-in permission profiles:
| Permission profile | Filesystem behavior | Appropriate use |
|---|---|---|
:read-only | Local command execution remains read-only | Repository inspection, planning, and review |
:workspace | Writes are allowed inside active workspace roots and system temporary directories | Normal coding and repository maintenance |
:danger-full-access | Local sandbox restrictions are removed | Only when unrestricted access is intentional and separately isolated |
The official documentation also describes the following mode as elevated risk:
codex --dangerously-bypass-approvals-and-sandbox
The same behavior is available through the alias:
codex --yolo
These commands disable both the sandbox and approval prompts. They are included here so users can identify and avoid the risky configuration—not as a recommendation.
OpenAI labels this mode as having no sandbox and no approvals, and says it is not recommended for normal use.
A coding agent does not merely suggest commands. In local-agent mode, it can execute them.
With a workspace sandbox, the operating system and Codex policy restrict where commands can write. A mistaken command may still damage the active project, but it should not be able to freely modify unrelated directories.
With Full Access, that technical boundary is gone. The model and its shell commands may be able to reach:
This is why prompt wording alone is not a sufficient control. Telling an agent to “only edit this folder” is a behavioral instruction. A sandbox is an enforcement boundary.
OpenAI describes sandboxing and approvals as complementary controls:
Removing both controls produces the highest-risk configuration.
Approval prompts can catch a risky operation before it runs, but they are not a substitute for filesystem isolation.
A user can approve the wrong command. An automatic reviewer can also only evaluate actions that are routed through the approval system.
OpenAI’s documentation explains that automatic review examines eligible approval requests for risks such as destructive actions, credential access, data exfiltration, and persistent security weakening.
A typical automatic-review configuration is:
approval_policy = "on-request"
approvals_reviewer = "auto_review"
This can reduce approval fatigue while retaining a review layer.
However, when Codex is launched with a mode that bypasses approvals and the sandbox entirely, there may be no permission boundary for the reviewer to enforce.
The safer pattern is:
OpenAI recommends different defaults depending on whether the working directory is version-controlled:
For a normal repository, the explicit CLI command is:
codex --sandbox workspace-write --ask-for-approval on-request
For inspection without file edits:
codex --sandbox read-only --ask-for-approval on-request
These settings keep Codex inside a defined execution boundary while allowing the user to approve exceptional actions.
OpenAI also documents a middle ground for unattended tasks. Approval prompts can be disabled while the sandbox remains active:
codex --sandbox workspace-write --ask-for-approval never
In this mode, Codex makes a best effort within the workspace restrictions rather than requesting permission to escape them. This is materially safer than disabling both approvals and sandboxing.
The exact controls vary slightly between the ChatGPT desktop app, Codex CLI, and IDE integrations, but the principle is the same.
In the desktop or IDE interface, open the permissions selector near the prompt composer.
Choose a workspace-limited or default sandboxed mode rather than Full Access.
Select a mode that allows Codex to write only within the active project or workspace roots.
In the CLI, use:
codex --sandbox workspace-write --ask-for-approval on-request
When opening an unfamiliar repository, begin with:
codex --sandbox read-only --ask-for-approval on-request
Let Codex inspect the code and propose a plan before granting write access.
Inside Codex, use the status or permissions interface to confirm which directories are considered writable workspace roots.
Do not assume that the folder shown in the editor is the only directory available to the agent.
Use on-request approvals for commands that need additional access.
For lower-friction workflows, consider auto-review rather than eliminating approvals completely.
Changing a configuration file may not retroactively constrain an already running process.
After changing the settings:
config.toml SettingsCodex supports configuration through:
~/.codex/config.toml
For the established sandbox configuration system, a safer default is:
approval_policy = "on-request"
sandbox_mode = "workspace-write"
A stricter inspection profile is:
approval_policy = "on-request"
sandbox_mode = "read-only"
Auto-review can be added without removing the sandbox:
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "auto_review"
OpenAI also documents permission profiles as a newer beta configuration system. A simple workspace profile is:
default_permissions = ":workspace"
A read-only default is:
Describe your idea once, and We0 AI can generate a showcase site, pages, and CMS, then help you attract customers and traffic after launch.
One complete project generation for free registration
Best for trying one complete generation flow and seeing a first project draft quickly.
default_permissions = ":read-only"
Configuration warning: OpenAI says the newer permission-profile system does not compose with the older
sandbox_modesettings. Configure one system or the other; do not place both approaches in the same active configuration and assume they will be combined.
.env FilesFor users testing the beta permission-profile system, OpenAI documents custom policies that extend the built-in workspace boundary.
A project-edit profile can keep the workspace writable while denying access to environment files:
default_permissions = "project-edit"
[permissions.project-edit]
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = false
This policy:
.env files.For many local coding tasks, this is a better starting point than granting broad access to the entire machine.
Organizations can use managed requirements to prevent users from selecting unrestricted sandbox modes.
OpenAI shows an allowlist similar to:
allowed_sandbox_modes = ["read-only", "workspace-write"]
This prevents Full Access from becoming an available sandbox choice in managed environments.
The newer permission-profile system can also be centrally restricted. Administrators can define approved profiles and omit :danger-full-access from the allowed set.
This is useful because a safety policy should not depend entirely on each developer remembering to select the correct mode.
A practical workflow can keep most of Codex’s speed without exposing the full host system.
Start Codex from the project directory, not from the home directory or a parent folder containing unrelated projects.
Avoid using broad paths such as:
~
or:
/
as the active workspace.
OpenAI recommends working on a feature branch and keeping git status clean before handing work to Codex.
A simple preparation sequence is:
git status
git switch -c codex/task-name
git add -A
git commit -m "Checkpoint before Codex task"
Adjust the branch name and commit message for your project.
Small commits make it easier to inspect and revert individual changes.
Do not wait until the end of a long autonomous session before creating the first recoverable checkpoint.
Treat Codex output like a pull request:
For large refactors, dependency experiments, build-system changes, or cleanup tasks, isolate the agent further.
Options include:
OpenAI provides a secure Dev Container example for cases where the container is intended to be the outer isolation boundary.
Version control protects tracked repository files, but not every file on the computer.
Use a backup system that Codex cannot modify through the same user account or mounted filesystem. Examples include offline backups, immutable snapshots, or remote backup services with version history.
When files have just been deleted, further writes can overwrite recoverable disk blocks.
Take the following precautions:
For tracked source code, begin with non-destructive inspection:
git status
git diff
git log --oneline --all
Do not run destructive Git recovery commands until you understand which files and commits remain available.
The AIBase report says OpenAI was updating Full Access warnings and strengthening protections while preparing a more detailed incident analysis.
OpenAI’s current public documentation already includes explicit warnings that Full Access can cause data loss. It also recommends sandbox boundaries, narrow exceptions, approval policies, permission profiles, version-control checkpoints, and isolated development environments.
No official public postmortem for the exact $HOME deletion mechanism was available when this article was prepared.
That means users should rely on the controls that are available now rather than waiting for a future explanation:
A destructive action can result from several layers:
For this reason, safety cannot depend on model accuracy alone.
Normal editing, testing, searching, and local command execution usually fit inside a workspace boundary.
When a task needs one additional directory or network destination, add a narrow exception instead of exposing the entire machine.
Automatic review may help classify approval requests, but it does not make unrestricted execution harmless.
The sandbox remains the strongest local control because it limits what a command can do even when the command itself is wrong.
Codex can edit and delete files when it has write permission. In workspace mode, those actions are limited to configured writable roots; in Full Access, the local sandbox restriction is removed, increasing the potential impact of a mistaken command.
$HOME deletion bug?The supplied AIBase report attributes that explanation to OpenAI’s investigation. OpenAI’s public documentation confirms the broader Full Access data-loss risk, but no public technical postmortem confirming the exact $HOME mechanism was available as of July 17, 2026.
Use :read-only when Codex only needs to inspect a repository. For normal coding, :workspace or workspace-write with on-request approvals provides a practical balance between productivity and containment.
--yolo safe to use?--yolo is an alias for bypassing approvals and the sandbox. OpenAI describes this as an elevated-risk mode with no sandbox and no approvals, so it should not be used on a normal host machine containing valuable files.
Yes. OpenAI documents --ask-for-approval never as compatible with sandbox modes. For example, codex --sandbox workspace-write --ask-for-approval never keeps the workspace boundary while avoiding interactive approval prompts.
No. Git can restore tracked and committed repository files, but it does not automatically protect untracked files, credentials, personal documents, external databases, or unrelated folders. Use separate backups for anything not safely stored in version control.
No. Auto-review evaluates eligible approval requests, while the sandbox enforces filesystem and network boundaries. Keep both controls when possible rather than treating one as a substitute for the other.
It can be reasonable when the container or virtual machine is intentionally designed as the outer security boundary and contains no sensitive mounted data. Review mounts, credentials, network access, and host integrations carefully because Full Access can still damage or expose anything available inside that environment.
The reported Codex file-deletion issue occurred in the highest-risk operating condition: Full Access without a sandbox boundary. AIBase described a suspected $HOME-related cleanup failure, while OpenAI’s public documentation confirms the broader fact that unrestricted access can enable unintended destructive actions and data loss.
Most developers do not need Full Access for ordinary repository work. Workspace-limited writes, on-request approvals, version-control checkpoints, and isolated environments provide a safer operating model without removing Codex’s core coding capabilities.
Users running unattended tasks can disable approval prompts while retaining the workspace sandbox. That is significantly safer than bypassing both protections.
The practical rule is simple: give Codex access to the project it needs—not to the entire machine.
Start from one sentence and have a complete website in minutes.
