Possible unintended mass file deletion from OneDrive folder triggered by Positron

[IsseiMiwa]

Apple M3 Pro OS Tahoe 26.5.2
Positron Version: 2026.08.2 build 4
Code - OSS Version: 1.124.0
Commit: 747dd53
Date: 2026-08-20T19:13:05Z
Electron: 42.2.0
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Darwin arm64 25.5.0

On August 29, 2026, at approximately 17:18 JST, I noticed that Positron was displaying “Deleting…” in the status area while I was working with CSV files in a project stored in my OneDrive folder.

I had not intentionally requested deletion of the project folder, and I do not remember seeing or approving any deletion confirmation dialog.

Shortly afterward, I noticed that many files under the project directory were no longer visible locally in Finder or through ls in Terminal. However, the same files were still present in OneDrive Web.

OneDrive then displayed a mass-deletion warning stating that 352 files had recently been deleted or moved from the OneDrive folder on this device, and asked whether they should also be deleted from OneDrive. I selected “Restore files”, and the files were successfully restored.

The most important evidence I found is in Positron's Window log. At 17:18:17, the following error was recorded:

2026-08-29 17:18:17.031 [error] [Window]
Unknown (FileSystemError): Failed to move 'Result_new' to the trash
(“Result_new”をゴミ箱に入れることができませんでした。)

at _FileSystemProviderError.create
at createFileSystemProviderError
at DiskFileSystemProviderChannel.delete

A nearly identical error was recorded again immediately afterward:

2026-08-29 17:18:17.888 [error] [Window]
Failed to move 'Result_new' to the trash
...
at DiskFileSystemProviderChannel.delete

Result_new is a major output directory in my research project and contains many subdirectories and files.

There were also OneDrive/File Provider-related errors around the same session. For example:

Failed to reload dataset after file change
...
Could not read from file ".../Result_new/...csv":
Operation timed out

Earlier in the session, Positron also logged several messages such as:

Lookup notebook session for notebook URI ... : not found
Additional information
The project is located under:
~/Library/CloudStorage/OneDrive-個人用/...
I was mainly opening and inspecting CSV files using Positron/Data Explorer.
I was not using Posit Assistant/chat at the time.
I searched the Extension Host log for deletion-related entries but did not find a corresponding delete operation.
Explorer: Confirm Delete is enabled.
I do not remember receiving or accepting a deletion confirmation dialog.
The standard deleteFile keyboard shortcuts are present, but I did not intentionally invoke a file deletion command.
The files remained intact in OneDrive Web until OneDrive detected the local deletion event and presented its mass-deletion protection dialog.
Fortunately, I was able to restore the 352 affected files through OneDrive.

At this point, I am not claiming that this was necessarily a Positron bug, since I do not yet know what initiated the delete request. However, the Window log appears to show that Positron's file system layer received or executed a request to move the entire Result_new directory to the trash.

I would particularly like to understand:

What component or command initiated the DiskFileSystemProviderChannel.delete call for Result_new?
Is there any additional log that can show the caller or originating command for this deletion request?
Could interaction between Positron and macOS File Provider/OneDrive cause an unintended folder deletion or partial deletion state?
Why might the deletion have proceeded without an apparent confirmation dialog even though Explorer: Confirm Delete was enabled?
Are there any known issues involving Positron, Data Explorer, or OneDrive-backed workspaces that could produce this behavior?

I have preserved the entire Positron log directory for the affected session, including window1, main.log, sharedprocess.log, terminal.log, agenthost.log, and the other session logs. I also have screenshots showing:

OneDrive's warning about the 352 deleted/moved files
Explorer: Confirm Delete being enabled
the current deleteFile keyboard shortcuts
the relevant Positron UI/log messages

I can provide the full log bundle and screenshots for investigation.

My main concern is identifying the root cause and preventing a recurrence, since this workspace contains research data and analysis outputs.

Thank you for your help in investigating this.

[juliasilge]

Thanks for the thorough report, and especially for preserving the full log bundle! I'm very glad OneDrive's mass-deletion protection let you recover everything. 😱

We take this kind of report seriously. Here's what it looks like we can determine so far, and what would help us narrow it down.

What the log tells us

The DiskFileSystemProviderChannel.delete error confirms that Positron's file service received a request to move Result_new to the trash (recursively, since it's a folder). Unfortunately, the stack trace only shows the main-process IPC channel and does not record which component, command, or extension initiated the request. This also explains why your Extension Host log search came up empty. If an extension issued the delete via the workspace.fs.delete() API, it would produce exactly this Window log signature while leaving no delete-specific entry in the Extension Host log.

Why you may not have seen a confirmation dialog

The Explorer's delete command honors Explorer: Confirm Delete, so with that setting enabled (as your screenshot shows), a delete initiated from the Explorer should have shown a dialog. However, a few paths bypass that confirmation entirely:

• An extension calling workspace.fs.delete() programmatically (no confirmation is ever shown)
• Undo Cmd+Z of a file/folder creation performed earlier in the session through the Explorer (undoing a folder creation moves it to the trash without a dialog)
• The delete keybinding Cmd+Backspace firing while the Explorer had keyboard focus rather than the editor

The OneDrive / File Provider factor

Several of your observations are consistent with known macOS File Provider behavior rather than Positron per se: "Operation timed out" when reading CSVs matches dataless (Files On-Demand) file materialization failing, and files disappearing locally while remaining in OneDrive Web matches eviction/provider-side deletion. Notably, on File Provider volumes the trash operation itself is handled by the provider, so OneDrive can process the deletion asynchronously even while reporting a failure back to the caller. That would explain why the trash operation logged as failed in Positron yet 352 files were still deleted. The two failed trash attempts ~0.9s apart also suggest two separate delete invocations (e.g., a repeated keypress) rather than a single retry.

What would help us investigate

1. The full log bundle for that session particularly the complete window1/ directory (including exthost.log, which lists which extensions were activated in that session), plus main.log and sharedprocess.log. If you'd rather not attach it publicly, you can email it to positron-support@posit.co.
2. Your installed extensions which you can get from the output of running Positron with --list-extensions, or a screenshot of the Extensions view. Combined with the exthost log, this tells us what could have issued a programmatic delete.
3. Was Result_new (or anything inside it) created during that Positron session? For example via New Folder, Duplicate, or paste in the Explorer. If so, an accidental Cmd+Z could have trashed it without any dialog.
4. Do you recall any cut/paste or drag-and-drop in the Explorer, or pressing Cmd+Backspace while the Explorer rather than an editor may have had focus?
5. Did anything from Result_new appear in the macOS Trash? That would tell us whether the trash partially succeeded before OneDrive processed the rest.
6. Your OneDrive version and Files On-Demand setting (presumably enabled, given the ~/Library/CloudStorage path).

To be transparent about where things stand, we don't yet have evidence pointing to a specific Positron feature (Data Explorer, for example, never deletes files) but the log does show the delete request passed through Positron's file service, so identifying the initiator is the key open question. The items above would let us either pin this on a specific caller or rule whole categories out.

Thanks again for the detailed write-up!