DEV Community: Hendrik Boelcke

Claude Code in Docker Sandboxes

Hendrik Boelcke — Fri, 26 Jun 2026 08:25:46 +0000

This article was also published in German!

Since generative AI took off, I've found it increasingly hard to find reliable information. It used to be easier to judge whether a Stack Overflow thread or a tutorial would actually help me. For most topics, I knew where to look. Today, there are so many new sources out there and honestly, I struggle to assess the quality of most of them. So I want to take a step back, work through the topic of "Claude Code, but safely", and share what I've learned along the way.

Some context

Until recently, my exposure to agentic engineering was fairly limited: conversations with colleagues and friends, the occasional podcast episode, and LinkedIn posts that often felt shallow and hype-driven.

Then I attended a two-day workshop on agentic engineering at work.
We basically just typed claude into the terminal and let the agent do its thing.
The presenter talked a lot about "guardrails" but largely ran Claude Code in automode without really addressing what could go wrong.

And here's the thing: There's a real risk hiding in plain sight. claude runs with your full user permissions on the host system by default. Concretely, that means:

Full filesystem access: everything your user can read, including ~/.ssh, ~/.aws, .env files, and so on
Unrestricted network access: arbitrary URLs, downloads, outbound connections, credential exfiltration
Process execution: shell commands, changing system settings, running package installers, creating cron jobs
Access to all shell environment variables, including any API keys you've set

Imagine an AI agent accidentally running rm -rf in the wrong directory, modifying your Git configuration, or leaking an .env file. None of these actions are intentional, but they're possible if the agent has unrestricted access.

That's a steep price for automode, whose main benefit is avoiding the fatigue of confirming every single action.

Docker Sandboxes addresses this directly: the agent runs in a container with a defined network policy, an isolated filesystem, and no access to host secrets.
You don't have to judge every action on the fly because you set the boundaries upfront.

Docker Sandboxes

A former colleague of mine (shoutout to Stefan!) posted on LinkedIn about using Docker Sandboxes and being impressed.
That was enough for me to dig in.

That brought me back to the original problem from the intro: which source do I trust?
I started with the official Docker Sandboxes documentation, which is solid.
But for a first overview, I wanted something more digestible - ideally a video.
YouTube has no shortage of tutorials on this topic, so picking one wasn't easy.
I went with a video that had a decent number of views and good ratings.

It turned out to be about 75% useful. The creator walked through the concept, toured the documentation, and gave me a solid getting-started path. The part about using a local model wasn't relevant to my setup, but everything else landed well.

My setup

Installation was straightforward:

brew install docker/tap/sbx    # install the sbx CLI
sbx login                      # log in with your Docker account
sbx secret set -g anthropic    # store your Anthropic API key

On first login, you're prompted to choose a default network policy:

1. Open        - All connections allowed
2. Balanced    - Default deny, common dev domains allowed
3. Locked Down - Everything blocked unless explicitly allowed

I went with Balanced. It allows AI provider APIs, common package managers, and GitHub, while blocking everything else.

After that, starting your first sandbox is as simple as:

cd ~/my-project
sbx run claude

The sbx dashboard

I'd recommend running the sbx dashboard in a separate terminal alongside your session:

sbx   # opens the interactive dashboard

From there you can see:

Which sandboxes are currently running (navigate with arrow keys)
i shows details: name, agent, status, mounted directories, resource usage
A live log of all allowed and blocked network requests

The network tab in particular is unexpectedly useful.
You can watch in real time which connections Claude is making:

A few hours later

Inside the sandbox, Claude requires an initial /login. After that, Claude Code starts with --dangerously-skip-permissions by default. That's intentional: the sandbox itself is the security boundary. It doesn't protect against every possible risk, but it dramatically reduces the blast radius.

Repository analysis based on a prompt (essentially the content of my current user story) works just as expected, and generating code and test classes runs without issues.

The first obstacle came when the newly generated integration test couldn't be executed and the solution therefore couldn't be automatically verified.

