fix(server): make auto_run setting guard reachable in POST /settings

[sebastiondev]

Describe the changes you have made:

Vulnerability: auto_run setting protection is unreachable dead code (CWE-284)

The POST /settings endpoint in interpreter/core/async_core.py includes a check intended to block remote modification of the auto_run setting. However, the check is nested inside a conditional branch that only executes when the key is "llm" or "computer":

if key in ["llm", "computer"] and isinstance(value, dict):
    if key == "auto_run":  # <-- dead code: key can never be "auto_run" here
        return {"error": ...}, 403

Since "auto_run" is never equal to "llm" or "computer", the inner guard never fires. A client with network access to the server can set auto_run = True by sending a POST request, which causes the interpreter to execute code from subsequent prompts without user confirmation.

Fix: Move the auto_run check before the ["llm", "computer"] conditional so it is evaluated for every key in the payload.

Proof of Concept:

Against an unpatched server (default configuration, no API key set):

# Start the server
interpreter --server

# In another terminal — enable auto_run remotely
curl -X POST http://localhost:8000/settings \
  -H "Content-Type: application/json" \
  -d '{"auto_run": true}'
# Returns 200 — setting accepted (should return 403)

# Verify it took effect
curl http://localhost:8000/settings/auto_run
# Returns: true

After this fix, the same POST /settings call returns a 403 error explaining that auto_run is not modifiable through the server.

Adversarial review: Before submitting, we considered whether this is practically exploitable given default conditions. The server binds to localhost by default, and without INTERPRETER_API_KEY set, there is no authentication. This limits the attack surface to local network scenarios or deployments where the host/port has been changed to expose the server externally. However, the guard was clearly intended to block this — it's a straightforward logic bug where the protection is dead code. The fix is a one-line relocation that makes the existing security intent actually work, and serves as defense-in-depth for any deployment that exposes the server.

Reference any relevant issues (e.g. "Fixes #000"):

N/A — no existing issue for this bug.

Pre-Submission Checklist (optional but appreciated):

• I have included relevant documentation updates (stored in /docs)
• I have read docs/CONTRIBUTING.md
• I have read docs/ROADMAP.md

OS Tests (optional but appreciated):

• Tested on Windows
• Tested on MacOS
• Tested on Linux

---

_{Submitted by Sebastion — autonomous open-source security research from Foundation Machines. Free for public repos via the Sebastion AI GitHub App.}