Containerizing Claude Code with Podman

2026-03-31T00:00:00+00:00

Photo by Seth Jensen, 2026.

I’ve been experimenting with many different AI tools, and my favorite is Claude Code. It provides the impressive performance of the Opus models without forcing me to use Visual Studio Code (or a fork of it).

IDEs and fancy editors like IntelliJ and VS Code are great, but I often prefer the simplicity and low memory footprint of working directly in the terminal. Claude Code works well with my tmux-centered work environment.

However, I don’t like giving AI agents access to all of my files, and I really don’t like letting them run arbitrary commands in my shell. I’m already pretty cautious about running unvetted code on my machine (I’m looking at you, install.sh files I’m supposed to blindly curl | bash), and the nondeterministic nature of LLMs takes this to the next level. It’s not just data-sniffing closed-source code or malware you need to worry about, it’s the product itself running commands and editing files in ways that, by design, are unique and untested.

Claude Code has a sandbox mode which is supposed to limit filesystem access to the folder it’s run from, but since it’s closed-source (in theory), you can’t verify this isolation. Even in this mode, it can run commands outside the sandboxed folder (in my experience, it asks first, but I wouldn’t count on this).

So, I wrote a little wrapper script to run Claude Code in a Podman container with access only to Claude’s config directory and the working directory you pass to the script. I also let it run with the --dangerously-skip-permissions flag, which I would never do on my host machine (it didn’t take long to find a horror story of a typo in an rm -rf command deleting half of the programs in /Applications on one Redditor’s Mac).

Important security notes

Claude has full access to the folder you pass to this script. That means it can run rm -rf as much as it wants, and you won’t be prompted before it does so, especially when using the --dangerously-skip-permissions flag.

You should only run this script if you don’t mind everything in that folder getting deleted — for example, in a Git repository where everything has been pushed to a remote, or in a sandbox folder — it’s easy to create a copy of your working directory for Claude to play in!

There is no constraint on outward network traffic, so Claude can send data anywhere it wants. If you’re working with sensitive data, you should set up a firewall so it only has access to the necessary Anthropic servers (and perhaps an allowlist you provide). Think carefully about what data you give to powerful AI agents.

Using my claude-container script

Make sure you have Podman and Podman Compose installed (this would also work with Docker & Docker Compose, just replace podman compose with docker compose in the claude-container script)
Clone the repo from my GitHub.
From the cloned folder, run ./claude-container /path/to/working/directory
Optionally, add the script to your PATH. This is what I ran on macOS:
```
ln -s /Users/myuser/repos/claude-container/claude-container /Users/myuser/bin/claude-container
```
You can then run the script from anywhere: claude-container /my/favorite/sandbox

That’s all you need to run it! Keep reading if you’re interested in the technical details.

What the script is doing

The claude-container script is a lightweight wrapper around podman compose, setting a couple of environment variables so the process is as simple as running Claude in the first place.

The compose setup uses bind mounts to give Claude access to the folder you pass, along with your Claude config directory. This means you don’t have to reauthenticate every time, and that session history is shared between containers/your local Claude install.

Podman compose will automatically build the image if it doesn’t exist. If you want to trigger a rebuild, you can run it with the -b flag: claude-container -b /path/to/working/directory.

The first time you run the script, it will ask you if you’re okay bypassing permissions. Because we’re only mounting two directories, this should be much safer than it normally would be (provided you’re smart about which folders you pass).

The Dockerfile

The Dockerfile is based on the one from Claude’s devcontainer docs. I’ve stripped out some development helpers since I’m running Claude directly in the CMD, not using the shell.

I previously copied the working directory into the image, but have since moved to using bind mounts only. If I want to make sure that Claude doesn’t touch any files on my machine, I just create a copy of the working directory to bind mount to the container.

Another important thing I removed from Claude’s devcontainer Dockerfile is the firewall setup with init-firewall.sh. Limiting outgoing traffic is a good idea, but the repos I was working with weren’t sensitive enough for me to spend the time getting this working (especially since it seems you need to run the container with the NET_ADMIN capability, which I don’t understand well enough to be using).

Running this with no firewall is dangerous, but less so than running the agent outside of a container.

No container-ception, unfortunately

At some point, I wanted to give Claude access to a backend dev server (it was running a frontend dev server in the container). But the backend dev server runs in a container itself, so I couldn’t just have Claude spin up the backend dev server in its container.

After trying a few things, my workaround was to connect Claude’s container to the backend container’s Podman network. Once all your containers have been started, find the relevant container network with:

podman network ls

If you’re not sure which is the right network, you can check which containers are connected to a network using podman network inspect <network_name>. To connect Claude to the desired network, run:

podman network connect <relevant container's network> <claude container>

And of course, if this container is connected to something important (like a database), this will allow Claude access to it. Always be careful before letting an LLM have access to data. In my case, this was an empty database for development, so in terms of exposing data to Claude, it was similar to running the backend dev server within the container.

A few notes

