Like shell execution tools, the new REPL tool gives the agent access to powerful execution mechanisms. It is essentially futile to try to restrict the power of these tools in an attempt to render them "safe". Instead, as mentioned in our security documentation, users should sandbox the agent as a whole if they are worried about the agent taking actions beyond the intended scope.

If you already provide your agent with a shell execution tool (be it Serena's or a built-in tool of your client), then adding the REPL should not heighten the risks. If you do not allow shell executions and your workflow relies on heavily restricting tool access, then using the REPL interface is not for you - but I would argue that sandboxing is most definitely the better option: A more powerful agent running in a sandbox is better than a crippled agent running outside of a sandbox.

If agents escape sandboxes, we should work on building better sandboxes instead of providing agents with less powerful tools that restrict their ability to solve the tasks assigned to them.

I agree that sandboxing matters, but it doesn’t answer all the concerns I raised.

Having shell access doesn’t automatically mean execution through Serena has equivalent controls. A shell might be subject to approvals, hooks, or isolation that Serena doesn’t inherit. How is that case handled?

The behavioral concern is separate: will agents keep Python usage inside Serena, or carry those instructions into unrelated project work? I’m raising that as something to evaluate, not claiming it is already proven.

And pointing to documentation doesn’t address users enabling this without understanding which restrictions no longer apply. Could that be made explicit during activation?

I also don’t think the choice is between a powerful sandboxed agent and a “crippled” one. A user can reasonably want both sandboxing and restricted capabilities. Those restrictions can be intentional requirements, not deficiencies.

I’m not asking you to abandon the REPL. I’m asking for these integration and behavioral concerns to be addressed directly, rather than reduced to whether users should sandbox their agents.

You either want the power of the REPL or you don't.
If you don't, you continue to have the option of using traditional tools; the REPL is an opt-in feature.
If you do, you have to either accept the risks or apply sandboxing. There is no other reasonable way to make it "safe".
The same applies to shell tools. Unless a shell tool is severely limited, it cannot be safe. Hooks, etc. are best-effort at most; they can trivially be circumvented. Approvals, however, are a valid control mechanism, and they equally apply to the REPL tool.

The behavioral concern is separate: will agents keep Python usage inside Serena, or carry those instructions into unrelated project work?

Intelligent agents can separate the respective contexts, so I don't anticipate any problems in this regard.

Those restrictions can be intentional requirements, not deficiencies.

The REPL supports restrictions, but they are soft rather than hard restrictions. For instance, if you enable read-only mode, Serena's functions with write access will be disabled - but being a general Python environment, the agent can find other ways of achieving write operations if it really wants to. And if the agent has access to a shell tool, it could most definitely apply write operations through that tool as well.