https://community.databricks.com/t5/technical-blog/letting-coding-agents-move-fast-without-breaking-everything/ba-p/152236 <P><SPAN>Your preferred AI model is a deeply personal choice. Public benchmarks might declare the “best” model for a specific task, but they don’t account for your workflow or how you access information, which can change the calculation entirely.</SPAN></P> <P><SPAN>Person A might find that using Gemini for a specific task is more productive than Claude because of the workflow they’ve adopted, while Person B might disagree and prefer Codex instead.</SPAN></P> <P><SPAN>Databricks Coding Agents give you access to top frontier models, letting you choose the best model for your workflow.</SPAN></P> <P><SPAN><span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="ezgif-6c9cee9d80b51dd4.gif" style="width: 999px;"><img src="https://community.databricks.com/t5/image/serverpage/image-id/27178iBB88C3F1EDAA1696/image-size/large?v=v2&amp;px=999" role="button" title="ezgif-6c9cee9d80b51dd4.gif" alt="ezgif-6c9cee9d80b51dd4.gif" /></span></SPAN></P> <P style="text-align: center;"><SPAN><EM>Databricks AI Gateway</EM></SPAN></P> <H3><SPAN>The new bottleneck: Human approval</SPAN></H3> <P><SPAN>As you get more proficient with these agents, you realise that the bottleneck isn’t the agents, it’s you having to approve every single action.</SPAN></P> <P><SPAN>Reviewing every edit kills your speed. But giving your agent access to your entire workspace and letting it run unchecked with </SPAN><CODE>--dangerously-skip-permissions</CODE><SPAN> or </SPAN><CODE>--yolo</CODE><SPAN> can lead to severe unintended consequences:</SPAN></P> <UL> <LI style="font-weight: 400;" aria-level="1"><SPAN><A href="https://www.theguardian.com/technology/2026/feb/20/amazon-cloud-outages-ai-tools-amazon-web-services-aws" target="_blank" rel="noopener">Amazon’s Kiro AI assistant took it upon itself to delete and recreate the environment during a routine task, causing a 13-hour outage.</A></SPAN></LI> <LI style="font-weight: 400;" aria-level="1"><SPAN><A href="https://x.com/summeryue0/status/2025774069124399363" target="_blank" rel="noopener">At Meta, even after explicitly asking her OpenClaw agent to confirm before every action, the director of AI Safety &amp; Alignment still watched it bulk-delete and archive hundreds of emails.</A></SPAN></LI> </UL> <HR /> <P>&nbsp;</P> <H3><SPAN>The solution: Containers as a blast radius limiter</SPAN></H3> <P><SPAN>The solution is straightforward. Run your coding agent inside a container, provide the environment variables and mount only the directories it should touch.</SPAN></P> <P><SPAN>The agent gets full autonomy inside the container, so it can read, write, and execute freely. But “freely” only applies to the environment variables you pass in and the directories you choose to mount. Your home directory, SSH keys, shell config, and every other project are invisible to it, limiting the blast radius of the agent’s mistakes.</SPAN></P> <PRE><CODE>+-------------------------------------+ | Your Machine | | | | ~/.zshrc &lt;- untouchable | | ~/.ssh/ &lt;- untouchable | | ~/Documents/ &lt;- untouchable | | | | ~/my-project/ ---- mounted ---&gt;+ | | | | | +---------------------------+ | | | | Docker Container | | | | | | | | | | /workspace &lt;- only this |&lt;--+ | | | | | | | Agent runs here with | | | | full permissions but | | | | can only see /workspace | | | +---------------------------+ | +-------------------------------------+</CODE></PRE> <H3><SPAN>Getting Started</SPAN></H3> <P><SPAN>While there are many ways to define containers, this article will use Dockerfiles and also assume that your coding agents are configured to use Databricks endpoints. It will describe the following:</SPAN></P> <OL> <LI style="font-weight: 400;" aria-level="1"><SPAN>The container Dockerfiles</SPAN></LI> <LI style="font-weight: 400;" aria-level="1"><SPAN>How to provide environment variables and mount directories</SPAN></LI> <LI style="font-weight: 400;" aria-level="1"><SPAN>Specific commands that reduce blast radius</SPAN></LI> </OL> <HR /> <P>&nbsp;</P> <H3><SPAN>The Dockerfiles</SPAN></H3> <P><SPAN>We start by defining a container for Claude Code, Gemini or Codex. I’ve published sandbox templates for each of these agents </SPAN><A href="https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-05-coding-agent-sandboxes" target="_blank" rel="noopener"><SPAN>here</SPAN></A><SPAN>.</SPAN></P> <P><SPAN>Each template is intentionally minimal. Here’s the Claude one in its entirety:</SPAN></P> <PRE><CODE># Minimal Claude Code sandbox FROM node:20-bookworm # Install Claude Code CLI # Note: unpinned version resolves to latest at build time. Pin for reproducibility, e.g.: # RUN npm install -g @anthropic-ai/claude-code@1.x RUN npm install -g @anthropic-ai/claude-code # --- Add project-specific dependencies below (e.g., Go, Terraform, Python, Rust) --- # --- End project-specific dependencies --- # Create non-root user with a fixed uid so --tmpfs uid=1001 in docker run # always matches this user (Claude Code blocks --dangerously-skip-permissions as root) RUN useradd -m -s /bin/bash -u 1001 agent \ &amp;&amp; mkdir -p /home/agent/.claude \ &amp;&amp; chown -R agent:agent /home/agent # Set working directory WORKDIR /workspace # Switch to non-root user USER agent # Default command ENTRYPOINT ["claude"]</CODE></PRE> <P><SPAN>The Codex and Gemini templates follow the same pattern. Just swap out the CLI package and the relevant configuration directory for your coding agent, then build the image:</SPAN></P> <PRE><CODE># Claude docker build -f Dockerfile.claude.template -t claude-code:latest . # Codex docker build -f Dockerfile.codex.template -t codex-cli:latest . # Gemini docker build -f Dockerfile.gemini.template -t gemini-cli:latest .</CODE></PRE> <P><SPAN>If you require additional tools, add them to the Dockerfile. On Apple Silicon, add </SPAN><CODE>--platform linux/arm64</CODE><SPAN> for native performance.</SPAN></P> <HR /> <P>&nbsp;</P> <H3><SPAN>How to provide environment variables and mount directories</SPAN></H3> <P><SPAN>Assuming you have configured authentication following the Databricks Coding Agents setup instructions for </SPAN><A href="https://docs.databricks.com/aws/en/ai-gateway/coding-agent-integration-beta" target="_blank" rel="noopener"><SPAN>AWS</SPAN></A><SPAN>, </SPAN><A href="https://learn.microsoft.com/en-us/azure/databricks/ai-gateway/coding-agent-integration-beta" target="_blank" rel="noopener"><SPAN>Azure</SPAN></A><SPAN>, or </SPAN><A href="https://docs.databricks.com/gcp/en/ai-gateway/coding-agent-integration-beta" target="_blank" rel="noopener"><SPAN>GCP</SPAN></A><SPAN>, the config files need small adjustments to work inside a container. See the </SPAN><A href="https://github.com/databricks-solutions/databricks-blogposts/blob/main/2026-05-coding-agent-sandboxes/readme.md" target="_blank" rel="noopener"><SPAN>readme</SPAN></A><SPAN> located with the sandbox templates for working examples.</SPAN></P> <P><SPAN>After that navigate to the project you want the agent to work on and run the container. The project directory gets mounted as </SPAN><CODE>/workspace</CODE><SPAN>, and each agent reads its Databricks credentials differently depending on what the CLI supports:</SPAN></P> <P><SPAN><STRONG>Codex:</STRONG></SPAN></P> <PRE><CODE>docker run -it --rm \ --cap-drop=ALL \ --security-opt=no-new-privileges \ --read-only \ --tmpfs /tmp:rw,size=128m \ --tmpfs "/home/agent:rw,size=128m,uid=1001,gid=1001" \ --pids-limit=512 \ --memory=4g \ -e DATABRICKS_TOKEN \ -v $(pwd):/workspace \ -v ~/.codex:/home/agent/.codex \ codex-cli:latest</CODE></PRE> <P><SPAN><STRONG>Gemini:</STRONG></SPAN></P> <PRE><CODE>docker run -it --rm \ --cap-drop=ALL \ --security-opt=no-new-privileges \ --read-only \ --tmpfs /tmp:rw,size=128m \ --tmpfs "/home/agent:rw,size=128m,uid=1001,gid=1001" \ --pids-limit=512 \ --memory=4g \ -v $(pwd):/workspace \ --env-file ~/.gemini/.env \ gemini-cli:latest --yolo</CODE></PRE> <P><SPAN><STRONG>Claude:</STRONG></SPAN></P> <PRE><CODE>docker run -it --rm \ --cap-drop=ALL \ --security-opt=no-new-privileges \ --read-only \ --tmpfs /tmp:rw,size=128m \ --tmpfs "/home/agent:rw,size=128m,uid=1001,gid=1001" \ --pids-limit=512 \ --memory=4g \ -v $(pwd):/workspace \ -v ~/.claude/settings.json:/home/agent/.claude/settings.json:ro \ claude-code:latest --verbose --dangerously-skip-permissions</CODE></PRE> <P><SPAN>That’s it. The agent launches in interactive mode, sees only </SPAN><CODE>/workspace</CODE><SPAN>, and everything else on your machine is invisible.</SPAN></P> <P><SPAN>Here are a few notes on how credentials are passed for each coding agent:</SPAN></P> <OL> <LI style="font-weight: 400;" aria-level="1"><SPAN>Claude Code mounts </SPAN><CODE>settings.json</CODE><SPAN> as a single read-only file and only reads this file at startup.</SPAN></LI> <LI style="font-weight: 400;" aria-level="1"><SPAN>Codex mounts the whole </SPAN><CODE>~/.codex</CODE><SPAN> directory (not just the config file) because Codex needs to save session data alongside its config. Your </SPAN><CODE>config.toml</CODE><SPAN> should tell Codex to read the token from the </SPAN><CODE>DATABRICKS_TOKEN</CODE><SPAN> environment variable rather than running a shell command to fetch one, since the container does not have the Databricks CLI installed.</SPAN></LI> <LI style="font-weight: 400;" aria-level="1"><SPAN>Gemini passes credentials using </SPAN><CODE>--env-file</CODE><SPAN> which loads your </SPAN><CODE>.env</CODE><SPAN> file as environment variables. This is used instead of mounting the file directly because Gemini needs to write other files into its config directory. One thing to watch out for is that values in the </SPAN><CODE>.env</CODE><SPAN> file should not have quotes around them. For example use </SPAN><CODE>GEMINI_API_KEY_AUTH_MECHANISM=bearer</CODE><SPAN>, as Docker reads the quotes literally, which breaks authentication.</SPAN></LI> </OL> <HR /> <P>&nbsp;</P> <H3><SPAN>Commands that reduce blast radius</SPAN></H3> <P><SPAN><STRONG>1. </STRONG></SPAN><CODE><STRONG>-v</STRONG></CODE><SPAN><STRONG> mounts only the directories you specify</STRONG></SPAN></P> <PRE><CODE>-v $(pwd):/workspace</CODE></PRE> <P><SPAN>Use </SPAN><CODE>-v</CODE><SPAN> to mount directories into the container. Only the directories you explicitly mount are visible to the agent. Everything else on your machine does not exist from the agent’s perspective.</SPAN></P> <P><SPAN><STRONG>2. </STRONG></SPAN><CODE><STRONG>-e</STRONG></CODE><SPAN><STRONG> passes only the environment variables you specify</STRONG></SPAN></P> <PRE><CODE>-e DATABRICKS_TOKEN</CODE></PRE> <P><SPAN>Use </SPAN><CODE>-e</CODE><SPAN> to pass environment variables into the container. The agent only has access to the variables you explicitly declare.</SPAN></P> <P><SPAN><STRONG>3. </STRONG></SPAN><CODE><STRONG>:ro</STRONG></CODE><SPAN><STRONG> makes mounts read-only</STRONG></SPAN></P> <PRE><CODE>-v ~/.claude/settings.json:/home/agent/.claude/settings.json:ro</CODE></PRE> <P><SPAN>The </SPAN><CODE>:ro</CODE><SPAN> flag makes the mounted file read-only inside the container. The agent can read your credentials to authenticate, but cannot overwrite or corrupt them.</SPAN></P> <P><SPAN><STRONG>4. Non-root user</STRONG></SPAN></P> <PRE><CODE>RUN useradd -m -s /bin/bash -u 1001 agent USER agent</CODE></PRE> <P><SPAN>The agent process runs as a regular user, not root. Even inside the container, this prevents the agent from modifying system files or installing packages at runtime.</SPAN></P> <P><SPAN><STRONG>5. Root-owned workspace</STRONG></SPAN></P> <PRE><CODE>WORKDIR /workspace</CODE></PRE> <P><CODE>WORKDIR</CODE><SPAN> runs before </SPAN><CODE>USER agent</CODE><SPAN>, so </SPAN><CODE>/workspace</CODE><SPAN> is created as root. If you forget the </SPAN><CODE>-v</CODE><SPAN> mount, the agent gets a permission denied error instead of silently writing to a throwaway filesystem. This is a fail-closed design. The container does nothing useful unless you explicitly mount a directory.</SPAN></P> <P><SPAN><STRONG>6. </STRONG></SPAN><CODE><STRONG>--cap-drop=ALL</STRONG></CODE><SPAN><STRONG> removes all special OS permissions</STRONG></SPAN></P> <PRE><CODE>--cap-drop=ALL</CODE></PRE> <P><SPAN>Containers get a set of Linux capabilities by default (things like changing file ownership or binding to low ports). The agent doesn’t need any of them. Dropping them all means even if something goes wrong inside the container, it can’t do anything privileged.</SPAN></P> <P><SPAN><STRONG>7. </STRONG></SPAN><CODE><STRONG>--security-opt=no-new-privileges</STRONG></CODE><SPAN><STRONG> blocks privilege escalation</STRONG></SPAN></P> <PRE><CODE>--security-opt=no-new-privileges</CODE></PRE> <P><SPAN>Stops the agent from running a program that grants itself higher permissions. This closes the “exploit a setuid binary” loophole that attackers commonly use to escalate from a regular user to root.</SPAN></P> <P><SPAN><STRONG>8. </STRONG></SPAN><CODE><STRONG>--read-only</STRONG></CODE><SPAN><STRONG> with writable tmpfs (temporary file system) mounts</STRONG></SPAN></P> <PRE><CODE>--read-only --tmpfs /tmp:rw,size=128m --tmpfs "/home/agent:rw,size=128m,uid=1001,gid=1001"</CODE></PRE> <P><SPAN>Makes the container’s own filesystem immutable. The agent can’t install packages or drop scripts into system directories. The CLI tools still need somewhere to write session state and temp files, so we give them two small writable locations: </SPAN><CODE>/tmp</CODE><SPAN> and the agent’s home directory. Both are capped at 128 MB and get thrown away when the container exits. Your mounted project folder is the only place where real work persists.</SPAN></P> <P><SPAN>The </SPAN><CODE>uid=1001,gid=1001</CODE><SPAN> part sets ownership of the tmpfs to the </SPAN><CODE>agent</CODE><SPAN> user inside the container. Without it, the tmpfs is owned by root and the agent can’t write to its own home directory. The 1001 value matches the uid we pinned in the Dockerfile with </SPAN><CODE>useradd -u 1001 agent</CODE><SPAN>.</SPAN></P> <P><SPAN><STRONG>9. </STRONG></SPAN><CODE><STRONG>--pids-limit=512</STRONG></CODE><SPAN><STRONG> caps the number of processes</STRONG></SPAN></P> <PRE><CODE>--pids-limit=512</CODE></PRE> <P><SPAN>Limits how many processes can run at once inside the container. If a command goes haywire and starts spawning processes in a loop, it hits this ceiling instead of eating all your host resources.</SPAN></P> <P><SPAN><STRONG>10. </STRONG></SPAN><CODE><STRONG>--memory=4g</STRONG></CODE><SPAN><STRONG> caps RAM usage</STRONG></SPAN></P> <PRE><CODE>--memory=4g</CODE></PRE> <P><SPAN>Specifies a hard cap on the memory allowed to be consumed by the container. If the agent spawns something that leaks memory, the container gets killed at 4 GB instead of consuming your whole machine’s RAM. Adjust the value based on your workload.</SPAN></P> <HR /> <P>&nbsp;</P> <H3><SPAN>Customizing for your stack</SPAN></H3> <P><SPAN>The templates are starting points. If your project needs specific toolchains, copy a template into a subdirectory and add dependencies in the marked section:</SPAN></P> <PRE><CODE># --- Add project-specific dependencies below (e.g., Go, Terraform, Python, Rust) --- RUN apt-get update &amp;&amp; apt-get install -y python3 python3-pip \ &amp;&amp; apt-get clean &amp;&amp; rm -rf /var/lib/apt/lists/* # --- End project-specific dependencies ---</CODE></PRE> <HR /> <P>&nbsp;</P> <H3><SPAN>Shell alias (macOS / Linux)</SPAN></H3> <P><SPAN>You can wrap the container command in a shell alias so running your sandboxed agent feels like calling a local CLI. I call mine </SPAN><CODE>claudex</CODE><SPAN>.</SPAN></P> <P><SPAN>On macOS or Linux, add this to your </SPAN><CODE>~/.zshrc</CODE><SPAN> (or </SPAN><CODE>~/.bashrc</CODE><SPAN><span class="lia-unicode-emoji" title=":disappointed_face:">😞</span></SPAN></P> <PRE><CODE>claudex() { docker run -it --rm \ --cap-drop=ALL \ --security-opt=no-new-privileges \ --read-only \ --tmpfs /tmp:rw,size=128m \ --tmpfs "/home/agent:rw,size=128m,uid=1001,gid=1001" \ --pids-limit=512 \ --memory=4g \ --workdir $(pwd) \ -v $(pwd):$(pwd) \ -v ~/.claude/settings.json:/home/agent/.claude/settings.json:ro \ claude-code:latest --verbose --dangerously-skip-permissions "$@" }</CODE></PRE> <P><SPAN>This mounts your current directory at the same absolute path inside the container (so the agent sees the same file paths you do on the host) and sets </SPAN><CODE>--workdir</CODE><SPAN> to match. Your Claude settings are mounted read-only for authentication. The agent is confined to the working directory and cannot access or modify anything else on your host machine.</SPAN></P> <P><SPAN>After reloading your shell (for example, </SPAN><CODE>source ~/.zshrc</CODE><SPAN>), you can run </SPAN><CODE>claudex</CODE><SPAN> from any project directory to launch the agent inside its container.</SPAN></P> <P><SPAN>On Windows, you can achieve something similar with PowerShell functions or aliases, but the exact setup will differ from the macOS/Linux example above.</SPAN></P> <HR /> <P>&nbsp;</P> <H3><SPAN>What this doesn’t protect against</SPAN></H3> <P><SPAN>Containers limit filesystem access, not network access. The agent can still make API calls, download packages, or reach the internet. Docker does not offer fine-grained network controls out of the box. Adding </SPAN><CODE>--network=none</CODE><SPAN> to your </SPAN><CODE>docker run</CODE><SPAN> command blocks all traffic including the model API. Fine-grained network control requires additional tooling like a forward proxy, which is beyond the scope of this article.</SPAN></P> <P><SPAN>This also doesn’t protect the mounted directory itself. If you mount </SPAN><CODE>$(pwd):/workspace</CODE><SPAN>, the agent can delete everything in that directory. Use git branches or worktrees so you can always revert.</SPAN></P> <P><SPAN>Note: Since the release of Claude’s model Mythos, there is growing discussion around the next wave of models being able to discover and exploit container breakout vulnerabilities, sometimes without the prompter even knowing it happened. Containers share the host kernel, and a sufficiently capable agent that finds a kernel exploit can escape the container entirely.</SPAN></P> <P><SPAN>This is driving interest in using virtual machines instead, as they run their own kernel. So even if the agent compromises the guest operating system, it cannot reach the host.</SPAN></P> <P><SPAN>For most development workflows today, containers remain a practical and meaningful improvement over running agents directly on your host. But if you are giving agents access to sensitive environments or running untrusted prompts, consider whether VM-level isolation is more appropriate for your threat model. The industry is moving in this direction, and it is worth watching how vendors respond as model capabilities continue to advance.</SPAN></P> <HR /> <P>&nbsp;</P> <H3><SPAN>Conclusion</SPAN></H3> <P><SPAN>We have just gone through how to use each frontier model in a container sandbox. Each model’s credentials are passed into the container (via read-only mounts, env vars, or env files depending on the CLI) allowing you to connect to the models hosted on Databricks.</SPAN></P> <P><SPAN>With a sandbox environment, you don’t have to choose between speed and safety. Run your coding agent in a container, mount only what it needs, and let it work with full permissions inside that boundary. The worst case goes from “agent deletes your home directory” to “agent makes a mess in one git branch.”</SPAN></P> <P><SPAN>The Dockerfiles are available on </SPAN><A href="https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-05-coding-agent-sandboxes" target="_blank" rel="noopener"><SPAN>GitHub</SPAN></A><SPAN>.</SPAN></P> <P><SPAN>Pick a template, build it, and start sandboxing.</SPAN></P> Thu, 21 May 2026 15:30:11 GMT jlieow 2026-05-21T15:30:11Z https://community.databricks.com/t5/technical-blog/letting-coding-agents-move-fast-without-breaking-everything/ba-p/152236 <P><SPAN>As you get proficient with coding agents, you realise that the biggest bottleneck isn’t the model. It’s you, sitting there approving every single action.</SPAN><SPAN><BR /></SPAN><SPAN><BR /></SPAN><SPAN>Reviewing every edit kills your speed. But letting an agent run unchecked with --dangerously-skip-permissions or --yolo can lead to terrible outcomes.</SPAN><SPAN><BR /></SPAN><SPAN><BR /></SPAN><SPAN>What if there were a way to constrain your agent’s access to only the secrets and files it’s expected to edit?</SPAN></P> Thu, 21 May 2026 15:30:11 GMT https://community.databricks.com/t5/technical-blog/letting-coding-agents-move-fast-without-breaking-everything/ba-p/152236 jlieow 2026-05-21T15:30:11Z