Claude won’t have access to some important developer tools in the container (e.g., Playwright). If you want to give it more tools, you could modify the Dockerfile to install them at build time. I tried installing Playwright at first, but found I actually prefer manually testing outside of the container & copying output back to Claude. I appreciate the extra time to slow down, check Claude’s decisions, and catch bugs.

This setup intentionally doesn’t give your container SSH access — I don’t ever want an LLM to have access to my SSH key, and I would suggest thinking very hard before giving it access to any servers. That’s one of the big reasons I don’t want to run Claude on my own machine, especially when using an SSH agent.

I’ve enjoyed developing using Claude Code from within the confines of a single folder. I get the solid code analysis and generation without giving away an excessive amount of data.

Running Ruby in Podman (When rbenv install Fails on Apple Silicon)

2026-01-12T00:00:00+00:00

I recently worked on a legacy Ruby backend app which hadn’t been changed for years. A Ruby development environment used to be provided by DevCamps for this site, but over the years we stopped using Ruby other than this small backend, so we also stopped using camps.

The frontend development now uses its own local dev server, so I decided to do the same for the backend by running the Unicorn server locally. I’m on a MacBook M2, so I should just be able to install rbenv using Homebrew. Easy, right?

Unfortunately not. I had a great deal of trouble getting any version of Ruby to run natively on my MacBook M2, so I eventually resorted to using Podman. You can skip to the end for my solution.

First try: native rbenv

The rbenv installation went just fine:

brew install rbenv ruby-build

And after adding eval "$(rbenv init -)" to my ~/.zshrc file, I tried to install the old version of Ruby:

rbenv install 2.4.10

However, this returned a BUILD FAILED message. Strangely, it also failed with a new version of Ruby (3.3.10). I tried debugging for a while before giving up — I figured this project isn’t worth multiple hours of getting a local Ruby installation to work (despite my obstinate attempts to do so).

Second try: mise

Several people on forums & blogs recommended using mise, a language-agnostic version manager. After installing it with Homebrew, I ran:

mise use --global ruby@2.4.10

This failed too! There was a good explanation, though: older Ruby versions don’t run on ARM processors. Of course, that makes sense. So I just needed to install a newer version from after Apple silicon was supported:

mise use --global ruby@3.3.10

However, this failed as well, just like rbenv:

mise ERROR Failed to install core:ruby@3.3.10:
   0: ~/Library/Caches/mise/ruby/ruby-build/bin/ruby-build exited with non-zero status: exit code 1

I’m sure there is a way to get Ruby running through a version manager on Apple silicon; I found several tutorials claiming you can just run these commands as normal and it’ll work. However, after spending longer than I’d like to admit, I was completely unable to do so despite trying many fixes found online.

This may be a unique problem on my machine, or I may be missing something. But the fact was, I’d waited through about a dozen failed Ruby installs (which take a long time!) and I just needed the app to work now. So I moved to a third option: run Ruby in a container.

Third try: Podman

Podman is a fully open-source containerization system which can run Dockerfiles and docker-compose.yml files. The app is a lightweight Sinatra backend with Unicorn as a server, and I just needed to add CloudFlare Turnstile to reduce bot traffic.

The app uses two main files: unicorn.rb (which holds the configuration for the Unicorn server) and config.ru (which defines and runs the Sinatra app). The command to start the app is pretty simple: bundle exec unicorn -c unicorn.rb config.ru. I also set up two files for the container: Containerfile and container-compose.yml.

Note: Podman does find files named Dockerfile and docker-compose.yml, but here I’m using Podman’s convention of Containerfile and container-compose.yml, which takes precedence if both are present in the folder.

To run this, I just needed to set up the environment in my Containerfile.

`Containerfile`

FROM ruby:2.4.10

WORKDIR /usr/src/app

COPY . .

RUN mkdir -p /var/log && \
 gem i bundler && \
 bundle install

EXPOSE 8080

CMD ["bundle", "exec", "unicorn", "-c", "unicorn.rb", "config.ru"]

It’s a pretty simple setup:

set the working directory
copy files from the source directory into the container
create the log directory defined in unicorn.rb
install bundler
install gems from Gemfile.lock
expose the port defined in unicorn.rb
define the server start command using a CMD instruction

`container-compose.yml`

services:
  backend:
    build:
        context: .
        dockerfile: Containerfile
    volumes:
        - .:/usr/src/app
    ports:
        - "8080:8080"

The volumes section means that changes on the host machine will be propogated to the container (and vice versa). This means you don’t need to rebuild the container when you change the app, instead you can use a change-watching Gem like rerun.

Note: You can run this without a compose file, the compose file just stores the volume & port information so you can run it more easily.
podman run -d --name mybackend -v .:/usr/src/app -p 8080:8080 <image_id>

Minimal `unicorn.rb` configuration file

listen "0.0.0.0:8080"
working_directory "/usr/src/app"

This is simple:

Use 0.0.0.0 to connect to the container’s network interface
Define our listening port
Set the working directory to the same value as in our Containerfile

