Cursor Rules Deleted on Launch

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Every time I open Cursor, all files inside my workspace’s .cursor/rules folder are deleted. The folder itself remains, but all .mdc rule files inside are gone. This has been happening for several weeks across multiple Cursor updates, and affects every project I work in — it is not isolated to a single workspace.

No other .cursor subfolders are affected — .cursor/skills, .cursor/commands, and .cursor/settings.json all persist correctly.

Steps to Reproduce

Add any .mdc file to .cursor/rules/ in any workspace
Close Cursor completely
Reopen Cursor with that workspace
Check .cursor/rules/ — all files are deleted

Operating System

Windows 10/11

Version Information

Version: 3.3.30 (user setup)
VSCode Version: 1.105.1
Commit: 3dc559280adc5f931ade8e25c7b85393842acf30
Date: 2026-05-09T18:28:42.332Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Additional Information

Reproducible across multiple different projects/workspaces
The rules folder’s LastWriteTime always updates to the exact time Cursor was opened, even when no rules were manually edited — Cursor is touching the folder on startup
The deleted files are recoverable via cloud backup version history, confirming these are real filesystem deletions, not read/sync failures
The rules folder has different filesystem attributes than the other .cursor subfolders, suggesting Cursor may be deleting and recreating it on startup rather than leaving it in place

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi @ethoburn-bhep,
I don’t see any expected behavior where Cursor should delete files from .cursor/rules on startup. Project Rules are intended to live in that folder and persist with the project.

Could you check a few things the next time this reproduces?

  1. After reopening Cursor, do any .md files appear in .cursor/rules, or does a rules-index.mdc file appear?

  2. Is the workspace inside OneDrive, Dropbox, Google Drive, iCloud, or another synced/backup folder?

  3. Is Windows Defender Controlled Folder Access, antivirus cleanup, or any endpoint protection tool active for that workspace path?

  4. Could you run this in PowerShell before and after opening Cursor and share the output?

Get-ChildItem -Force .cursor\rules | Select-Object Name,Length,CreationTime,LastWriteTime,Attributes

If possible, also check Help > Toggle Developer Tools after launch and share any filesystem or rules-related errors from the Console. That should help narrow whether Cursor is deleting/recreating the directory, converting rule files, or whether another Windows process is removing the files during startup.

7
  1. .cursor/rules and its files are gone. There’s no rules-index.mdc
  2. Yes it’s in onedrive, but it doesn’t appear to be a onedrive sync issue, as it’s deleted from onedrive as well. Also, my skills and commands folders in .cursor are unaffected
  3. Sophos is installed and running, but no has no recent activity logs. Windows Defender is not the cause: AntivirusEnabled=False, RealTimeProtectionEnabled=False.
  4. See below

Couldn’t spot any rules related errors from the console.

PS C:\XXX\> Get-ChildItem -Force .cursor\rules | Select-Object Name,Length,CreationTime,LastWriteTime,Attributes


Name          : canvas.mdc
Length        : 224
CreationTime  : 2026-05-11 4:45:52 PM
LastWriteTime : 2026-05-11 4:45:52 PM
Attributes    : Archive, ReparsePoint

Name          : dbt-conventions.mdc
Length        : 1073
CreationTime  : 2026-05-11 4:45:52 PM
LastWriteTime : 2026-05-11 4:45:52 PM
Attributes    : Archive, ReparsePoint

Name          : sql-style.mdc
Length        : 1190
CreationTime  : 2026-05-11 4:45:52 PM
LastWriteTime : 2026-05-11 4:45:52 PM
Attributes    : Archive, ReparsePoint

Name          : using-bigquery.mdc
Length        : 1467
CreationTime  : 2026-05-11 4:45:52 PM
LastWriteTime : 2026-05-11 4:45:52 PM
Attributes    : Archive, ReparsePoint


                                                                      Get-ChildItem -Force .cursor\rules | Select-Object Name,Length,CreationTime,LastWriteTime,Attributesurn\XXX>
Get-ChildItem : Cannot find path 'C:\XXX\.cursor\rules' because it does not exist.
At line:1 char:1
+ Get-ChildItem -Force .cursor\rules | Select-Object Name,Length,Creati ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Users\ethobu...g\.cursor\rules:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
8

The ReparsePoint attribute on those files confirms they’re OneDrive “Files On Demand” placeholders. That’s almost certainly the cause. When Cursor opens the workspace and accesses .cursor/rules/, the interaction with those reparse points can trigger OneDrive to remove the local copies — and since OneDrive treats that as an intentional change, it syncs the deletion to the cloud too.

The reason .cursor/skills and .cursor/commands are unaffected is likely that Cursor interacts with the rules directory differently on startup (enumerating and watching it), which triggers OneDrive’s sync logic in a way the other folders don’t.

To fix this:

  1. Right-click the .cursor/rules folder in File Explorer

  2. Select Always keep on this device — this tells OneDrive to keep real local copies instead of cloud-only placeholders

  3. Restore your .mdc files (from OneDrive version history or backup)

  4. Reopen Cursor and check if the files persist

If that doesn’t help, try excluding the .cursor folder from OneDrive sync entirely (OneDrive Settings > Account > Choose folders, or move the workspace outside the OneDrive-synced directory).

Could you try that and let me know if the files survive a restart?

9

Did not fix the issue.

10

Thanks for trying that. Since pinning didn’t help, the cleanest way to isolate this is to test with one workspace completely outside OneDrive.

Could you try copying one of your affected workspaces to a path that is not synced by OneDrive (for example, C:\Projects\test-workspace), add a .mdc file to .cursor/rules/, close Cursor, reopen it, and check if the files survive?

If the issue stops outside OneDrive, we’ll know the sync interaction is the root cause (even if pinning alone wasn’t enough to prevent it). If it still happens outside OneDrive, that points to Sophos or another process on the machine.

One other thing to check: open the Sophos quarantine manager and search for any .mdc entries. Sophos can sometimes quarantine files with uncommon extensions without logging it in the main activity view.