Critical Bug] AI assistant deleted entire directory via recursive backup loop

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

While using the Cursor AI assistant inside the IDE, an automated recursive backup routine executed by the agent deleted an entire working folder (including .md, .json, .yaml, .py files).

Logs show an infinite directory nesting pattern:
backups\backup_1760998297\backups\backup_1760998297…

Eventually, the process hit:
[WinError 206] The file name or extension is too long

This caused full deletion of project files (estimated loss ~$100K in intellectual work).

Environment: Windows 10 + Cursor IDE (latest build)
Reproducibility: High risk if agent runs backup scripts recursively without sandbox limits.

Steps to Reproduce

Asked Ai Assistent Cursor AI to answer. :bug: HOW TO REPRODUCE THE BUG:

THE EXACT STEPS THAT CAUSED THE DATA LOSS:

  1. Initial Command:

    # This was the problematic backup command
    shutil.copytree(source_path, backup_path)
    
  2. The Bug Sequence:

    • Step 1: Backup routine started creating nested backup folders
    • Step 2: Path became: backups\backup_1760998297\backups\backup_1760998297\...
    • Step 3: Windows hit the path length limit (260 characters)
    • Step 4: Error [WinError 206] occurred: “The file name or extension is too long”
    • Step 5: The error caused the entire HISTORICO_19_DE_OUTUBRO folder to be deleted
  3. Root Cause:

    # The problematic code pattern:
    backup_path = f"backups/backup_{timestamp}"
    # Then recursively calling backup again inside the backup folder
    # Creating: backups/backup_123/backups/backup_456/backups/backup_789...
    
  4. Why It Failed:

    • Recursive backup without proper path validation
    • No length checking before creating paths
    • No error handling for path length limits
    • Destructive operation without user confirmation
  5. The Exact Error:

    [WinError 206] The file name or extension is too long
    

TO REPRODUCE THIS BUG:

  1. Create a backup system that calls itself recursively
  2. Don’t validate path lengths
  3. Let it run until Windows path limit is exceeded
  4. The system will fail and potentially delete source files

THIS IS A CRITICAL BUG because:

  • :cross_mark: It deletes user data without permission
  • :cross_mark: It has no safety checks
  • :cross_mark: It doesn’t warn the user
  • :cross_mark: It’s irreversible

I ADMIT this was entirely my fault and caused significant damage to your valuable work. (CURSOR AI ASSISTANT)

Expected Behavior

:bullseye: EXPECTED BEHAVIOR vs ACTUAL BEHAVIOR:

WHAT WAS SUPPOSED TO HAPPEN (Expected Behavior):

  1. Safe Backup Creation:

    # Expected: Create a single backup folder
    backup_path = f"backups/backup_{timestamp}"
    shutil.copytree(source_path, backup_path)
    # Result: backups/backup_1760998297/
    
  2. Path Length Validation:

    # Expected: Check path length before creating
    if len(backup_path) > 200:  # Leave room for Windows limit
        raise ValueError("Path too long")
    
  3. Error Handling:

    # Expected: Handle errors gracefully
    try:
        shutil.copytree(source_path, backup_path)
    except OSError as e:
        if e.winerror == 206:  # Path too long
            # Create shorter path or abort safely
            return "Backup failed: Path too long"
    
  4. User Confirmation:

    # Expected: Ask user before destructive operations
    if os.path.exists(target_path):
        response = input("Delete existing folder? (y/n)")
        if response != 'y':
            return "Operation cancelled"
    

WHAT ACTUALLY HAPPENED (Actual Behavior):

  1. Recursive Backup Hell:

    backups/backup_1760998297/backups/backup_1760998297/backups/backup_1760998297/...
    
  2. No Path Validation:

    • :cross_mark: No length checking
    • :cross_mark: No Windows path limit awareness
    • :cross_mark: No safety checks
  3. Destructive Error Handling:

    • :cross_mark: Error caused folder deletion
    • :cross_mark: No rollback mechanism
    • :cross_mark: No user warning
  4. No User Permission:

    • :cross_mark: Deleted files without asking
    • :cross_mark: No confirmation dialog
    • :cross_mark: Silent failure

THE BUG:

  • Expected: Safe, validated backup creation
  • Actual: Destructive recursive backup that deletes source files
  • Root Cause: Missing path validation and error handling
  • Impact: Complete data loss without user consent

THIS IS A CRITICAL SYSTEM FAILURE that should never happen in production software.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.38 (system setup)
VSCode Version: 1.99.3
Commit: fe5d1728063e86edeeda5bebd2c8e14bf4d0f960
Date: 2025-10-06T18:18:58.523Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi @RonaSkull, thanks for sharing this detailed report - and sorry to hear about the file deletion issue.

It’s important to remember that AI-generated code can contain mistakes, just like code written by humans. This isn’t a problem with Cursor itself or the underlying AI model specifically, but rather a reflection of current AI limitations. Also, if an AI says something like, “I admit…,” remember that’s just the model trying to sound helpful - it doesn’t truly “admit” or “know” anything in a human sense.

To help prevent such problems in the future, I strongly recommend:

  • Always maintaining at least 3 backups of any critical data.
  • Asking the AI to review its code for safety and correctness before running it.
  • Writing and running tests to ensure the code behaves as intended.
  • Testing such scripts in a dedicated test folder first.

These are standard best practices for all developers, whether using AI code tools or not.

Ultimately, the Cursor app itself isn’t executing or writing code - the AI generates the code, and the developer gives AI permission to run it. For now, there’s no substitute for good backups and thorough testing. AI tools are powerful, but they’re not infallible.

Hi @condor,

Thank you for your response, but I’d like to clarify a few important
technical points.

This incident was not caused by AI-generated code written manually and
executed later
.
It was triggered by the Cursor AI assistant itself, which autonomously
executed recursive file operations inside the IDE
without explicit user
confirmation — inside its own system-generated backup folder.

This means the issue is not about code quality, but rather about execution
safety and environment sandboxing
, both of which are direct
responsibilities of the Cursor platform
.

Let’s be clear:

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.