Bug: sudo commands hang process indefinitely with no feedback

[thehighnotes]

Description

When the LLM generates a command that triggers a [sudo] password for <user> prompt, the subprocess hangs indefinitely waiting for password input that can never arrive. OI uses subprocess.Popen with stdin=subprocess.PIPE — there is no terminal for password entry. The process blocks until the execution timeout fires (default 120s), with no indication of what went wrong.

Steps to reproduce

1. Start OI with auto_run = True (or approve when prompted)
2. Ask it to do something that requires root, e.g. "check the systemd journal for errors"
3. The LLM generates sudo journalctl -xe
4. OI hangs for ~120 seconds with no output
5. Eventually times out with a generic error

Root cause

handle_stream_output() in subprocess_language.py reads lines via iter(stream.readline, "") and checks for KeyboardInterrupt, active line markers, and end-of-execution markers — but has no detection for sudo password prompts. The [sudo] password for message arrives on stderr, gets queued as regular output, and the process continues blocking on stdin.

Suggested fix

Detect the sudo prompt pattern in the output stream and immediately signal completion with a clear message:

  def handle_stream_output(self, stream, is_error_stream):
      try:
          for line in iter(stream.readline, ""):
              ...
              line = self.line_postprocessor(line)

              if line is None:
                  continue

+             if "[sudo] password for" in line:
+                 self.output_queue.put(
+                     {
+                         "type": "console",
+                         "format": "output",
+                         "content": "[sudo detected — command requires elevated "
+                                    "privileges. Run it manually.]\n",
+                     }
+                 )
+                 self.done.set()
+                 return

              if self.detect_active_line(line):
                  ...

Since the subprocess uses pipes (not a PTY), we cannot send Ctrl+C to cancel the sudo prompt. But self.done.set() causes run() to stop waiting and return. The blocked subprocess is cleaned up when terminate() is called on the next execution or OI exit.

Environment

• open-interpreter 0.4.3
• Python 3.10, Linux (ARM64)
• Ollama backend, bash shell execution

[endolith]

You can actually type in your password even though there isn't a visible prompt. I am scared to do so though, because I'm not 100% sure it won't get sent to the server somehow.

[thehighnotes]

That's a fair correction — you can type blind into the pipe, we shouldn't have said "can never arrive". But yeah the core problem is the same either way: there's zero indication that sudo is waiting, and a user (or the LLM on the next turn) has no idea what's happening.

We're not trying to make sudo work through OI — the opposite. The fix in the issue detects [sudo] password for in the output stream and immediately stops execution with a clear message telling the user to run it in their own terminal:

if "[sudo] password for" in line:
    self.output_queue.put({
        "type": "console",
        "format": "output",
        "content": "[sudo detected — command requires elevated "
                   "privileges. Run it manually.]\n",
    })
    self.done.set()
    return

This slots into the existing handle_stream_output(self, stream, is_error_stream) loop, right before detect_active_line. No attempt to pipe a password through — just catch it and bail with feedback instead of a silent 2-minute hang.

— Mark (with Claude's assistance)

[endolith]

Yeah that's probably better than what we have now. Allowing the user to safely enter their password would be even better, though.

(Another option is to have the AI write a script for you, then do %% sudo script.sh to run it and enter your password without leaving OI, and then have the AI check that it worked.)

[endolith]

I was also looking into other filters, like preventing smaller LLMs from making tool calls incorrectly, putting reasoning inside blockquotes, etc. Maybe a filter library could implement all of this, rejecting the LLM's response and telling it to try again using the correct format, like Instructor's reasking logic? https://python.useinstructor.com/concepts/reask_validation/#llm-based-validation-example

LLMGuard seems too heavy, depending on torch, etc.?