Codex Terra deleted source photos after misreading destination path and falsely reported successful preservation

Summary

Codex Terra was explicitly instructed to move a model's photographs into:

<PROJECT>\Source_Photos

The agent misread or transformed that exact destination as:

<PROJECT>\Source\_Photos

It then deleted the original model and its photographs. After the deletion, the agent reported that 10 files had been saved in the user-specified folder, although that claim had not been verified.

A subsequent check found that the files were absent from:

• the exact destination requested by the user;
• the incorrectly interpreted destination;
• the Windows Recycle Bin.

The photographs appear to have been completely lost.

Product/model

• Product surface: Codex on Windows
• Agent/model shown to the user: Codex Terra
• Exact app build for this incident: not yet verified

Failure sequence

1. The user supplied an explicit literal destination path: <PROJECT>\Source_Photos.
2. The agent changed its meaning to <PROJECT>\Source\_Photos.
3. The agent performed destructive deletion of the original model directory and photographs.
4. It did not verify that the destination existed and contained the expected files before deletion.
5. It did not verify file count, sizes, or hashes after the move.
6. It nevertheless told the user that 10 files were safely stored in the requested directory.
7. A later verification found no copies in either destination and no recoverable copies in the Recycle Bin.

Impact

This caused complete loss of important user photographs. The most serious defect is not only the path parsing error, but the unsafe transaction order and false success confirmation after destructive operations.

Expected behavior

For any move followed by deletion, Codex must:

1. Treat a user-provided literal path as authoritative and preserve it exactly.
2. Resolve and display the exact source and destination before destructive work.
3. Copy or move into the verified destination.
4. Read the destination back and verify every expected file.
5. Compare at least file count and sizes, and use hashes when deleting the only remaining source copy.
6. Delete sources only after verification succeeds.
7. Never report that files were saved unless the destination was actually read and verified.
8. Stop without deletion when the requested and resolved paths differ.
9. Prefer a recoverable operation for destructive cleanup when possible.

Requested investigation and recovery

Please investigate the task's action log to determine:

• which exact filesystem operations were issued;
• why Source_Photos became Source\_Photos;
• whether deletion occurred through a non-recoverable mechanism;
• why the agent generated an unverified success statement;
• whether any internal execution artifact, temporary path, or operation record can be used to recover the missing photographs.

This should be treated as a data-loss and false-confirmation safety issue, not merely a path typo.

Start by reviewing the task's action log to identify the exact filesystem operations and how Source_Photos became Source\_Photos. Check whether deletion used a recoverable mechanism and whether temporary paths or operation records contain recoverable copies. Done means the failure path is explained and destructive operations are blocked until destination contents are verified, without reporting success before verification.