Uh, yes, VS Code supports devcontainers. Been using it for a while…

We shall see. VS doesn't support devcontainers and never will (it can't). Aspire "supports" devcontainers but doesn't actually work in a devcontainer in practice. Using a devcontainer as designed is unusable in a Windows (or Mac) environment for any real work. The official MS "fix"?... clone the repo again inside the devcontainer. 🤦‍♂️ GitHub Copilot extension in VS is way behind the VSCode extension. Copilot code completions is useless in both. Use the CLI agent tooling instead? Sure, but now forget about VS or DevKit because they don't like files edited outside their purview and crash. So none of the dev tooling they currently have actually work together now. Why would wslc be any different? Don't get me wrong, I love the premise and it would be a huge benefit for us at work if MS actually creates a cohesive ecosystem. It would not surprise me if it took their tooling a long time to catch up if at all. They are doing a lot of cool innovative things at a fast pace, but disjointedly with the left hand not talking to the right. I don't need a pink theme or a kitten walking across my screen in Visual Studio or a GUI on top of OpenClaw. I need my dev tools to work without all the friction. Each of their tools solves a real pain point in a dev workflow, but together, make the workflow more painful. I've had to scrap most of it be productive.

But how long wltill it work with the rest of MS dev tooling? Aspire? VS? VSCode? Devcontainers?

Beatorajaの開発環境をDevContainersに移行

And maybe github.com/apple/container on Mac? Oh and easier Devcontainers support: I want to run my apps in containers, with non conflicting ports

devcontainers for the win

It’s such a good (and awaited) feature! I even got them working in DevContainers

I also do a lot with devcontainers, so even on Windows, Visual Studio isn't an option for my workflows.

人間関係リセット癖持ちだから数ヶ月起動してなかった Windows マシンとか OrbStack で立てた DevContainers とかすぐ初期化しちゃう

My main use case is devcontainers with an editor such as Zed. Perhaps there will be a way to get it to use this new Mac feature instead of docker.

Stop using Docker to sandbox AI agents. Most people are protecting the wrong thing. Docker and devcontainers strip away a lot of what makes an agent useful. Auth has to be forwarded, API keys end up in environment variables, updating means rebuilding images, and everything still shares the same kernel. VMs give stronger isolation, but every task starts from a blank slate. You lose the local context sitting on your machine and pay a cold start penalty every time. firejail and seccomp help, until the agent needs to install packages, run build tools, or do anything outside a carefully curated syscall list. Then there are approval prompts. They work for a single agent. Once you have ten agents running in parallel, everybody eventually clicks "allow all" and moves on with their day. The assumption behind all of these approaches is that the agent needs the sandbox. I think the code needs the sandbox. The agent is something you chose, configured, authenticated, and connected to your tools. The risky part is the model-generated shell command that just got written five seconds ago. That command might contain a bug, a prompt injection, or something outright hostile. Temenos (github.com/vitalops/temenos) splits the system at exactly that boundary. The agent stays on the host with access to auth, MCP servers, updates, and model APIs. Execution happens inside a rootless gVisor sandbox with its own userspace kernel. The host filesystem only appears where you explicitly mount it. Network access can be switched off with a flag. The separation is enforced by the toolchain itself. Claude starts without Bash, Read, Write, Edit, or any other tool that can directly touch the host. The execution path available to the model goes through the sandbox. That means scaling to fleets of agents without living inside approval dialogs. ⁠``` pip install "temenos[all]" cd ~/code/my-repo temenos claude `` ⁠ Trust the agent. Contain the code it generates. Everything else falls out naturally from that.

Just shipped @rosorg based devcontainer support for the Artemis Mission Simulator 🌕! Check it out: Merged PR: github.com/jasmeet0915/artem… Repo: github.com/jasmeet0915/artem… The project now supports 2 development workflows: 1️⃣ One-click setup with VSCode's devcontainers. 2️⃣ Manually build and run the docker dev container using the helper scripts.

Still dealing with “it works on my machine” in your #IT projects? @JustinWGrote shows how #DevContainers enable: ✅ Reproducibility ✅ #Automation ✅ Portable environments From #Docker to #Podman — define once, run anywhere youtu.be/1Fax3y-AiH4?si=KJPe… #PowerShell #DevOps #PSConfEU

I feel like I'm missing something, are you saying *using* devcontainers burns a whole lot more tokens than without it? Or that it takes a lot of tokens to author a new devcontainer for your project?

I have had some luck, you will definitely burn through tokens though. Currently I align devcontainers with VS Code Tasks as a quick start for repos with a lot of dependencies. Never done work with Nuget though.

Private artifactory feed, DevExpress licensed feed. It feels like devcontainers are only truly usable with zero manually configuration steps, with stuff you could bake into the container image

I'm trying to use devcontainers for the first time on a project that requires private nuget feeds, and it's... difficult to get started. I can't find an easy way to expose the Windows host nuget configuration to the Linux container image. Any tips?

Hardcoded creds & env‑var leaks ➡️ real incidents. This demo shows how Dev Containers PowerShell make secure‑by‑default the easiest path. 👉 Register here: luma.com/5zla238g #DevOps #Azure #CloudSecurity #DevContainers #PowerShell #SecureCoding #CloudCommunity