The ~/.m2 directory doesn't exist — Maven hasn't been run yet in this environment,
so no local repository has been created.

The ~/.m2 directory simply doesn't exist in the sandbox. So there are no cached dependencies available. On top of that, the network policy was blocking access to repo.maven.apache.org, so the Maven Wrapper couldn't bootstrap Maven either.

At this point I had two options: run the test myself (Claude gave me the exact mvnw command) or grant Claude the necessary access.
Since I'm comfortable with both repo.maven.apache.org and the local ~/.m2/repository, I went with the latter.

A note on ~/.m2/settings.xml: Claude suggested mounting the settings.xml alongside the repository directory. Since that file can contain credentials for private repositories, I mounted only ~/.m2/repository so the settings.xml stays off-limits.

New sandbox with the m2 mount

You can't add mounts to a running container after the fact, so I had to delete the existing sandbox and create a new one.

Before doing that, I asked Claude to summarize the session:

Summarize what we've done so far and what's next

Claude summarized the problem we'd analyzed, the findings, the code changes made, and - most importantly - the list of blockers with their causes and possible solutions. You can persist this context with /memory.

Important: the /memory context is stored inside the container by default, which means it's gone when the container is deleted. Before proceeding, make sure the context has actually been saved to your project directory or to ~/.claude/MEMORY.md on the host. I got caught out by this and lost the context. Fortunately, not much had happened yet, so the damage was limited.

Deleting the old sandbox and creating a new one (including ~/.claude as additional volume mount):

sbx rm <sandbox-name>

sbx create claude --name shop-dev \
  "$(pwd)" \              # project directory
  ~/.m2/repository:ro \   # Maven cache, read-only
  ~/.claude/              # Claude directory with write access

Then start it:

sbx run shop-dev

I reconstructed the lost context by asking Claude to look at the existing changes in the project and pick up from there.

Allowing network access after the fact

Claude tried to run the integration test again but hit the same wall: the Maven Wrapper needed to download Maven, and the network was still blocked (clearly visible in the sbx dashboard).

This can be fixed from a separate terminal without restarting the sandbox:

sbx policy allow network --sandbox shop-dev repo.maven.apache.org

Back in Claude:

Try it again

