DEV Community: Kunal Das

Your AI Agent Can Run `rm -rf /`. Put It in a Sandbox.

Kunal Das — Sun, 25 Oct 2026 14:39:49 +0000

Your AI Agent Can Run `rm -rf /`. Put It in a Sandbox.

Docker Sandboxes is Docker's tool for running AI coding agents inside an isolated microVM on your own machine, managed by a standalone CLI called sbx. It exists because of an uncomfortable default. When you start Claude Code inside a sandbox, it runs with claude --dangerously-skip-permissions as the standard startup command. Not because someone was reckless, but because that is the mode the sandbox is built to make safe (Docker docs, Claude Code agent page).

That flag is the entire problem this post is about. Every coding agent has an equivalent: Codex bypasses approvals, while Cursor, Copilot and Gemini use what their vendors call YOLO mode. The official tutorial is blunt about it. The built-in sandbox integrations start agents "in their full-autonomy mode," and you don't need to add those flags yourself.

Full autonomy is genuinely useful. At the same time, it is exactly the blast radius you would never hand to a shell prompt that answers to a language model. Docker's own launch post for the microVM release puts the trade in one line: "Since they can't harm your computer, let them run free" (Docker blog, January 2026).

In this post:

Why a container is not enough anymore
What actually crosses the trust boundary?
The 10-minute setup
How do you control what the agent can reach?
Which sandbox mode fits your workflow?
FAQ

Key Takeaways

Docker Sandboxes (sbx) runs each coding agent in its own microVM with its own kernel, filesystem, and Docker daemon. The agent gets sudo inside the VM and cannot reach your host outside the files you explicitly share (security model).

Your workspace directory is the exception: a direct mount is read-write, so the agent can still delete your working tree. Use --clone when that matters.

The sbx CLI and local compute are free, including commercial use, and do not require Docker Desktop (pricing).

Network policy defaults matter more than the VM itself: with the Locked Down preset, even your model provider's API is blocked until you allow it.

Why a container is not enough anymore

The usual answer to "my agent is dangerous" is "put it in a container." That answer was reasonable when the dangerous thing was a build script. A coding agent, however, is a different animal, for one reason: it holds a conversation with you, decides what to run next, and keeps going while you are getting coffee.

Two container-era assumptions break down. First, containers share the host kernel. Namespaces and cgroups give you a lot, but a kernel-level isolation boundary is not a hardware-level one. A microVM is a lightweight virtual machine with its own kernel, booted under a hypervisor, which gives the agent a hardware-enforced boundary instead. Docker describes the microVM as the "primary trust boundary" in its security model. The agent has full control inside the VM, including sudo, and the VM boundary is what stops it from reaching anything else.

Second, an agent that can build containers is an agent that wants the Docker socket. This is the part people forget. I wrote about this class of problem in my post on Compose healthchecks: a tool with host Docker access is a tool with root on the host, because docker run -v /:/host is always sitting there. Sandboxes solve it in an unusual way. Each sandbox runs a private Docker daemon inside the VM, so the agent can build images, pull, and run containers to its heart's content, with zero access to your host daemon. Docker claims this is unique among sandboxing options, and I have not found a counterexample (Docker blog, architecture docs).

One sandbox, meanwhile, is a real Linux environment. The agent installs packages, edits files, and starts services. When a run goes sideways, you delete the whole thing and start a fresh one in seconds. That disposal loop, more than any single feature, is what changes how much autonomy you can comfortably grant.

What actually crosses the trust boundary?

This is the part worth internalizing, because "it's sandboxed" is doing a lot of vague work in most conversations. The security model page is unusually specific about what crosses in, what crosses back, and what never crosses at all. I found it the most useful page in the whole docs set, and it is the reason this post exists.

Into the VM:

Your workspace directory, when you run sbx run from a project folder or pass a path. A direct mount is read-write, and the agent's edits land in your working tree in real time. With --clone, the repo is mounted read-only and the agent works on a private clone inside the sandbox. A mountless sandbox shares no host directory at all.
Credentials, but not really. A host-side proxy injects authentication headers into outbound requests. The raw credential values never enter the VM. This is a genuinely clever design: the agent uses your GitHub or Anthropic auth without ever holding the token.
Outbound TCP to allowed destinations, proxied through the host.
A shared skills store, mounted read-only by default at the agent's skills directory.

Back to the host:

Workspace file changes (instant, on direct mounts).
Outbound connections you allowed.
Skill store writes, only if you flipped the skills mount to read-write.

Never:

Your host filesystem outside the workspace and skills store.
Your host Docker daemon.
Your host network interfaces directly. Sandboxes cannot talk to each other over the network. Outbound UDP is blocked unless you turn on an experimental flag, and ICMP is blocked outright.

The one honest caveat, and the reason clone mode exists: a direct mount is read-write. The docs say it plainly. Your project directory is the exception to the sandbox boundary, and the agent can modify or delete its files (tutorial). Andrew Lock's hands-on writeup of running Claude Code this way reached the same conclusion. In his words, the sandbox only has access to your working directory, "so yes, it could delete your git repo," and that is basically the extent of the damage it can do (andrewlock.net). Therefore, keep your work under version control, or use clone mode, or both.

The 10-minute setup

sbx is the standalone CLI that creates and manages sandboxes. It does not require Docker Desktop or Docker Engine on the host, and local sandbox compute is free including for commercial work (install docs, pricing).

Install for your OS. macOS uses Homebrew, Windows uses winget, and Ubuntu installs the docker-sbx package from Docker's apt repository:

$ brew trust docker/tap && brew install docker/tap/sbx        # macOS
$ winget install -h Docker.sbx                                 # Windows
$ curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh      # Ubuntu, repo only
$ sudo apt install docker-sbx

Then sign in once with Docker OAuth:

$ sbx login

Next, start an agent from a project directory:

$ cd ~/my-project
$ sbx run --name my-sandbox claude

The first run pulls the agent template (docker/sandbox-templates:claude-code), which takes a moment. Afterwards, it prompts you to choose a default network policy for all your sandboxes: Open (everything allowed), Balanced (default deny, common dev destinations allowed), or Locked Down (nothing allowed until you say so). The get-started guide recommends Balanced as the starting point.

Claude Code then starts inside the sandbox. If you have a Claude subscription, type /login inside the session. The OAuth token stays on your host and is never stored inside the sandbox. If you use an API key instead, sbx secret set anthropic stores it on the host side where the proxy can use it without exposing it to the agent.

Give the agent a real task. While it runs, open a second terminal and look around:

$ sbx ls
SANDBOX      AGENT    STATUS      PORTS   WORKSPACE      CREATED
my-sandbox   claude   ● running           ~/my-project   2m

That workspace column is the entire filesystem the agent can see of your machine. To drop into a shell inside the VM yourself:

$ sbx exec -it my-sandbox bash

You land in the primary workspace, inside a Linux machine the agent has sudo on. Poke around, run ps, look at what the agent installed. This is the moment the model clicks: it is a computer, not a chroot.

When you are done, the lifecycle commands do what their names say. sbx stop pauses the sandbox and preserves everything inside it across restarts. sbx rm deletes the sandbox and everything in it, while your host working tree stays untouched. Meanwhile, running sbx with no arguments opens an interactive dashboard with live CPU and memory per sandbox, a network panel, and keyboard shortcuts to attach, shell in, stop, or remove.

Replacing claude with codex, copilot, cursor, gemini, opencode, kiro, or droid works the same way. The full supported list is on the agents page, along with a shell agent-less template for manual setup.

How do you control what the agent can reach?

Filesystem isolation is half the story. The other half is network egress, and this is where the preset you picked during first run earns its keep.

Network policy is the allowlist the sandbox applies to outbound connections. Check the rules in effect:

$ sbx policy ls

Allow one more host:

$ sbx policy allow network registry.npmjs.org

The three presets differ in what they block by default, and the differences are the entire security posture of a run:

Preset	Outbound traffic	Model provider API	Good for
Open	Everything allowed	Allowed	Trusted tasks on machines with nothing to protect
Balanced	Denied by default, common dev sites allowed	Allowed	Daily development; the docs' recommended start
Locked Down	Everything blocked	Blocked until allowed	Untrusted or unattended tasks; allow exactly what the job needs

The get-started guide includes a detail I appreciate: with Locked Down, even your model provider's API is blocked until you explicitly allow it. That point is the actual security model in miniature. Locked Down means an agent that goes rogue cannot phone home anywhere, exfiltrate your workspace to a paste site, or quietly download a second stage, unless you allowed that destination. For a task you do not fully trust, the workflow is: locked down, then allow exactly api.anthropic.com (or your provider's endpoint) plus the package registries the task needs, and nothing else. An allowlist you can read in one command beats a permission dialog you learned to click through.

