Hi,
I’m on the Pro plan and noticed the Agent generated this command while creating a project in an empty workspace (/home/xxx/Projekts/yyy):
ls -ლა /home/xxx/Projekts
This looks like the model was silently switched to a lower-quality LLM. The Agent was working fine before.
Could the empty workspace have caused the agent to leave the scope?
Steps to Reproduce
?
Expected Behavior
Creating valid shell commands. Not leaving the scope
Operating System
Linux
Version Information
Version: 3.12.30
VS Code Extension API: 1.128.0
Layout: IDE
Build Type: Stable
Release Track: Default
V8: 14.4.258.32-electron.0
OS: Linux x64
Hey, thanks for the report. I’ll go point by point, nothing scary is happening here.
ls -ლა instead of ls -la. This is a rare one-off generation glitch where the model inserted a lookalike token from another alphabet ლა instead of plain la. The empty workspace has nothing to do with it. It’s harmless. the shell just rejected the invalid flag and the agent reran the command. If this starts happening often, send the Request ID right chat menu top right > Copy Request ID and we’ll dig in.
The model was quietly switched to a weaker one. On Auto, each request is routed separately and can be handled by different models. This is by design, not a hidden downgrade. Different behavior between requests is normal on Auto. If you want consistency, pick a specific model manually instead of Auto. More on routing: Cursor Router | Cursor Docs
Listing a folder one level above the workspace. This is also expected. Reading and searching files isn’t strictly limited to the workspace folder. External-File Protection applies to writes outside the workspace, not reads. If you want to limit what the agent can read, use .cursorignore or a stricter run mode: Run Modes | Cursor Docs
So both symptoms aren’t a sign of anything broken. Let me know if the ls -ლა type issue repeats a lot, and with a Request ID we can look deeper.
Thanks, my concern is the same Unicode generation bug could hit destructive commands like rm – this is a systematic issue, not just a one-off; isnt it and how do I prevent that?
Otherwise, cursor is very helpful. Thanks for the great work!
Good request, and the concern makes sense. Here’s why an rm scenario is unlikely here:
A lookalike glitch like this is more likely to break a command than to neatly turn it into a working destructive one. That’s exactly what happened with ls -ლა. The swapped token produced an invalid flag, the shell rejected it, and nothing happened. If a similar character showed up in rm, you’d usually get the same result, a syntax error and no execution, not silent file deletion. This isn’t a systematic issue, it’s a rare one-off sampling glitch on the model side.
Real protection isn’t built around this glitch, it’s built around confirmations and guardrails:
By default, terminal commands require approval, so you see the command before it runs. Don’t switch shell commands to full auto-run or an allowlist mode, especially for destructive commands, so you can review each command before execution.
There’s File-Deletion Protection and External-File Protection, the latter protects writes outside the workspace.
Via Run Modes Run Modes | Cursor Docs you can set an allowlist or denylist for commands and keep mandatory approval for anything potentially dangerous.
The basic backstop is version control with regular commits, so you can roll back any unwanted change.
Models are constantly being trained to follow instructions more accurately, and the team is working on safety behavior. If something like ls -ლა starts happening often, send the Request ID right top corner of the chat > Copy Request ID and we’ll dig deeper. Glad Cursor is helping otherwise.