Maven installs. Then Claude notices that our internal artifact registry is also unreachable. The failed request shows up in the dashboard. Since Claude has no credentials for the registry (and shouldn't), it solves the problem on its own: it creates a custom settings.xml that points to the mounted ~/.m2/repository as a local file:// repository.

After that, all tests pass.

Wrap-up

The result on this branch is ready to review (or hand off to a review agent), push to GitHub, and open a pull request.

This setup does require some upfront configuration: directory mounts, network policies, one-time initialization. It can be simplified with a bash alias or wrapper script, but it's not entirely frictionless.

What cost me the most time, though, was a hallucination: Claude suggested a settings.json entry for automatic mounts that simply doesn't exist. That cost me a context I could have kept. A good reminder to always verify AI suggestions about your own toolchain configuration.

Overall, though, this experiment shows clearly what Docker Sandboxes delivers: by default, only your chosen working directory and a well-defined set of URLs are accessible. Everything else has to be explicitly unlocked.

Working inside the sandbox, I feel noticeably more relaxed running Claude Code. And at the same time, the restrictions make it very clear just how many requests and file operations Claude makes in automode without one. As a developer, it gives you a meaningful degree of control back over your own system and over resources within your organization. The configuration overhead is absolutely worth it. Running the dashboard alongside Claude Code has made the whole experience feel noticeably more controlled.

How do you assess this setup? Is there a better approach for mounting additional directories? Any general tips on agentic engineering and working with Claude Code? I look forward to your feedback!

Disclaimer: I wrote this text, but it was translated with the help of AI.

How to: Replace Rollup.js with Vite ⚡️

Hendrik Boelcke — Sat, 02 Mar 2024 12:49:23 +0000

For me, it was once again time to take care of a project that I haven't worked on for almost a year. As we can see in the output below (the package.json was analyzed using npm-check-updates), the project still uses rollup.js and many libraries have become outdated in the meantime:

Current dependencies:

@rollup/plugin-commonjs      ^21.1.0  →   ^25.0.7
@rollup/plugin-node-resolve  ^13.3.0  →   ^15.2.3
@rollup/plugin-replace        ^3.1.0  →    ^5.0.5
@rollup/plugin-typescript     ^8.5.0  →   ^11.1.6
@tsconfig/svelte              ^2.0.1  →    ^5.0.2
contentful                    ^9.3.5  →  ^10.6.21
prettier                      ^2.8.8  →    ^3.2.5
prettier-plugin-svelte       ^2.10.1  →    ^3.2.1
rollup                       ^2.79.1  →   ^4.12.0
rollup-plugin-css-only        ^3.1.0  →    ^4.5.2
rollup-plugin-scss            ^3.0.0  →    ^4.0.0
svelte                       ^3.59.2  →   ^4.2.11
svelte-check                 ^2.10.3  →    ^3.6.4
svelte-preprocess            ^4.10.7  →    ^5.1.3
typescript                    ^4.9.5  →    ^5.3.3

So it's time to update!

Update the application and dependencies

In fact, the introduction of Vite and updating the dependencies were much easier than anticipated. These are the steps I took:

Setup the basics:

Run npm create vite@latest, enter a <project-name> and choose svelte. When the initial setup is done copy all newly generated files from ./<project-name> to the actual project directory. Afterwards delete package-lock.json once and run npm install. You can also delete rollup.config.js now.

Further tasks

The basic setup is now already done! All I have to do now is to install the dependencies I'm using for my project (like leaflet, contentful, sass, etc.) and replace the generated App.svelte file with my actual application files.

Since I'm using some environment variables I also have to prefix the variable names in .env with VITE_ and replace all process.env.VARIABLEs with import.meta.env.VITE_VARIABLE in the source files.

Bonus task: Run ncu once again and update!

I then checked the dependencies again with ncu:

➜  vgnmap git:(feat/replace-rollup) ncu
Checking /Users/hendrik/dev/vgnmap/package.json
[====================] 16/16 100%

 @playwright/test          1.41.2  →    1.42.1
 @types/node             20.11.19  →  20.11.24
 contentful               10.6.21  →   10.6.22
 prettier-plugin-svelte     3.2.1  →     3.2.2
 svelte                    4.2.11  →    4.2.12
 svelte-check               3.6.4  →     3.6.6
 typescript                 5.2.2  →     5.3.3

This time there were only minor updates. But while I'm at it, I'll also install these updates! I simply run ncu -u followed by npm install!

Comparison: build times

Let's take a look at the times required for the production build

Using Rollup.js:

➜  vgnmap git:(main) ✗ npm run build

> svelte-app@1.0.0 build
> rollup -c


src/main.ts → public/build/bundle.js...

created public/build/bundle.js in 2.8s

Using Vite:

➜  vgnmap git:(feat/replace-rollup) npm run build
> vgnmap@1.1.0 build
> vite build

 ✓ 46 modules transformed.
dist/index.html                   1.23 kB │ gzip:  0.66 kB
dist/assets/index-DfWY1ihM.css   19.01 kB │ gzip:  7.45 kB
dist/assets/index-CPtvyui6.js   265.34 kB │ gzip: 84.48 kB
✓ built in 857ms

As we can see, the build for the same application is two seconds faster with Vite than with Rollup. Furthermore: Vite also works noticeably faster in development mode! 💛

Netlify deployment issues 🚨

Two notes if you also deploy your application to Netlify:

Don't forget to update the names of your environment variables on netlify.app!
Vite places the build output in the dist folder. So you have to change your Netlify Deploment settings, otherwise you'll get a 404 error!

References:

For reference you can take a look at these commits:

For general information about Vite see: https://vitejs.dev/guide/

Find a vegan restaurant near you - With the help of Svelte!

Hendrik Boelcke — Mon, 10 Jan 2022 10:53:16 +0000

Trying out Svelte was on my bucket list for months or maybe even for years.Especially after watching this talk by Rich Harris.

When I was thinking about vegan restaurants in my hometown I finally found a suitable use case: I wanted to show my favourite vegan food locations on a map. That way I can remember where I've been and which restaurants I still want to go to. I also wanted to display information such as the address or excerpts from the menu in a list 🍔🍕🍣 🌱. In addition, the list should focus on the selected restaurant on the map when clicked.

Implementation

To store and provide the data about the restaurants, I use the content management system Contentful. In my current client project, I already work with another CMS, but I find Contentful very suitable for managing the restaurants. In particular, the Google Maps function integrated into Contentful was very helpful. With it, I can search for a restaurant and save the coordinates determined by Google Maps in the CMS. With a simple GET request, I can then retrieve the coordinates together with other restaurant data like address, website, etc. and show them in the frontend 🗺.

I created the Svelte project with degit according to these instructions. In addition, I use TypeScript and SCSS, which can be configured subsequently with little effort. The application itself consists mainly of a GET request to Contenful to read the restaurant data. I use Leaflet to display the map.
Now when I publish new restaurants in Contenful, they are visible in the frontend after a few seconds. Oh, and have you already discovered the very simple dark mode? 🌚

The application was deployed on Netlify. A push on the main branch in Github starts the build process on Netlify, where the latest version of the project is then delivered:

Svelte Highlights

In preparation for the development of the application, I only spent a few hours reading the pretty good Svelte tutorial. So I would not be surprised if the code is not optimal in some places. However, I did recognise a few highlights from Svelte, especially compared to React or Vue.js.

Reactive declarations

I really like the idea of reactive declarations. The label of the theme button depends on which theme is currently selected.
themeLabel will be recomputed when theme changes and Svelte will afterwards update the DOM. To mark a variable as reactive, the $: symbol is used.

$: themeLabel = theme === "light" ? "Lights off" : "Lights on";

Reactive lists

Reactivity works also on lists! If I select a different city in the checkbox, the list of restaurants to be displayed is refreshed.

$: restaurantsToShow = restaurants
  .filter((r) => r.address.city === selectedCity)
  .sort((a, b) =>
    a.position[1] > b.position[1] ? 1 : a.position[1] < b.position[1] ? -1 : 0
  );

Conditional classes

Conditional classes can also be used very easily. The div below only gets the class "restaurant-section-dark" assigned if theme is equal to "dark".

<div
  class="restaurant-section"
  class:restaurant-section-dark={theme === "dark"}>
</div>

Performance

The Lighthouse Score of the application is very good without me having done anything special for it (at least in the desktop view). Svelte says about itself:

Svelte compiles your code to tiny, framework-less vanilla JS — your app starts fast and stays fast

Check out the article about the Virtual DOM and why Svelte doesn't use one!

The Lighthouse Report seems to confirm this:

There is still room for improvement in the mobile view. In particular, the dependencies on Leaflet and the loading of the map tiles are noticeable. I'll deal with that another time, all right? But that leads us directly to the section with the improvements I can make in the future!

Future improvements

I have just mentioned it, but I like to say it again.
In the future, I would like to improve the performance on mobile devices. If you have any tips for improvement (especially for Leaflet), I'd definitely appreciate a message from you!

I would also like to add and display more information about the restaurants. For example, I am thinking of photos, ratings and opening hours. So far, there are also only a few restaurants in Hamburg, Berlin and Munich.
But other cities will surely follow. At the latest when I add restaurants from other countries, I will also have to do some internationalisation.

And I quickly finished the project in my spare time between Christmas and New Year 🙈 The code base should therefore still be tidied up and the city coordinates need to be removed from the code. But before I start, I should definitely write a few tests...

If you like you can try out veganmap here. Thanks for reading!

How to solve an everyday problem with Node.js, Gatsby and Netlify

Hendrik Boelcke — Mon, 01 Mar 2021 06:54:41 +0000

I built a random episode generator for audio dramas on Spotify before Netflix did the same for its series 😉. Here I outline the implementation based on Node.js, Gatsby and Netlify.

Motivation

I really love radio dramas, especially Die drei ??? ("Three Investigators"). And I'm not alone with that. The series has now been in production since 1979 and there are now over 200 episodes, live shows, Christmas specials, merchandise, etc. Over fifty million records have been sold so far. So there are a lot of people out there who also like to listen to them as much as I do (or even more).

The Three Investigators books have always been very popular in Germany. They are known there as Die drei ??? (Die drei Fragezeichen, meaning "The Three Question Marks"). Jupiter Jones was renamed as "Justus Jonas", a German adaption of his original name, while Peter Crenshaw is named "Peter Shaw". Bob Andrews retained his original name. The chauffeur's name is Morton.

In 1964 the Random House publishing company and the Kosmos publishing company started to publish the translated 43 original books. In 1979 the German publisher Europa started a radio drama based on those original 43 books. In 1993 Kosmos started to publish new written books by German authors which were and still are continued as radio dramas in Germany. All in all, this would result in a canon of over 200 books (6 books per year, 3 during spring and 3 during autumn) and 201 radio dramas published as…

View on Wikipedia

In addition, of course, there are a variety of other series. TKKG, Fünf Freunde, Point Whitmark, just to name a few. But Die drei ??? is still my all-time favorite. I found a good article on Fluentu.com that will give you an overview of the topic if you're more interested.

Thanks to Spotify I have access to an almost endless number of radio dramas. Nevertheless, it is often difficult to find an episode that fits my mood or situation. That's why I often ask my wife for a random episode ID. Unfortunately, my wife is not a good randomizer. When I ask her for an episode ID, she answers "73!" most of the time 😉. But episode #73 of Die drei ??? is "Poltergeist" which is not a good episode if you want to listen to something relaxing while you try to fall asleep 👻 😱

So, there was only one way out: I had to build my personal random episode generator. I was aware that this one will sometimes make inappropriate suggestions to me, but I was hoping that the poltergeist would be suggested to me less often.

Exploring possible solutions

To be honest, I started this project about two and a half years ago, kept discarding ideas and starting over again. I have gone down many different paths to find a solution that fits my needs. First, I wanted to use Clojure for a small backend application and React to implement the frontend. I also made it to crawl Wikipedia for episode titles and parse that information and fit it into a simple database schema. But after a few days, I lost focus on this rather complicated approach. There was a gap between the episode suggestion and the play button to start playback. Why should I use a suggestion application if I have to type this suggestion into Spotify by hand afterwards? Or even worse: If I would then have to search for the episode for a long time in a CD collection?

Back in 2020 I stumbled over the idea of Jamstack applications ("JAM" means JavaScript, APIs and Markup). Jamstack promises better performance, higher security, cheap and easy scaling and a better developer experience. To explain the principle very briefly: You can use a static site generator like Gatsby.js to create static sites from Markdown, JSON, APIs, etc using React. Afterwards, you can deploy your static HTML, CSS and JavaScript to a provider of your choice, e.g. GitHub pages or Netlify! If you want to learn more about Jamstack there are a lot of resources about it out there!

Thinking about the Jamstack approach and my Spotify account I was approaching a new solution. Fortunately, I found that Spotify provides a comprehensive and well documented API. So, I came up with the idea of developing a web based Jamstack application. It should get the information about the different episodes directly from the Spotify API and provide a button that will play the episode on Spotify without redirection.

Episode importer

But first things first. I had to access the Spotify API in order to fetch episode information and create a random playback button. So, I created a Spotify developer account and generated an API key. With this key in hand, I could use ReST to get information about artists and albums. Artists of interest are stored in a small JSON object including their name and Spotify artist id. Then I have created a small Node.js application that fetches all episodes of every artist from the configuration object. Each sequence was then saved in JSON format. There ain't no magic in this. Just some ReST calls, basic error handling and file I/O.

Later I added some more logic to the application. So now only the latest episodes are retrieved and the episode objects are no longer persisted locally, but in a cloud database.

You can see the source files of random-episode-importer on GitHub.

thr0n / random-episode-importer

Episode frontend

Once I finally had the episodes in JSON format as input (without scraping, woohoo!), it was time to set up Gatsby.js. To get started, I just followed the Gatsby tutorial. In the tutorial you'll will learn everything you need to know to create UI components, add styling, read JSON files as input, access the imported JSON data using GraphQL, automatically create pages from data and much more.

I started with two GraphQL queries: A list of all artists and a list of all episodes grouped by the artist id. Based on this data I created an overview page that shows all artists that have been imported using the episode importer. With a click on an artist, a random episode determined at the time of rendering is displayed. This works with the help of a page generated specifically for the episode, to which the browser gets redirected. To play the episode on Spotify, I just need to click on the displayed cover. Each click on an artist also defines a new random episode for the next run. This mechanism was implemented quite simply using Math.random() 🙈.

Recently, I added an additional page that shows the three latest releases for each artist. This is very handy if you don't want to miss any new releases of your favorite artist! But that's not the only feature that I've added. Additionally, there is an Auth0 login form if you want to access random episode. This was unfortunately necessary from my point of view, because I don't own the rights to the names and cover images I display in the application 😔. All I can give you is my promise that it is a lot of fun to work with the Spotify API (at least if you're a music lover) and build static websites with Gatsby and React.

Here's a small GIF recording of random episode to give you a hint of the look and feel of the application. On the first screen, it shows the artist overview as well as a short info text of random episode's purpose. After that, you can see how clicking on a tile redirects the browser to a random episode for the selected artist:

The source code of random-episode-frontend is also available on GitHub.

thr0n / random-episode-frontend

You can read about random-episode on my blog 🙃

Deployment

If you're looking for a way to host a static website, you'll probably come across Netlify fairly quickly. Netlify simplifies the deployment and hosting of a web application (for example developed with Gatsby, Next.js or plain React, Vue or, Angular) immensely. In the simplest case, Netlify basically only needs access to my Git repository and a suitable build script. Then a push in the repository is enough to execute a build and a subsequent deployment on Netlify. So I don't have to worry about DevOps topics or infrastructure components, I just have to write application code. After deployment, I can reach my app from anywhere there is internet.

I also created a small script that runs the episode importer and triggers a build on Netlify using a POST request. In this way it's possible to read the latest episode data from the cloud database without pushing to GitHub. To do this, I integrated an update mechanism into the Netlify build that reads the latest episodes from the database.

Since I added Auth0 login to random episode the application is for my eyes only (and of course the eyes of my wife). But I can tell you that it's fun to use the app and that it's a good solution to prevent situations I described in the introduction. So please feel free to fork the repository and setup your own random episode generator!

Future improvements

The project isn't quite finished yet. There are a few topics on my to do list I'd like to do in the near future:

Add an unprotected welcome page, so visitors can get an idea of what is going on at random episode
Add TypeScript to the episode importer. In my current customer project we use TypeScript and I don't want to miss it anymore
At the moment I'm using Firebase as cloud database. I've been reading bad things about it a lot lately, so maybe I'll give Back4App a try
Finally, I would like to automate the build and deployment on Netlify so that I can always see all the new episodes on Friday without running my script locally

Are you also working with Gatsby or Netlify? Or have you already used the Spotify API yourself? Or do you have a favorite radio drama series as well? 😉 I would be happy to read about all of these things in the comments!

I hope that you now can't wait to play around with Gatsby, Netlify, or the Spotify API! Thanks for reading!