Two related controls are worth knowing. First, secrets, not environment variables: -e VAR=value on sbx run works, but the docs warn that environment variables are readable by processes inside the sandbox, so for API keys sbx secret set keeps the value on the host and has the proxy inject it into outbound requests instead. Second, registry credentials for builds: the sandbox's Docker daemon pulls from Docker Hub using your sbx login session, but for other registries you must store pull credentials first. For example, gh auth token | sbx secret set --registry ghcr.io --password-stdin. Otherwise, private image pulls fail as anonymous.

Which sandbox mode fits your workflow?

The default (sbx run claude from a project directory, read-write mount) is the right choice most days: you watch the agent's edits appear in your working tree as a normal Git diff and commit what you want. The usage guide documents the rest of the toolbox:

--clone mounts your repo read-only and hands the agent a private clone. This is the mode for running several agents against one repository, and the mode for the days you do not trust the diff. The clone lives inside the sandbox; remove the sandbox and the clone is gone.
Mountless sandboxes (sbx create --name scratch claude, no path) share no host directory at all. The agent works in /home/agent/workspace inside the VM, files persist across stops, and sbx cp moves things in and out. Good for experiments you want fully disposable.
--rm makes the whole session a throwaway: the sandbox is deleted the moment the agent exits, and sbx run returns the agent's exit status. This is the CI shape of the tool.
Detached sandboxes (sbx run -d) keep running after your sessions end, which pairs with published ports when the agent is running a service you want to poke at.
sbx move recreates a sandbox's filesystem on Docker-managed cloud infrastructure, or back. This is how a heavy build migrates off your laptop without changing anything about the environment.

That list is also the honest sizing of the tool. Sandboxes are a laptop-and-workstation product with a cloud escape hatch, not a fleet-management layer. What you get locally is the free tier, and it is the part that matters: a hard boundary between "things the agent can ruin" and "everything else."

FAQ

Do I need Docker Desktop to use sbx?

No. The CLI installs standalone and local sandbox compute is free, including for commercial work. Cloud compute is a separate pay-as-you-go subscription, and organization-wide policy governance is a separate paid plan (pricing).

Can the sandbox agent still destroy my code?

Inside a direct mount, yes: the workspace is shared read-write and the agent can delete files there. That is why the docs tell you to keep your work under version control, and why --clone exists when you want the repo protected.

How is this different from just running the agent in a container?

A container shares your host kernel and, if you give it the Docker socket, effectively owns the host. A sandbox is a microVM with its own kernel and its own Docker daemon, so "build and run containers" and "isolate from the host" stop being mutually exclusive.

Can the agent reach the internet?

Only through the network policy you allow. Sandboxes cannot reach your host network directly, cannot talk to each other, outbound UDP is blocked unless you enable an experimental feature, and ICMP is blocked.

Where do my API keys live?

On the host. A proxy injects credentials into outbound requests, and the raw values never enter the VM. Environment variables, by contrast, are readable inside the sandbox, so use secrets for anything sensitive.

The five commands that matter

Install, log in, run, inspect, delete: brew install docker/tap/sbx (or your OS equivalent), sbx login, sbx run claude, sbx ls, sbx rm my-sandbox. Everything else in this post is nuance on top of that loop.

The trade you are making is explicit now instead of implied. The agent runs at full autonomy, with sudo, on a machine it cannot escape, that you can delete with one command when the run goes wrong. The alternative is a permission prompt you have trained yourself to approve without reading, on a machine that has your SSH keys on it. I know which one I let run overnight.

Verified against docs.docker.com (Sandboxes overview, install, get-started, usage, security model, architecture, agents, Claude Code agent page), the Docker Sandboxes product page, and the Docker launch blog post, all retrieved 2026-10-25. Every factual claim links to its source. I did not run the walkthrough on this machine; instead, each claim traces to the linked documentation, and I flag anything I could not verify.

Sources

Every claim above traces to these primary sources. Where I could not verify something hands-on, the post says so.

About the author

Kunal Das writes operations engineering notes as he learns them, always against primary sources. Contact: GitHub and Dev.to. Follow the Docker tag for the next posts in this series.

Docker Compose healthchecks: make depends_on actually wait for Postgres

Kunal Das — Sun, 25 Oct 2026 12:59:08 +0000

Docker Compose healthchecks: make depends_on actually wait for Postgres

Docker Compose is a tool for defining and running multi-container applications with one YAML file. Its depends_on field is the most misunderstood keyword in that file. If your Compose stack has a bare depends_on: list in front of Postgres, your app has never actually waited for the database.

