<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Sandbox on Johan Eliasson</title><link>https://johan.eliasson.xyz/tags/sandbox/</link><description>Recent content in Sandbox on Johan Eliasson</description><generator>Hugo -- 0.144.1</generator><language>en-us</language><lastBuildDate>Fri, 21 Aug 2026 18:00:00 +0200</lastBuildDate><atom:link href="https://johan.eliasson.xyz/tags/sandbox/index.xml" rel="self" type="application/rss+xml"/><item><title>A cage for the Coding Agent</title><link>https://johan.eliasson.xyz/post/2026/a-cage-for-the-coding-agent/</link><pubDate>Fri, 21 Aug 2026 18:00:00 +0200</pubDate><guid>https://johan.eliasson.xyz/post/2026/a-cage-for-the-coding-agent/</guid><description>&lt;p>Pretty much regardless of harness, running a coding agent (by general convention) means approving or whitelisting commands one by one - or skipping all that with something like Claude Code&amp;rsquo;s &lt;code>--dangerously-skip-permissions&lt;/code> and living in danger-land.&lt;/p>
&lt;p>I&amp;rsquo;ve scratched this itch recently with a &lt;a href="https://johan.eliasson.xyz/post/2026/sandbox-for-agents/">Sandbox for Agents&lt;/a> for a personal AI assistant, over MCP. The reasoning is the same here: let the agent run pretty much anything inside a sandbox while reducing the attack surface, and allow for project-specific host resources to be exposed when needed.&lt;/p></description></item></channel></rss>