Codex Desktop deleted workspace roots + installed apps on failed archive (bypassed Recycle Bin)

What version of the Codex App are you using (From “About Codex” dialog)?

Not enough information to easily find this in the app; \OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0\ or 0.108.0.0 from the .exe version

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop (cli_version 0.108.0-alpha.12, package
OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0, source=vscode) on
Windows 11 Pro 10.0.26200 programmatically deleted the contents of
10+ directories from my system, bypassing the Windows Recycle Bin.
The damage occurred at approximately 2026-04-18 21:03:46 UTC during
a conversation-archive operation that failed while multiple agent
threads were active. Possibly session-ID d019d9dd2-8ac2-7d71-9b9c-992c5d1dbbbd

Confirmed missing directories (per Codex Desktop's own
electron-saved-workspace-roots in .codex-global-state.json):
C:\src\ai-chat
C:\src\Alpental
C:\src\Bruce-Demo
C:\src\EggTracker
C:\src\FluidNC
C:\src\fluidnc-posts
C:\src\LocalAutomation
C:\src\pluralsight
C:\src\rudone
C:\src\StockInvestmentTool

Also deleted: multiple installed applications / Steam games under
C:\Program Files (x86)\ (post-incident C: free space is 706 GB of
930 GB, hundreds of GB higher than before the incident).

Windows Event Log: Volsnap Event ID 36 at 21:03:46 UTC — "The shadow
copies of volume C: were aborted because the shadow copy storage
could not grow due to a user imposed limit." This suggests a VSS
snapshot was attempted immediately before a bulk mutation, aborted
because of a storage cap, and the bulk mutation proceeded anyway.
Because VSS aborted, no shadow copy exists to recover from.

I was running with sandbox = "elevated" in config.toml,
sandbox_mode: danger-full-access, Approval policy: never (per session
metadata). I granted full privilege — but there is no reasonable
code path in which archiving a conversation should trigger a bulk
deletion against my workspace roots, let alone one that bypasses
the Recycle Bin.

Sandbox setup was actually triggered AFTER the damage
(setup_marker.json timestamp 21:11:54 UTC — ~8 minutes late). When
the sandboxed agents later came online, they spent 20+ minutes
spawning pwsh.exe commands searching C:\src and C:\$Recycle.Bin
specifically for the names of the missing repos — i.e., the
post-incident agents were INVESTIGATING the loss, not causing it.
Sandbox setup itself failed with:
{"code":"helper_unknown_error","message":"read ACL run had errors"}

I used Claude Code to conduct a forensic investigation and assembled
the attached bundle (PII scrubbed, 489 replacements). This is 100%
unacceptable and should be treated as a live-site incident until
root-caused. I have zero ability to restore or recover the lost work.

What steps can reproduce the bug?

codex-bug-report-public.zip

I cannot produce a deterministic repro — I have not attempted to
re-trigger the conditions without risking further data loss. The
observed sequence that led to the incident was:

1. Codex Desktop running on Windows 11 Pro 10.0.26200, source=vscode,

cli_version 0.108.0-alpha.12, with:
~/.codex/config.toml: sandbox = "elevated" [windows]
session meta: sandbox_mode: danger-full-access
session meta: Approval policy: never

1. Multiple agent threads active simultaneously in one conversation.
2. I deleted a couple of temporary git branches inside

C:\src\chip-chad (branches within one repo — NOT workspace roots).

1. I attempted to archive the conversation while threads were running.
2. The archive operation failed. All running threads terminated and

posted "task was not able to resume" errors. Per state file, a
thread received 10+ queued "continue" messages each blocked with
reason: "no rollout found for thread id
019d9dd2-8ac2-7d71-9b9c-992c5d1dbbbd".

1. At ~21:03:46 UTC, directory contents began disappearing across

C:\src\* workspace roots and C:\Program Files (x86)\ app install
dirs. Deletions bypassed the Recycle Bin (programmatic, not
shift-delete).

1. Codex Desktop then prompted me to set up an agent sandbox. The