Here is the fix, in three parts: the healthcheck plus condition: service_healthy setup, the socket trap that makes naive Postgres probes lie, and the two failure modes the gate hides.

In this post:

What does depends_on actually guarantee?
How do you wire the gate?
Where does the socket trap bite?
What are the two failure modes the gate hides?

You bring a stack up cold. The database container starts, the app container starts a beat later, and the app tries to open a connection before Postgres is finished initializing. The app crashes. This is a known failure class in microservice deployments: when a dependent service is unready, calls to it fail and the app misbehaves until the dependency becomes available (ISSREW 2019, "Avoiding Faults due to Dangling Dependencies by Synchronization in Microservices Applications"). If you set restart: unless-stopped, Compose quietly restarts it a few seconds later, by which point the database happens to be ready, and the stack looks fine. It is not fine. The restart policy papered over a race instead of fixing it, and the same stack can crash-loop the morning the host reboots.

Key Takeaways

The short depends_on list only orders container start and stop. Compose explicitly "does not wait until a container is 'ready', only until it's running" (Docker docs).

Waiting for readiness means a healthcheck on the dependency plus condition: service_healthy in the long depends_on form.

On the official Postgres image, run pg_isready against TCP (-h 127.0.0.1 or the service name), not the default Unix socket, or the probe can pass while the real server is still down (docker-library/postgres issue 146).

The gate is a startup gate, not a monitor. If Postgres dies or restarts later, your app still needs its own retry logic.

What does depends_on actually guarantee?

The short syntax, the one most quick-start guides show, does exactly two things: Compose creates and starts the dependency container before the dependent one, and removes it in reverse order on shutdown. That is the entire contract. The startup order page in the Compose documentation states it plainly: "does not wait until a container is 'ready', only until it's running" (Docker Compose startup-order docs, 2026). For a database, running and ready are different states separated by seconds of work.

The long form adds a condition per dependency, and there are three to choose from in the compose-file services reference:

service_started: identical behavior to the short syntax.
service_healthy: the dependency's healthcheck must report healthy before the dependent service starts. This is the readiness gate.
service_completed_successfully: the dependency must run to completion with exit code 0, which is what you want in front of a one-shot migration job, not in front of a database.

There is a fourth long-form field people miss: restart: true, which makes Compose restart the dependent service when an explicit Compose operation restarts the dependency, so the app re-establishes its connections instead of pointing at a stale database session.

Why does Postgres race ahead of its own readiness?

The official Postgres image does real work between "container running" and "accepting your queries." On a first boot with an empty data directory, the entrypoint script runs initdb to create the cluster. It then starts a temporary Postgres server to set up roles and run anything you mounted into /docker-entrypoint-initdb.d/. Only after that does it stop the temporary server and exec the real one as PID 1.

The detail that matters for healthchecks: that temporary server is started with listen_addresses='', so it listens on the Unix socket only and not on TCP. The image is designed this way on purpose. Back in 2016, yosifkit put it as: "when it is listening on the network port via its non-loopback interface, it is ready to accept connections." During initialization the container is running, Postgres is running, and nothing on the network will answer. From the outside, the container looks started the whole time, which is exactly the state the short depends_on waits for and then stops waiting.

What I actually ran

To check that the fix works the way the docs describe, I tested this with a real cold start on my own host: Docker Compose v5.1.4, a postgres:16-alpine database with a TCP healthcheck, and an alpine app that prints one line after starting. The app declares depends_on: db: condition: service_healthy. From my testing, the sequence below is what actually happened, in this order.

For example, here is the exact output I watched during the cold start.

 Container compose-test-db-1 Starting
 Container compose-test-db-1 Started
 Container compose-test-db-1 Waiting
 Container compose-test-db-1 Healthy
 Container compose-test-app-1 Starting
 Container compose-test-app-1 Started
app-1  | APP-STARTED-WITH-db-healthy

Note the order: the app container is not even created until db reports Healthy. The diagram below is the same flow the output shows, with the gate drawn in.

Before adding the gate, the same file started both containers at once, and the app's very first connection attempt hit connection refused. In my experience, that is the failure most people blame on "the database being slow" before they find out the ordering was never there. The gate removes this specific race; it cannot remove every failure mode, which is the subject of the last sections.

How do you wire the gate?

healthcheck is a container configuration that makes the runtime probe your service at a fixed interval and report its state as starting, healthy, or unhealthy. service_healthy is the depends_on condition that waits for that state. Here is a runnable Compose file with both:

