Skip to content

fix: detect sudo password prompt and exit cleanly instead of hanging#1729

Open
octo-patch wants to merge 1 commit intoopeninterpreter:mainfrom
octo-patch:fix/issue-1694-sudo-hang
Open

fix: detect sudo password prompt and exit cleanly instead of hanging#1729
octo-patch wants to merge 1 commit intoopeninterpreter:mainfrom
octo-patch:fix/issue-1694-sudo-hang

Conversation

@octo-patch
Copy link
Copy Markdown

Fixes #1694

Problem

When the LLM generates a sudo command (e.g., sudo journalctl -xe), the subprocess uses subprocess.PIPE which has no terminal for interactive password input. The [sudo] password for <user>: prompt appears on stderr but the process then blocks indefinitely waiting for input that can never arrive through the pipe. OI hangs for ~120 seconds with no output before timing out.

Solution

Added a check in handle_stream_output() in subprocess_language.py for the [sudo] password for pattern in the output stream. When detected, OI immediately:

  1. Emits a clear message informing the user that sudo requires elevated privileges and should be run manually
  2. Sets the done event so the run() loop exits without waiting for the execution timeout

The subprocess remains blocked but gets cleaned up on the next execution or when OI exits, consistent with how other error cases are handled.

Testing

  • Trigger a sudo command with OI in a non-passwordless sudo environment
  • Before: OI hangs for ~120 seconds then times out with a generic error
  • After: OI immediately returns with a clear message: [sudo] password prompt detected — OI cannot provide a password through a pipe. Please run this command manually in your terminal.

Existing True/False auto_run behavior and non-sudo commands are completely unaffected.

@endolith
Copy link
Copy Markdown
Contributor

It doesn't actually block, you can type the password and it runs. I usually just press enter so it says incorrect password and then type the correct password so I know it's going into the right place. Definitely should be handled better though

@octo-patch
Copy link
Copy Markdown
Author

Thanks for the context! You're right that you can type the password and it will work — the blocking behavior just means there's no visible prompt to indicate what's happening, which can confuse users who don't realize sudo is waiting. This PR aims to make that situation explicit (detect and exit cleanly with a clear message) so the user knows to either run their command without sudo or set up passwordless sudo. Happy to revisit the approach if you have a different preference for handling this UX issue.

@endolith
Copy link
Copy Markdown
Contributor

I wonder if there's a way to just show the password prompt?

@Notnaton
Copy link
Copy Markdown
Collaborator

We could replace sudo with pkexec.
On gui distro it will pop up a gui.

This may break if run through ssh?

@endolith
Copy link
Copy Markdown
Contributor

endolith commented Apr 20, 2026

Actually Cursor was able to fix this in my fork by changing one line: endolith@2e43fec

Not sure if that has other side effects or if it only works in my fork vs in the original, though.

see also #1694

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: sudo commands hang process indefinitely with no feedback

3 participants