sandbox did not yet exist at the time of the deletions
(setup_marker.json: 21:11:54 UTC).

1. I closed and reopened Codex Desktop; on relaunch I was re-prompted

to log in and every previous thread was gone.

Relevant identifiers:
Affected (archived) thread: 019d9dd2-8ac2-7d71-9b9c-992c5d1dbbbd
Post-incident session: 019da274-75d6-77a1-9e38-3d415b19aca4
(rollout jsonl attached)
Environment id: [REDACTED_ENV_ID]
machine_id: wham-public/wham-universal
workspace_dir: /workspace
environment label: chip-chad
OS: Windows 11 Pro 10.0.26200
Codex package: OpenAI.Codex_26.305.950.0_x64
__2p2nqsd0c76g0

Token/context window usage for the affected (pre-damage) thread is
not available — its rollout was destroyed when the archive failed.
That the rollout does not survive a failed archive is itself a bug
data point.

What is the expected behavior?

1. Archiving a conversation must never mutate the user's filesystem

outside Codex's own config/cache directories (~/.codex/).

1. If a conversation archive operation fails, threads should remain

resumable — or at minimum their rollouts should persist on disk —
not silently be destroyed.

1. Any bulk file-deletion operation initiated by Codex, its sandbox

setup, or any agent under its control must:
(a) respect the OS Recycle Bin (on Windows: SHFileOperation with
FOF_ALLOWUNDO, not Remove-Item / DeleteFileW / rmdir API
calls);
(b) require explicit user confirmation regardless of
"Approval policy: never" — that setting should govern
command-execution approval within the agent's cwd, not grant
license to destroy files outside cwd/workspace.

1. Workspace roots registered in electron-saved-workspace-roots are

user data. They must never be deleted by Codex under any internal
cleanup, crash-recovery, archive, or sandbox-setup path.

1. A failed VSS snapshot (Volsnap Event ID 36) immediately preceding

a planned bulk mutation should abort the mutation — the snapshot
was presumably requested as a safety net; if the safety net is
gone, the operation it was protecting should not proceed.

1. The sandbox setup helper (which in my case failed with

helper_unknown_error / "read ACL run had errors") must not be
capable of deleting user data as a side effect under any failure
mode. It should only add ACLs for the sandbox users, never remove
files.

Additional information

• The sandbox setup created two new local Windows user accounts:
CodexSandboxOffline and CodexSandboxOnline (both still present on
my system). Please confirm whether these can be removed safely and
document a supported cleanup procedure for users who want to
uninstall the sandbox.

• Forensic bundle contents (PII scrubbed):

• README.txt — full UTC timeline with event-log references
• codex-state/ — .codex-global-state.json, config.toml, cap_sid
• sandbox-logs/ — sandbox.log, setup_marker.json, setup_error.json
• session-rollout/ — post-damage session jsonl (images stripped)
• windows-events/ — System + Application CSVs (~20:45–22:00 UTC)
• current-C-src-listing.txt, c-drive-state.txt, codex-local-users.txt

• Scrubbing: 489 replacements applied (Windows username, GitHub
username, Codex user id, repo/user ids, SIDs, env id, credential
patterns ghp_/sk-/AIza/JWTs, base64 image payloads). Residuals are
Steam game-icon SHA-1 hashes (public) and a WER bucket hash —
non-sensitive.

• Evidence limitations on my side:

• Recycle Bin was empty post-incident (deletions were programmatic)
• NTFS USN journal size = 32 MB, already rolled over — no

deletion USN records recoverable

• VSS aborted → no shadow copies to restore from
• Windows object-level auditing was not enabled, so the deleting

process identity is not in the Security log

• The smoking gun — which Codex Desktop code path issued the

destructive call — should be in Codex Desktop's own main/
renderer log files on OpenAI's side. My attached sandbox.log
only starts at 21:11:54 UTC, which is AFTER the damage.

• Happy to provide additional artifacts on request (Electron logs,
cache, registry, anything else). Please do not ask me to attempt a
reproduction on my primary machine.