services:
  app:
    build: .
    depends_on:
      db:
        condition: service_healthy
        restart: true
    environment:
      DATABASE_URL: postgres://app:apppassword@db:5432/appdb

  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: apppassword
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s

volumes:
  pgdata:

With this file, docker compose up starts db, probes it every 5 seconds, and does not create the app container until the healthcheck passes. The $$ doubling is Compose escaping: a single $ in a Compose file is interpolated by Compose itself, so $$ is what reaches the shell inside the container as a literal $.

pg_isready is the Postgres client's readiness probe; it exits 0 when the server accepts connections. The five timing knobs below use the defaults from the Dockerfile HEALTHCHECK reference. The Compose healthcheck block works the same way:

interval (default 30s): how often the probe runs once the container is up.
timeout (default 30s): how long one probe may run before it counts as a failure.
retries (default 3): consecutive failures needed to mark the container unhealthy.
start_period (default 0s): grace window where failures don't count toward retries.
start_interval (default 5s): probe cadence during start_period only, needs Docker Engine 25.0 or later.

For a local dev stack, interval: 5s with start_period: 10s is plenty. In CI on a cold runner, or with a big initdb.d directory, give yourself more headroom: start_period: 30s and retries: 10 is a common starting point. Without a start_period, a database that takes 15 seconds to initialize can burn through its failure budget before it ever had a chance — for example, my own cold start took roughly eight seconds across initdb and the temporary server, inside the 10s window.

Where does the socket trap bite?

Copy-paste healthchecks for Postgres usually look like pg_isready -U postgres. That version can report healthy while the real server is still down, because pg_isready inside the container connects to the Unix socket by default, and the temporary initialization server answers on the Unix socket.

