OpenAI Warns Codex Full Access Can Cause Data Loss

Introduction

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.

What the Reported File-Deletion Issue Involved

The supplied AIBase report describes the issue as occurring under a specific combination of settings:

1. Codex was given Full Access to the local machine.
2. The sandbox boundary was disabled.
3. Approval or automatic-review protections were not active.
4. A task attempted to create or use a temporary working directory.
5. An error involving the $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:

• Desktop and Documents folders.
• Source-code repositories.
• SSH configuration and keys.
• Application settings.
• Shell profiles.
• Local databases.
• Personal files.
• Cloud-sync folders.

A recursive deletion aimed at the wrong path can therefore affect far more than the active project.

What OpenAI Officially Warns About

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.

Why Full Access Changes the Risk So Much

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:

• The full home directory.
• Other repositories.
• Mounted disks.
• Cloud-synchronized folders.
• Credential files.
• Package-manager configuration.
• Local application data.
• External tools available to the user account.

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:

• The sandbox determines what the agent can technically access.
• The approval policy determines when the agent must stop and ask before crossing a boundary.

Removing both controls produces the highest-risk configuration.

Approval Prompts and Auto-Review Are Not the Same as a Sandbox

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:

1. Keep the workspace sandbox enabled.
2. Use on-request approvals or auto-review.
3. Add narrowly scoped exceptions only when needed.
4. Avoid unrestricted access on the host machine.

OpenAI’s Recommended Default Modes

OpenAI recommends different defaults depending on whether the working directory is version-controlled:

• Version-controlled folder: workspace write with on-request approvals.
• Non-version-controlled folder: read-only mode.

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.

How to Disable Full Access in Codex

The exact controls vary slightly between the ChatGPT desktop app, Codex CLI, and IDE integrations, but the principle is the same.

Step 1: Open the Permissions Control

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.

Step 2: Use Workspace Access for Normal Coding

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

Step 3: Use Read-Only Mode for Initial Inspection

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.

Step 4: Confirm the Active Boundary

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.

Step 5: Keep Approvals Enabled for Boundary-Crossing Actions

Use on-request approvals for commands that need additional access.

For lower-friction workflows, consider auto-review rather than eliminating approvals completely.

Step 6: Restart Existing Full-Access Sessions

Changing a configuration file may not retroactively constrain an already running process.

After changing the settings:

1. Stop the current Codex session.
2. Confirm the configuration.
3. Restart Codex from the intended project directory.
4. Recheck the active permissions before continuing.

Safer config.toml Settings

Codex 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:

default_permissions = ":read-only"

Configuration warning: OpenAI says the newer permission-profile system does not compose with the older sandbox_mode settings. Configure one system or the other; do not place both approaches in the same active configuration and assume they will be combined.

Example: Limit Writes to the Workspace and Deny .env Files

For 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:

• Keeps normal project files writable.
• Preserves the built-in workspace safeguards.
• Denies access to matching .env files.
• Disables command network access.

For many local coding tasks, this is a better starting point than granting broad access to the entire machine.

Enterprise Controls for Blocking Full Access

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 Safer Daily Codex Workflow

A practical workflow can keep most of Codex’s speed without exposing the full host system.

1. Work in a Dedicated Repository

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.

2. Use Version Control Before Delegating

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.

3. Commit Frequently

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.

4. Review Commands and Diffs

Treat Codex output like a pull request:

• Inspect the commands it proposes.
• Review file diffs.
• Run tests.
• Confirm changed paths.
• Check for unexpected deletions.
• Document important decisions.

5. Use Worktrees or Containers for Risky Tasks

For large refactors, dependency experiments, build-system changes, or cleanup tasks, isolate the agent further.

Options include:

• A Git worktree.
• A disposable virtual machine.
• A Dev Container.
• A Docker container.
• A temporary development account with limited permissions.

OpenAI provides a secure Dev Container example for cases where the container is intended to be the outer isolation boundary.

6. Keep Backups Outside the Agent’s Reach

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.

What to Do After an Accidental Deletion

When files have just been deleted, further writes can overwrite recoverable disk blocks.

Take the following precautions:

1. Stop the Codex session immediately.
2. Stop build tools, package managers, sync clients, and other processes writing to the affected disk.
3. Do not reinstall software onto the affected drive.
4. Check Git history, worktrees, editor local history, snapshots, and cloud version history.
5. Restore from a known-good backup where available.
6. For irreplaceable data, consider professional recovery before attempting repeated DIY recovery operations.

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.

What OpenAI Is Changing

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:

• Do not run Full Access by default.
• Keep the project boundary intact.
• Retain approvals for escalated actions.
• Use version control and backups.
• Isolate high-risk automation.

Important Distinctions

A Model Error Is Not the Only Risk

A destructive action can result from several layers:

• The model chooses an unsafe command.
• A variable expands to an unexpected path.
• A shell interprets quoting incorrectly.
• A cleanup script targets the wrong directory.
• A tool runs from an unexpected working directory.
• The user approves a command without inspecting it.
• The sandbox is disabled.

For this reason, safety cannot depend on model accuracy alone.

Full Access Is Not Required for Most Coding Tasks

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.

Auto-Review Reduces Friction, Not Consequences

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.

常见问题

Can Codex delete files from my computer?

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.

Did OpenAI confirm the exact $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.

What is the safest Codex permission mode?

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.

Is --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.

Can Codex run automatically without approval prompts and still remain sandboxed?

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.

Does Git protect me from every type of Codex data loss?

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.

Does auto-review replace the sandbox?

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.

Should I use Full Access inside a container?

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.

相关工具

• Codex CLI: OpenAI’s local command-line coding agent for repository work and automation.
• Codex Permissions: Official documentation for read-only, workspace, and Full Access profiles.
• Codex Sandbox: Explains how filesystem and network boundaries are enforced.
• Codex GitHub Repository: The official open-source Codex CLI repository.
• Visual Studio Code Dev Containers: Runs development workflows inside isolated container environments.
• Git: Provides version history, branches, diffs, and rollback for tracked source files.

Related Links

• Agent Approvals and Security: Official guidance for sandbox modes, approval policies, auto-review, and dangerous settings.
• Codex Permissions: Official reference for least-privilege permission profiles.
• Codex Sandboxing: Explains project boundaries and sandbox behavior across Codex surfaces.
• Windows Sandbox for Codex: Includes OpenAI’s explicit warning that Full Access may cause destructive actions and data loss.
• Running Codex Safely at OpenAI: Describes the controls OpenAI uses internally for bounded execution and review.
• Codex CLI Documentation: Official installation and local-use instructions.
• OpenAI Codex GitHub Repository: Source code, issues, security policy, and release information.

Summary

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.