Note: When we forward port 8080 to our Podman container, that traffic arrives on the container’s network interface, not on its internal loopback (localhost). If your app only listens on localhost, it’s essentially saying “I only accept connections from myself,” so the forwarded traffic gets rejected. By binding to 0.0.0.0, your app listens on all interfaces, which includes the one Podman uses to route external traffic into the container.

Simple `config.ru`

require 'sinatra'
get '/' do
  "Hello from Sinatra in Podman!\n"
end
run Sinatra::Application

This is also very simple:

After importing sinatra, define a GET route for the / location (so this will be accessed from localhost:8080/ on the host machine)

$ podman build .
$ podman run -p 8080:8080 <image-id>

This returned a successful response on my host machine:

$ curl localhost:8080
Hello from Sinatra in Podman!

When the app failed to run, it kept trying to restart until I moved a .env file into place and it worked. That shows that the volume is working correctly.

I’m not a Ruby expert, but with this setup I was able to convert the JavaScript code for Turnstile to Ruby and get it working!

Endless OS: A Linux Distro for Kids

2021-01-20T00:00:00+00:00

Photo by August de Richelieu

In 2020 some of us had to work from home while taking care of the kids ourselves, as most childcare services are temporarily closed due to the COVID-19 pandemic. In this post I won’t complain about the pandemic, but rather share my experience.

I have installed several different Linux distributions for my kids’ desktop computer in the past, but have found it quite difficult to find a balance between strict parental controls and no parental controls at all. Then I came across Endless OS, a Linux distro based on Debian, but with heavy customizations to focus on school from home.

Installation

The installation process was smooth and easy. The install image I chose was quite huge though, at around 16GB. But given we can just use a USB drive as the installation medium nowadays this should not be a big issue. The installer does not seem to give an option to encrypt my hard disk with LUKS during the installation phase.

Endless OS is powered by OSTree (which is defined as “a system for versioning updates of Linux-based operating systems”) and Flatpak. According to the website, “Endless OS uses OSTree, a non-destructive and atomic technique to deploy operating system updates. That means updates can be installed without affecting the running state of the system, making the process safe and robust from environmental factors such as a sudden power loss.”

The default window manager is a customized Gnome.

According to its website, the operating system is free for individuals and non-commercial use up to 500 computers.

Package installation and package updates

We can choose from a couple of ways to install new packages (or update them). You can either use the Control Centre, or (if you want to install remotely) the command line. Although Endless OS is based on Debian, the apt command does not work here. Instead you can use Flatpak, with commands like flatpak install <package name>. Flatpak assists the user when installing a new package. For example, if you just typed the package name half correctly, it will suggest a similar name so that you can choose the correct package’s name.

It’s FOSS has a guide to using Flatpak.

Package control

By default, the OpenSSH service for remote shell login is not enabled. The user needs to enable it through the GUI settings in Sharing->Remote Login.

We can limit the type of applications enabled on Endless OS. For example, we could disable the web browser from the Control Centre, while maintaining use of the other apps. The default administrative level user in Endless OS is administrator, with sudo privileges. In other words, the “administrator” user is included in the “sudo” group. However, you could just drop your SSH key in the root account if you insist on using the root login to get into the shell account. I also had to remove the “shared” user account as it does not ask for any password. The kids in the house will have to use the account that I created and assigned to them.

We could disable the browser in the parental control settings, however we could not define where they could/could not go from the settings.

Although Endless OS is unlike other Linux distros, you can fortunately still do your work inside it if you need to using Podman.

Browsing management

I tried to search for similar control for my network, but couldn’t find a good option. My colleague previously wrote about Pi-hole, so I decided to give a try. I found a tutorial on using Pi-hole in a container, and made minor changes from that. As Endless OS ships with podman included, we can use the docker command or adapt it to podman. So I changed the –restart flag to –restart=always and used podman. The rest is similar to the original post.

podman run \
--name=pihole \
-e TZ=Asia/Kuala_Lumpur \
-e WEBPASSWORD=YOURPASS \
-e SERVERIP=YOUR.SERVER.IP \
-v pihole:/etc/pihole \
-v dnsmasq:/etc/dnsmasq.d \
-p 80:80 \
-p 53:53/tcp \
-p 53:53/udp \
--restart=always \
pihole/pihole

We can then browse Pi-hole’s admin page by going to http://<server>/admin.

Conclusion

I like Endless OS for my kid’s usage, however I think the distro needs a lot of help from the community to make it appealing to working adults too. I previously found that I could not install the curl package with flatpak (and I could not use apt to install it). So I built curl with a manifest file from here.

The things I love about this distro are browser management and flatpak for installing the latest software/games from flathub. There may be more points I like as I use it more and more. As for now, the current offerings are already enough. Maybe what I need is a screen time management and an internal URL blocking manager rather than installing an external application.

These are my main observations of Endless OS after a few weeks of usage on my kid’s computer. If you have also used it and have any useful information to add, please leave a comment below.