The maintainers' guidance is to force TCP. tianon's comment on the long-running readiness issue: "Simply adding -h 127.0.0.1 to the pg_isready command line should be enough to detect readiness correctly." (docker-library/postgres issue #146.) The docker-library healthcheck script does the same thing in a heavier form: it resolves the container's own hostname and connects with psql, explicitly "to not use the local unix socket."

Probe shape	What it detects	When it lies	Best for
`pg_isready -U postgres` (socket)	The Unix socket answers	During init: the temp server answers while the real one is down	Nothing in a multi-container app
`pg_isready -h 127.0.0.1 -U ...` (TCP, loopback)	TCP port 5432 accepts connections	Never on readiness; still blind to init scripts	The default choice
`pg_isready -h db -U ...` (TCP, service name)	The exact address other containers use	Never on readiness; still blind to init scripts	When you want the probe to mirror app traffic
`psql -c "SELECT 1"` (real login)	A role and database actually answer	Can fail for reasons unrelated to readiness (connection limits, `pg_hba.conf`)	When you need objects from `initdb.d` to exist first

One nuance from the same issue threads: pg_isready confirms the server accepts connections. It does not confirm that a role or database created by an init script exists yet. If your app needs objects created in /docker-entrypoint-initdb.d/, a TCP probe says "Postgres is up" while those scripts may still be running.

What are the two failure modes the gate hides?

Adding a readiness gate converts one vague failure (intermittent connection refused) into two specific ones. Knowing both is the difference between a five minute fix and an afternoon of log spelunking.

Failure mode one: "dependency failed to start: container db is unhealthy"

Your healthcheck runs, exhausts its retries, and Compose gives up on the whole chain instead of starting the app against a database it knows is not ready. It looks like the gate broke your stack. It didn't. This is the gate doing its job, loudly, at a point where you would otherwise be reading crash-loop logs from the app.

Debug it in this order:

docker inspect --format '{{json .State.Health}}' <container> — the Engine stores the last few probe results, stdout and stderr included, so you can see the actual command output that failed.
docker compose logs db — the usual suspects: the probe binary does not exist in the image (curl on an image that ships wget), a typo'd user or database name, or timing values too tight for a cold start.
If the error instead says the dependency "didn't complete successfully" or the container never leaves starting, check that the dependency actually defines a healthcheck. condition: service_healthy with no healthcheck defined means the condition can never be satisfied and the dependent service is never created.

Failure mode two: the gate passes, the app still crashes

service_healthy is evaluated once, at startup. It is not a runtime monitor. If Postgres restarts two hours later, or the bridge network hiccups under load, Compose does not restart your app to re-run the gate. The app still needs to handle a connection that drops mid-session.

This one-shot behavior is not unique to Compose. Orchestration research on Kubernetes health monitoring shows that how and how often you probe matters: a 2025 study of poll-based container monitoring found it "requires careful tuning," can erroneously detect failures, and that erroneous detections alone reduced service availability by 4% compared with signal-based monitoring (arXiv:2507.02158). The practical reading for a Compose stack: treat the startup gate as your first line, and build the retry into the application, because nobody re-probes for you later.

The belt-and-braces pattern is a retry with backoff at connection time, something like:

import time

def connect_with_retry(connect, attempts=10, base_delay=1.0):
    for attempt in range(1, attempts + 1):
        try:
            return connect()
        except Exception:
            if attempt == attempts:
                raise
            time.sleep(base_delay * attempt)

The healthcheck removes the common cold-start race. Only the application can ride out a dependency that blips later, after docker compose up has long finished and moved on.

How do you verify the gate works?

Watch the health column during a cold start (the exact sequence is above):

docker compose up -d
docker compose ps

You want to see db sit in a starting health state briefly, flip to healthy, and only then see the app container appear. If app starts at the same moment as db, the condition is not wired: check for a typo in the YAML or a missing healthcheck block on the target service.

Two commands worth memorizing for the moment something goes sideways:

docker inspect --format '{{json .State.Health}}' db
docker compose logs db

And for CI pipelines that need a hard wait without writing your own polling loop, docker compose up --wait blocks until every service with a healthcheck reports healthy or the timeout hits. It is a much cleaner signal than grepping logs for a "ready" string.

FAQ

Why does my app still crash if I copied the healthcheck from a tutorial?
The tutorial probably missed condition: service_healthy in the long depends_on form. Or its probe talks to the Unix socket instead of TCP. Both are covered above; the table in "Where does the socket trap bite?" is the quick checklist.

Does depends_on wait for the database by itself?
No. The short list only orders container startup. Readiness requires a healthcheck plus condition: service_healthy.

Is pg_isready -h 127.0.0.1 enough, or do I need psql?
For "is Postgres accepting connections", pg_isready over TCP is enough and is what the image maintainers recommend. Use a psql login probe only when you also need init scripts to have finished.

Will the healthcheck protect the app if Postgres restarts later?
No. service_healthy runs once at startup. The application needs its own connection retry logic for post-startup failures.

What should I use in CI instead of polling?
docker compose up --wait blocks until healthy services report healthy, which replaces hand-rolled polling loops.

What are the five lines that matter?

Strip the whole article down and this is what ships: a healthcheck on the database that probes TCP readiness, and a depends_on with condition: service_healthy on the app. Everything else is tuning. Start with interval: 5s, retries: 5, start_period: 10s locally, loosen them for CI, and add app-level retries because the gate only protects the startup sequence, not the runtime.

If your current compose file has a bare depends_on: list in front of Postgres, that is the line to change today. It was never waiting for the database, and the first cold boot on a slow disk will be the one that reminds you.

Verified against Docker Compose v5.1.4 and the compose-spec reference on 2026-10-25, and fact-checked against every linked source (docs.docker.com, docker-library/postgres issue #146, the Dockerfile reference and the compose-file reference). I flag anything I could not reproduce.

Sources

Every claim above traces to these primary sources. Where I could not verify something hands-on, the post says so.

About the author

Kunal Das writes operations engineering notes as he learns them, always against primary sources. Contact: GitHub and Dev.to. Follow the Docker tag for the next posts in this series.

DEV Community: Kunal Das

Your AI Agent Can Run `rm -rf /`. Put It in a Sandbox.

Your AI Agent Can Run rm -rf /. Put It in a Sandbox.

Why a container is not enough anymore

What actually crosses the trust boundary?

The 10-minute setup

How do you control what the agent can reach?

Which sandbox mode fits your workflow?

FAQ

Do I need Docker Desktop to use sbx?

Can the sandbox agent still destroy my code?

How is this different from just running the agent in a container?

Can the agent reach the internet?

Where do my API keys live?

The five commands that matter

Sources

About the author

Docker Compose healthchecks: make depends_on actually wait for Postgres

Docker Compose healthchecks: make depends_on actually wait for Postgres

What does depends_on actually guarantee?

Why does Postgres race ahead of its own readiness?

What I actually ran

How do you wire the gate?

Where does the socket trap bite?

What are the two failure modes the gate hides?

Failure mode one: "dependency failed to start: container db is unhealthy"

Failure mode two: the gate passes, the app still crashes

How do you verify the gate works?

FAQ

What are the five lines that matter?

Sources

About the author

Your AI Agent Can Run `rm -rf /`. Put It in a Sandbox.