Allow list for urls/domains/url globs

[hadley]

The main thing that stops me from using mcp-repl for package development is when packages need to talk to the internet.

[t-kalinowski]

First PR toward this merged in #51, adding preliminary support. macOS only for now.

You can try it out with:

cargo install --git https://github.com/posit-dev/mcp-repl --locked

Then edit the launch command by adding a repeatable flag:

mcp-repl \
  --interpreter r \
  --sandbox workspace_write \
  --config sandbox_workspace_write.network_access=true \
  --add-allowed-domain pypi.org \
  --add-allowed-domain pythonhosted.org \
  --add-allowed-domain '**.r-project.org'

Still pending:

• Linux and Windows support
• Better defaults in mcp-repl install
• Docs updates
• Additional support for other workflows, in particular additional carve-outs to easily support local Shiny development and remote DB access

[hadley]

Would you consider having some config file in the working directory? Or do you want to avoid that because you then need to prevent the llm from editing it? Is it possible to change these settings after the repl has started?

[t-kalinowski]

Would you consider having some config file in the working directory?

Yes, I think that's a great idea. It can live in .agents/, .codex/, or .claude/ as mcp-repl.toml. Those directories are generally already write-restricted to the agent.

Is it possible to change these settings after the repl has started?

For the proxy, we'll be able to live-reload. For filesystem restrictions, however, we'd only be able to change the config for a fresh worker. An open question: should we:

a) have a file watcher that detects changed writeable_roots and kills and respawns the repl session worker automatically, as soon as the config file is changed, or
b) have the updated config not go into effect until the repl session worker is manually restarted, for example by the user asking the lll to call repl("^D"), or an equivalent like quit(), or by quitting and starting a new claude/codex process?

[hadley]

I think being explicit about the restart would be better, unless you want to save and reload the state of the current session (which is hard to do correctly and I think probably a bad idea).