# Security Considerations for Using the auto_run Feature in Open Interpreter

> Understand the security risks of Open Interpreter's auto_run feature. Learn how to prevent arbitrary code execution with Safe Mode and sandboxing.

- Repository: [Open Interpreter/open-interpreter](https://github.com/openinterpreter/open-interpreter)
- Tags: security
- Published: 2026-03-05

---

**Enabling `auto_run` in Open Interpreter removes the human confirmation step before executing LLM-generated code, creating significant security risks including arbitrary code execution unless mitigated by Safe Mode or sandboxed environments.**

The `auto_run` flag in Open Interpreter allows the system to execute generated code without prompting the user for approval. While this enables fully automated workflows, it eliminates a critical safety checkpoint that prevents malicious or erroneous code from running on your system. Understanding the architecture and security implications of this feature is essential for safe deployment.

## How auto_run Works in the Open Interpreter Architecture

### Core Implementation and Default Settings

The `auto_run` attribute is defined in the core interpreter class with a default value of `False`. In [`interpreter/core/core.py`](https://github.com/openinterpreter/open-interpreter/blob/main/interpreter/core/core.py) (lines 42-48), the constructor initializes `self.auto_run = auto_run`, ensuring that explicit user action is required to enable automatic execution. This default protects users from accidentally running code without review.

### CLI Integration and Safe Mode Safeguards

The command-line interface processes the `--auto_run` (or `-y`) flag in [`interpreter/terminal_interface/start_terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/interpreter/terminal_interface/start_terminal_interface.py) (lines 420-425). However, the CLI includes a critical safeguard: if **Safe Mode** is set to `"ask"` or `"auto"`, the startup logic forcibly disables `auto_run` to prevent accidental execution. This ensures that safety settings always override convenience flags.

### Runtime Control via Magic Commands

Users can toggle `auto_run` dynamically during an interactive session using the magic command system. In [`interpreter/terminal_interface/magic_commands.py`](https://github.com/openinterpreter/open-interpreter/blob/main/interpreter/terminal_interface/magic_commands.py) (lines 26-34), the `%auto_run` command accepts `true` or `false` arguments, allowing users to enable automatic execution for trusted workflows and disable it when handling sensitive operations.

### Execution Flow When auto_run Is Enabled

When the LLM generates code, the system creates a `confirmation` chunk that normally pauses for user approval. In [`interpreter/terminal_interface/terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/interpreter/terminal_interface/terminal_interface.py) (lines 87-100), the UI checks `interpreter.auto_run`:

- If `False`: The UI displays the code and prompts for confirmation
- If `True`: The UI skips the prompt and proceeds directly to execution

If Safe Mode is not `"off"`, the system may still invoke `scan_code()` (lines 101-118) to analyze the code with **semgrep** before execution, providing a secondary defense even when `auto_run` is enabled.

## Security Risks When auto_run Is Enabled

### Arbitrary Code Execution

The most severe risk of enabling `auto_run` is **arbitrary code execution**. Without the confirmation checkpoint, a compromised or misaligned LLM could generate commands to delete files, exfiltrate data, or install malware. In [`interpreter/terminal_interface/terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/interpreter/terminal_interface/terminal_interface.py), the bypass of the confirmation dialog (lines 87-100) means no human reviews the code before the Computer subsystem executes it via Python shells or system commands.

### OS Control Mode Risks

When **OS mode** is enabled (`interpreter.os = True`), the interpreter gains the ability to control the mouse, keyboard, and screen. Combining OS mode with `auto_run` creates a high-risk configuration where the LLM could autonomously interact with the operating system without any human oversight. The CLI safeguard in [`start_terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/start_terminal_interface.py) attempts to prevent this by disabling `auto_run` when Safe Mode is active, but users can override this at runtime with `%auto_run true`.

### Code Scanning Bypass

If `auto_run` is enabled **and** Safe Mode is set to `"off"`, the `semgrep` scanner is bypassed entirely. In [`terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/terminal_interface.py), the scanning logic (lines 101-118) only executes when Safe Mode is active. This eliminates a critical defense layer that checks for known dangerous patterns (such as `eval()` calls or shell injections) before execution.

### Persisted State and Dependency Exploitation

The interpreter maintains conversation history across sessions. Malicious code could be hidden in previous messages and re-executed in subsequent interactions. Additionally, executed code can import any installed Python package. With `auto_run` enabled, the model could automatically install and exploit vulnerable dependencies without review.

## Defensive Defaults and Mitigation Strategies

The Open Interpreter project implements several **defensive defaults** to protect users:

- **CLI safeguard**: The startup logic in [`start_terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/start_terminal_interface.py) forcibly sets `auto_run = False` when Safe Mode is `"ask"` or `"auto"`, ensuring safety settings take precedence.
- **Prompt-time guard**: The terminal interface always checks `interpreter.auto_run` before skipping confirmation, defaulting to manual approval when the flag is unset or `False`.
- **Safe Mode scanning**: When Safe Mode is enabled, the system automatically invokes `scan_code()` using semgrep rules to detect dangerous patterns before execution, even if `auto_run` bypasses the human confirmation step.

To mitigate risks when using `auto_run`:

1. **Enable Safe Mode**: Set `--safe_mode ask` to retain code scanning even when skipping manual confirmation.
2. **Use sandboxed environments**: Run Open Interpreter inside Docker containers, virtual machines, or restricted user accounts to limit system damage.
3. **Audit dependencies**: Maintain a minimal Python environment with locked [`requirements.txt`](https://github.com/openinterpreter/open-interpreter/blob/main/requirements.txt) to prevent automatic installation of malicious packages.
4. **Clear history regularly**: Use `interpreter.reset()` or restart sessions to prevent exploitation of persisted conversation state.

## Practical Code Examples

```python

# Example 1 – Enable auto_run from the CLI (trusted automation)

# -----------------------------------------------------------

# Run the interpreter with automatic execution:

#   $ interpreter -y --model gpt-4o-mini

# This sets interpreter.auto_run = True at startup.

# Example 2 – Toggle auto_run at runtime via magic command

# -------------------------------------------------------

# Inside an interactive session:

%auto_run true      # Turn on auto‑run

%auto_run false     # Turn it off again

# Example 3 – Combine safe_mode with auto_run for scanning

# -------------------------------------------------------

# Start with safe_mode = "ask" (default) and later enable auto_run:

$ interpreter -y --safe_mode ask

# The CLI will *still* disable auto_run because safe_mode is ask.

# You can re‑enable it after the interpreter has started:

%auto_run true      # Now auto‑run is on, but each chunk will be scanned first.

```

## Summary

- **`auto_run` disables the confirmation prompt** that normally requires human approval before executing LLM-generated code, as implemented in [`interpreter/terminal_interface/terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/interpreter/terminal_interface/terminal_interface.py).
- **Security risks include arbitrary code execution, OS control exploitation, and bypass of semgrep scanning** when Safe Mode is disabled.
- **Defensive defaults protect users**: The CLI forcibly disables `auto_run` when Safe Mode is `"ask"` or `"auto"`, and the terminal interface always checks the flag before skipping confirmation.
- **Mitigation requires layered defenses**: Enable Safe Mode to retain code scanning, run in sandboxed environments, audit dependencies, and clear conversation history regularly.

## Frequently Asked Questions

### What happens if I enable auto_run without Safe Mode?

If you enable `auto_run` while Safe Mode is set to `"off"`, the interpreter will execute generated code immediately without human confirmation and without running the semgrep security scanner. This creates the highest risk configuration, as malicious code could delete files, exfiltrate data, or compromise the system without any warning or defensive scanning.

### Can I use auto_run safely for automation workflows?

Yes, but only with additional safeguards. You should enable Safe Mode (`--safe_mode ask` or `--safe_mode auto`) to retain the semgrep code scanning that checks for dangerous patterns before execution. Additionally, run the interpreter inside a sandboxed environment such as a Docker container or virtual machine with limited permissions, and maintain a minimal, audited set of Python dependencies to reduce the attack surface.

### How does the CLI prevent accidental auto_run activation?

The CLI startup logic in [`interpreter/terminal_interface/start_terminal_interface.py`](https://github.com/openinterpreter/open-interpreter/blob/main/interpreter/terminal_interface/start_terminal_interface.py) (lines 420-425) includes a safeguard that checks if Safe Mode is set to `"ask"` or `"auto"`. If Safe Mode is active, the code forcibly sets `auto_run = False` regardless of whether the user passed the `-y` or `--auto_run` flag. This ensures that safety settings always override convenience flags, preventing users from accidentally enabling automatic execution while expecting safety checks.

### What is the difference between auto_run and Safe Mode?

`auto_run` is a boolean flag that controls whether the terminal interface prompts for human confirmation before executing code chunks. When `True`, execution proceeds immediately after code generation. **Safe Mode** is a separate setting (`"off"`, `"ask"`, or `"auto"`) that controls whether the system runs semgrep security scans on generated code and how it handles detected threats. Safe Mode can provide automated security scanning even when `auto_run` is enabled, though the CLI disables `auto_run` by default when Safe Mode is active to prioritize safety.