“Do not use this password anymore in chat or with me.
I will not store it, run sudo with it, or enter it into any files.
Never share root/sudo passwords in chat, email, or with tools — that counts as a leak.”
What is this!? Absurd! Can you please fix this!
Steps to Reproduce
Use sudo pass
Expected Behavior
Do not use this password anymore in chat or with me.
I will not store it, run sudo with it, or enter it into any files.
Never share root/sudo passwords in chat, email, or with tools — that counts as a leak.
Operating System
Linux
Version Information
Cursor (CLI som finns i PATH): 2.4.37
Commit: 7b9c34466f5c119e93c3e654bb80fe9306b6cc70
Arkitektur: x64
Hey, this is a known issue with sudo on Linux. The model treats the password as a credential leak and refuses to handle it. That’s model behavior, not really a Cursor bug, but the sudo workflow on Linux is broken right now.
For now, the workaround is: when the agent runs a command that needs sudo, you should see a small arrow at the top of the command block. Click it to open a full interactive terminal, then enter your password there directly, bypassing the model.
If the arrow doesn’t show up, try enabling Legacy Terminal Tool in Cursor Settings.
The team knows about the issue. I can’t promise a timeline, but your report helps with prioritization. Let me know if the workaround helped.
Thanks for your input. I have tried every setting I can find, but nothing works. The agent runs the command and doesn’t even prompt for a password before moving on. I can see the terminal, but there is no password prompt, and legacy mode is enabled.
This is extremely frustrating. There’s no point in using Cursor AI if I have to do everything manually.
No — I should not generate echo "…" | sudo -S … with the password filled in.
Why: even as a “template,” this leads straight into a pattern where the password ends up in shell history, process lists (ps), and often logs. It’s one of the most common ways passwords get accidentally leaked.
What you can do instead:
Use sudo -A with SUDO_ASKPASS — this opens a graphical prompt; no password in the command line.
Use a limited NOPASSWD rule in sudoers for exactly the binaries you need (for example, a specific apt command) — then no password is needed in the workflow at all.
Run sudo … in an interactive terminal and enter the password at the prompt (nothing in the command itself).
If you tell me which distro you’re using and what command the agent should run with sudo (a concrete example), I can help you step by step with askpass or a minimal, secure NOPASSWD rule — without putting any password in echo or in the chat.
I can see you tried the arrow key and Legacy Terminal, but it didn’t help. Sadly, that workaround doesn’t work for everyone since the agent sometimes skips past the command too fast.
The only reliable workaround right now is to set up NOPASSWD in sudoers for the specific commands you need. For example, if the agent often runs apt:
This removes the password prompt for those specific commands, so the model won’t get stuck on the sudo prompt. Keep the list as narrow as possible, only the binaries the agent actually needs. It’s not ideal, but it’s the only thing that works consistently right now.
We’re aware of the sudo issue on Linux. I can’t promise a timeline, but your report helps us prioritize it.