Sandbox

Dear @t-kalinowski,

first of all, I highly appreciate mcp-repl. I find it incredibly useful (object persistence, handles figures, fast, ...)

I have been testing it from within LM Studio with a local LLM, and from within Claude Desktop using remote Claude Sonnet 4.6. Even with the --sandbox workspace-write option enabled, Claude used R to get access to files outside of the sandbox. Granted, macOS asked me, whether I would allow a process from my R venv access to files outside the sandbox, and I allowed it to see, how far the Claude model would get. It used R's readLines() and writeLines() and to apply a patch to a problematic python file residing on my Desktop.

From the sandbox.md file it seems that sandboxing is at least in part handled on the OS level. However, it seems to me that the sandbox should strictly prevent unwanted access at the mcp level, if this is possible. Granting access by accident on the OS level can happen far too easily. Now R is a mighty tool, and in my case it runs with normal user privileges. And therein lies of course part of the problem, because once granted, an agent can use R to obtain read/write access to any file the user has access to on a system.

I am open to suggestions on how to possibly make this more secure. I would like to transplant an agentic pipeline using mcp-repl from a small macOS test system to a production GPU server running Ubuntu, but I cannot judge, if accidentally breaking a sandbox could happen under Linux.

Start by reading sandbox.md and tracing how mcp-repl applies sandboxing on macOS and Linux. Compare the reported R readLines() and writeLines() access with the intended boundary, then define reproducible tests for file access through R and Python. Done should mean the boundary is enforced consistently or its limitations are clearly documented.