File System Interaction

Relevant source files

The following files were used as context for generating this wiki page:

• totally_reset_cursor.py
• reset_machine_manual.py
• config.py
• bypass_token_limit.py
• main.py
• scripts/install.ps1
• scripts/install.sh

File system interaction is a core component of the cursor-free-vip project, enabling it to locate, configure, and modify the Cursor application files. The primary purpose of these interactions is to reset trial-related data, apply patches to bypass limitations, and manage the tool's own configuration. The scripts are designed to be cross-platform, with specific logic for Windows, macOS, and Linux to handle their distinct file system structures.

The system interacts with files in three main areas: the tool's own configuration directory (.cursor-free-vip), the Cursor application's installation directory, and user-specific application data folders. This involves reading and writing JSON, INI, and SQLite files, modifying JavaScript source code, and in some cases, interacting with system-level identifiers like the Windows Registry.

Configuration Management

The tool manages its settings through a config.ini file located in a dedicated directory. This configuration is central to locating necessary Cursor files and controlling script behavior.

Sources: config.py, totally_reset_cursor.py

Configuration Directory and File

The primary configuration directory is .cursor-free-vip, created within the user's "Documents" folder. The get_user_documents_path function determines the location of this folder across different operating systems. If the Documents folder cannot be found or created, the scripts fall back to using a temporary directory.

The main configuration file is config.ini inside this directory. The setup_config function in config.py is responsible for creating this file with default values if it doesn't exist, or reading and updating it if it does.

Sources: config.py:22-50, totally_reset_cursor.py:33-49

The following diagram illustrates the configuration setup process.

Sources: config.py:22-111

Key Configuration Paths

The config.ini file stores platform-specific paths to crucial Cursor application files. These paths are used by various scripts to locate and modify the application.

Section	Key	Description	Example Value (Windows)
WindowsPaths	storage_path	Path to the user's global storage JSON file.	C:\Users\user\AppData\Roaming\Cursor\User\globalStorage\storage.json
WindowsPaths	sqlite_path	Path to the user's state database.	C:\Users\user\AppData\Roaming\Cursor\User\globalStorage\state.vscdb
WindowsPaths	machine_id_path	Path to the file containing the machine ID.	C:\Users\user\AppData\Roaming\Cursor\machineId
WindowsPaths	cursor_path	Path to the Cursor application's resource directory.	C:\Users\user\AppData\Local\Programs\Cursor\resources\app
MacPaths	storage_path	Path to the user's global storage JSON file.	~/Library/Application Support/Cursor/User/globalStorage/storage.json
LinuxPaths	cursor_path	Path to the Cursor application's resource directory.	/opt/Cursor/resources/app

Sources: config.py:114-150, totally_reset_cursor.py:183-255

Cursor Application File Discovery

The scripts employ a multi-step process to locate the Cursor application and its critical files, adapting to different operating systems and installation methods (e.g., standard install vs. AppImage on Linux).

Sources: totally_reset_cursor.py, reset_machine_manual.py, bypass_token_limit.py

Path Discovery Logic

The get_cursor_paths and get_workbench_cursor_path functions are central to this process. They first read the cursor_path from config.ini. If the configured path doesn't exist, especially on Linux, they iterate through a list of default and potential paths, including those for extracted AppImages (squashfs-root).

The discovery flow is as follows:

1. Determine the operating system (Windows, Darwin, Linux).
2. Read the cursor_path from the corresponding section in config.ini.
3. On Linux, if the configured path is not found, scan a list of default installation directories and common AppImage extraction paths.
4. Once a valid base path is found, construct the full paths to package.json, out/main.js, and out/vs/workbench/workbench.desktop.main.js.
5. Verify that these critical files exist before returning the paths.

Sources: totally_reset_cursor.py:52-181, reset_machine_manual.py:236-302

This flowchart visualizes the path discovery mechanism.

