The read_file tool fails with a regex parsing error when attempting to read files, even when the file paths are valid and accessible via terminal commands.
Environment
OS: macOS (darwin 25.1.0)
Tool: read_file function
Actual Behavior
The tool fails with the following error:
Error: Invalid regular expression: /(?:^|\/)Apple ][\/$/i: Unterminated character class
Error Details
The error message suggests that the tool is attempting to parse a file path or filename as a regular expression, and encountering special characters (specifically “Apple ][” appears in the error) that break the regex parsing.
Project DOES have a python file with that text in it, which is run as a startup script whenever opening a terminal. entire repo has been indexed, including that file
Workaround
none, i can’t get work done, because read_file is borked cuz it chokes due to the text when using regex.
the ai CAN figure out how to read that ONE file, but that’s not helpful. my environment is just broken.
AI figured out this: Using run_terminal_cmd with cat successfully reads the files:
cat /path/to/.cursorrules
This workaround confirms:
The files exist and are readable
The paths are valid
The issue is specific to the read_file tool’s internal processing
Files Affected
everything
Additional Notes
The error occurs consistently across multiple file paths
occurs in all chat contexts, even brand new ones
occurs if i wipe the entire Cursor prefs folder and start from scratch with no chat history database and no repo index
The regex error suggests the tool may be incorrectly treating file paths as regex patterns
The specific mention of “Apple ][” in the error is suspicious -
The AI thinks that this may be related to a directory name or path component that contains special characters, but it’s not. that string is in a python file.
Impact
Severity: BLOCKER - Viable workaround does not exist: requires using terminal commands instead of the intended tool
Frequency: 100% - Occurs every time read_file is used, which is all the time
User Impact: work is blocked, even though replaced text with “Apple II”, the chat histories and indexes are still searched using regex, then they fail. even telling the chat to look for “]” and replace it, just introduces more “]” into the history to mess things up more
Steps to Reproduce
have a terminal .bash_profile script that runs a python script. in said python script is the string “Apple ][“, and it prints that to the terminal output
have that file be in your project, and indexed already
have a .cursorrules file with some rules in it
tell agent to read .cursorrules (or issue any other command that touches files inside your project)
behind the scenes it uses “read_file” func, eg: read_file("/path/to/.cursorrules")
Expected Behavior
The tool should successfully read the file contents and return them, or execute whatever command without choking on invalid regex
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
I see what the issue is. The square brackets ][ are being used as regex characters without escaping. That’s a bug, I’ll pass it to the team.
But there’s one more detail. You said this Python file prints “Apple ][” every time you open the terminal. That means even after clearing prefs, each new terminal adds that line back into the context again. So a wipe won’t help.
even after clearing EVERYTHING and sarting OVER with what appears to be from scratch, with all remnants of any “Apple ][“ wiped from my hard drive, i am still blocked at every turn by:
Read invalid regular expression: /(?:^IV) Apple ][V$/i: Unterminated character class
i’m blocked! like, i can’t use cursor at all now??
okay so my new wipe scripts work but it is very easy to get reinfected
there is a readme.
run the backup script first to capture your user state
then run the clean script. it will auto install your backup state, without any caches
Hey, replying to your latest questions. Yep, the bug is logged in our system. Like I mentioned, the issue is that square brackets ][ aren’t being escaped when used as a regex.
Why it keeps getting re-infected:
Like I wrote earlier, your Python file prints Apple ][ every time you open the terminal. That means even after a full cleanup, each new terminal session adds that string back into the context. Also, you mentioned you had a folder with that name in your path: /projects/Apple ][/graphics/....
I’ve passed this bug to the team, but I can’t share a timeline for when it’ll be fixed. Your report helps with prioritization.
i am blocked. completely blocked. 100% blocked. my “clean” scripts don’t help, the next session is immediately reinfected. i can’t use cursor, nothing i do is working. every single command gets hug up on Error: Invalid regular expression: /(?:^|\/)Apple ][\/$/i: Unterminated character class
even when i completely wipe cursor from my entire system and start completely fresh.
help! this is critical! my development is halted!
The .gitignore comment mentions "bracket-containing children excluded via
parent ignore", which suggests directories with brackets in their names.
The regex error /(?:^|\/)Apple ][\/$/i likely comes from the tool’s
internal ignore processing when it encounters a path like "Apple ]"
or "Apple II" and misinterprets the ][ as a regex character class.
The error appears to be in the read_file tool’s ignore-file processing,
not in the ignore files themselves. The tool may be generating a regex
from a path containing brackets and producing invalid syntax.
This is likely a bug in the tool’s path-matching logic when handling
bracket characters in file/directory names. The terminal cat command works
because it doesn’t process ignore patterns.
Cursor rules (.cursor/rules/*.mdc): the regex is built directly from the globs inside that file. Making those globs strict and bracket‑free removes the offending characters from the regex construction path, so the error goes away.
.cursorignore: the regex error appears even when the file is empty, which means the regex isn’t being built from the ignore patterns at all. It’s being built from something else in the indexing/paths layer (e.g., a path list or cache that includes a ]), so changing the ignore globs doesn’t affect it.
That explains why tightening the rules globs helped but tightening .cursorignore did not. In this case the failure is likely in a path enumeration or cache step that happens before or outside .cursorignore parsing.
