Serena

Serena runs as the OS user who launched it and does nothing to narrow that authority. Its shell tool, which is on by default, runs any command with the user's full environment, and language-server processes get a copy of the whole environment too. There is no per-request authorization layer and no read-only default; the only guidance against misuse is a line in the tool description asking the model not to run unsafe commands. If the model is steered by malicious content, it can use everything the user's account can reach, including cloud CLIs and keys in the environment.

As an MCP server, Serena leaves approval to the client and gives it only MCP hints. Tools inherit a read-only or destructive hint from an internal 'can edit' marker. The shell and file-edit tools are correctly flagged, but not every tool's hint is accurate. There is no dry-run or diff preview, and no confirmation step the server enforces. A read-only project mode exists but is off by default and set in the project's own repository file. Wrongly approved shell commands can make irreversible changes, and Serena keeps no checkpoint to undo them.

Serena's file and symbol tools check that paths stay inside the active project. The check is lexical, and the code allows symlinks on purpose. Two default-on tools make this boundary weak. The shell tool accepts any command string and any absolute working directory. activate_project lets the model make any directory, such as the home directory, the new project root. The default context exposes all non-optional tools, including shell and editing. Users can exclude tools globally or pick a narrower context.

The default shell tool runs model-written commands on the host as the same user, with no sandbox and the full environment. The optional REPL tool runs Python inside the Serena process. Serena ships an experimental Docker image that its security docs recommend as the only real protection. It is opt-in, runs as root with default capabilities and full network, and mounts the workspace read-write. That still beats the default, so the criterion takes the opt-in score, capped because it is off by default.

Serena reads untrusted content all the time: source files, search results, shell output, committed memories and the repository's .serena/project.yml. None of it is marked as untrusted. The project's initial_prompt is placed into the activation result as project instructions, and the tool descriptions tell the model to read memories before running commands. A repository author can therefore write directly to the model. The server offers no structural limit, so a hijacked session can run shell commands to leak data and make irreversible changes, unless the MCP client happens to gate them.

Serena loads state the repository controls. .serena/project.yml can inject an initial prompt, add tools and choose which language servers are downloaded and started. Memories under .serena/memories are designed to be committed and shared, and are offered to the model on activation. A trust setting, empty by default on new installs, gates only two project settings: the activation command and language-server overrides. The model can write and edit project and global memories freely; read-only patterns exist but are empty by default. A poisoned memory can therefore persist across sessions and spread to everyone who clones the repository.

With the default LSP backend, Serena downloads and runs third-party language servers on its own when a project is activated. Which servers run depends on languages it detects in the repository or on the repository's project.yml. Versions are pinned, and archive downloads are restricted by host and checked against a SHA-256 hash when one is configured. npm-based servers are pinned but installed without a digest. The servers run as separate processes under the same user with the full environment. The user is not asked before installation.

Serena holds almost no secrets of its own. Its local authentication secret is hidden from repr and kept in a config file restricted to its owner. Everything else is unprotected. Full tool arguments and results, including any secret a file read returns, are logged at INFO to ~/.serena/logs and to the dashboard. read_file can open gitignored files such as .env. The shell and language servers inherit the full environment. A content-free usage ping is sent by default unless SERENA_USAGE_REPORTING=false.

Every tool call goes through one wrapper. It logs the tool name and all arguments before running and logs the result afterwards, with timestamps, to a per-run file under ~/.serena/logs. The file is written by default, outside the project folder. It is plain text with no actor attribution, nothing makes it tamper-evident, and the shell tool can edit or delete it.

Serena applies a 240-second timeout and a 150,000-character output cap to every tool call. The timeout only stops waiting: the worker thread and any shell process keep running, and the shell call itself has no timeout. The model can raise the output cap on each call through max_answer_chars. There are no rate limits.