Sources: totally_reset_cursor.py:52-181

File Modification and Patching

A primary function of this repository is to modify Cursor's JavaScript files to alter its behavior, such as bypassing token limits or changing UI elements. This is done by reading the file content, applying string or regex replacements, and overwriting the original file after creating a backup.

Sources: totally_reset_cursor.py, reset_machine_manual.py, bypass_token_limit.py

Patching Process

The modify_workbench_js and modify_main_js functions implement the patching logic. The process is carefully designed to be safe and reversible.

1. Permissions & Backup: The script first saves the original file's permissions and ownership. A backup copy of the original file is created (e.g., workbench.desktop.main.js.backup.YYYYMMDD_HHMMSS).
2. Read and Replace: The content of the target JavaScript file is read into memory. A series of predefined string or regex patterns are applied to replace specific code sections.
3. Atomic Write: The modified content is written to a temporary file.
4. Overwrite: The temporary file is moved to replace the original file. This ensures that an incomplete write does not corrupt the original.
5. Restore Permissions: The original file permissions and ownership are restored on the newly patched file.

Sources: totally_reset_cursor.py:418-527, reset_machine_manual.py:382-491, bypass_token_limit.py:126-200

The sequence diagram below shows the file modification flow.

Sources: totally_reset_cursor.py:418-479

Target Files and Modifications

File	Function	Purpose of Modification
out/main.js	modify_main_js	Patches the getMachineId() function to alter how the machine ID is retrieved, aiding in trial resets.
out/vs/workbench/workbench.desktop.main.js	modify_workbench_js	Modifies UI elements (e.g., changing "Upgrade to Pro" button) and bypasses token limits by altering getEffectiveTokenLimit.

Sources: totally_reset_cursor.py:481-527, bypass_token_limit.py:126-200

User Data and State Management

The MachineIDResetter class in totally_reset_cursor.py is dedicated to resetting user-specific data stored by Cursor, which is a key part of bypassing trial limitations.

Sources: totally_reset_cursor.py:584-911

Data Reset Flow

The reset process involves generating new unique identifiers and updating them in multiple locations.

1. Locate Data Files: The class constructor identifies paths to storage.json and state.vscdb based on the operating system and config.ini.
2. Generate New IDs: The generate_new_ids method creates a new devDeviceId, machineId, macMachineId, and sqmId using uuid and hashlib.
3. Update storage.json: The script reads the storage.json file, updates it with the newly generated IDs, and writes it back. A backup (.bak) is created first.
4. Update state.vscdb: The update_sqlite_db method connects to the SQLite database and uses INSERT OR REPLACE to update the key-value pairs corresponding to the machine IDs.
5. Update machineId file: A separate machineId file is updated with the new devDeviceId.

Sources: totally_reset_cursor.py:657-731

The following diagram shows the machine ID reset process.

Sources: totally_reset_cursor.py:814-874

Installation Scripts

The project includes installation scripts for both Windows (install.ps1) and Linux/macOS (install.sh) that handle downloading the correct binary from GitHub releases and executing it.

Windows Installer (install.ps1)

The PowerShell script performs the following actions:

1. Fetches the latest release information from the GitHub API.
2. Identifies the correct .exe asset for Windows.
3. Checks if the file already exists in the user's Downloads folder.
4. If it exists, it attempts to run it with administrator privileges.
5. If it doesn't exist, it downloads the executable with a progress bar and then runs it.

Sources: scripts/install.ps1

Linux/macOS Installer (install.sh)

The shell script performs similar steps:

1. Fetches the latest release version from the GitHub API.
2. Detects the OS (macOS/Linux) and architecture (ARM64/x64).
3. Constructs the download URL for the corresponding binary.
4. Checks if the binary already exists in the user's Downloads directory and executes it if present.
5. If not present, it downloads the binary using curl, makes it executable with chmod +x, and then runs it.

Sources: scripts/install.sh