Not the OP, but it's pretty useful in my team, we all work on the same environment, with the same system dependencies, with no setup required on development machine (except the need for docker).

In the devcontainer you can run code snippets, use the system shell and access an execution environment close to production if well made.

It also allows to avoid (system) dependency conflicts between different projects you may work on.

I sometimes work on old PHP applications, some of which require versions as ancient as 5.4 and refuse to run on anything beyond that. They're not only difficult/impossible to install on modern systems, but also make it hard to onboard other people — you have to write a detailed setup document and then waste a couple of hours time for each new system. And then repeat that a few more years down the line.

Why not write that document as a bunch of build instructions instead of free-form text, while also isolating the result from the rest of the system.

Are you talking about the same thing? This sounds like your typical docker/compose dev setup for running the software under development. The "dev container" stuff is more about running your editor stack in a container, like static analysis tools, language servers etc.

In our case, instant on-boarding of devs with no host setup needed. It's a large, complicated repo with a lot of unusual system dependencies. We build a multi-arch base image for all this and then the devcontainer is built on-top. Devcontainer hooks then let us do all the env setup in a consistent, version controlled way. It's been a god send for us and we'll never go back.

I use a devcontainer to run Claude Code on a sandbox with all tools and services installed. That way I can run YOLO mode with some safety.

Why would I do something that’s more work, less secure, and not cross platform?

It's less work and just as secure, but you do you.

I am a big fan of using it when working with somewhat complicated toolchains, especially if they need to be compiled. Cleaning up the file system is as simple as deleting the container and starting a new one. OCaml on windows comes to mind.

It's ideal for open source projects, no need to install a toolchain locally for small changes. I've used it for a POC in Go where nobody has Go installed in my organization. Not that Go is complicated to install, but I wouldn't ask anyone to install a toolchain for a one-off POC.

There's other toolchains that are more involved or conflict with an operating system's pre-installed stuff, like (iirc) Ruby on MacOS.