[Critical data loss] Codex deleted important project files without an explicit deletion request or confirmation

Summary

Codex performed a destructive file operation that deleted important files from an actively developed local project, even though the user did not intend to delete those project files and did not explicitly approve a destructive deletion.

This is a potentially serious data-loss / destructive-action safety issue. An AI coding agent should not remove important existing project files outside the user's requested scope without an explicit, clearly informed confirmation.

Date observed

• 2026-08-12

User impact

• Important files from an active project were deleted.
• The project was important enough that recovery became an urgent concern.
• Work had to stop immediately to investigate recovery options.
• This creates a risk of irreversible loss when files are not fully recoverable from Git, backups, editor history, or OS recovery mechanisms.

What happened

1. The user was working with Codex on an important, actively developed project.
2. During the task, Codex performed file-deletion operations.
3. Important project files were removed.
4. The user did not intend for those files to be deleted and had not knowingly approved deletion of the project files.
5. After discovering the deletion, work had to be stopped to avoid worsening potential data loss.

Expected behavior

Codex should treat destructive file operations as high-risk, especially when they involve:

• deleting directories;
• deleting multiple files;
• deleting existing user-authored source files;
• deleting files outside the narrowly requested task scope;
• commands such as rm -rf, Remove-Item -Recurse, git clean, or equivalent destructive operations;
• changes that can cause substantial or irreversible data loss.

For these cases Codex should either:

1. avoid the deletion when it is not necessary to complete the user's request, or
2. require an explicit confirmation that clearly states what will be deleted and the potential impact before executing it.

A broad filesystem permission setting should not be interpreted as user intent to delete valuable project data.

Actual behavior

Codex deleted important project files without adequate confirmation of the destructive consequence.

Suggested safety/product improvements

Please consider adding a destructive-action guardrail independent of general filesystem access, for example:

• detect recursive / bulk deletion and high-impact file removal;
• show the exact affected paths before execution;
• require explicit confirmation for deletion of existing project files outside a clearly requested deletion task;
• prefer recoverable deletion (Trash / Recycle Bin) where practical instead of permanent removal;
• warn when a command would remove untracked files or large portions of a repository;
• maintain an undo/recovery record for agent-driven destructive filesystem changes when technically possible.

Environment / diagnostics

Known at the time of filing:

• OS family: Windows
• Product: Codex
• Project type: local development project
• Incident date: 2026-08-12

The exact Codex version, model, original prompt, deletion command, affected paths, and Codex Session ID are not included in this initial report because they were not yet captured in the incident notes.

If maintainers indicate the preferred diagnostic fields, the reporter can add available redacted session information, screenshots, command history, affected paths, or recovery details without exposing private project content.

Privacy note

The project itself is private/important, so no proprietary source files or sensitive project contents are attached publicly. Diagnostic information can be redacted before sharing.

Why this matters

Destructive filesystem actions are qualitatively different from ordinary code edits. Even when an agent has permission to modify a workspace, deletion of valuable existing files should require strong intent alignment and should fail safe when that intent is ambiguous.