Use an IDE

A workbench is a full Linux dev container. You can attach your desktop IDE to it and work as usual - editor, IntelliSense, debugger, refactoring, AI assistants - except everything runs inside the container, against its code, language runtimes, tools and services. Your host stays clean.

New to Monoceros? Start with Installation.

Why attach an IDE

• The IDE runs on the container, not your host. Extensions, language servers and debuggers see the container’s toolchain and the mounted workspace - no “works on my machine” gap between editor and runtime.
• Reproducible. The container is derived from the yml; the editor just connects to it. Nothing about your setup leaks into the container, and the container doesn’t pollute your host.
• More than a shell. monoceros shell gives you a terminal; attaching an IDE gives you the full graphical editor on the same container.
• Local, not cloud. No SaaS, no remote VM - the container is on your machine.

Officially supported IDEs

VS Code Dev Containers extension (native) or SSH attach.

VS Codium SSH attach via the Open Remote - SSH extension.

JetBrains IntelliJ, WebStorm, PyCharm & co. via the Toolbox App over SSH.

Claude Code The Claude Code desktop app, via its Connect to SSH host feature.

Hit a snag? See the IDE FAQ.

The two ways an editor connects

Every supported editor reaches the container one of two ways. The per-IDE pages tell you exactly which to use; this is the mental model.

Dev Containers (VS Code only)

VS Code’s Dev Containers extension talks to Docker directly: it opens (or attaches to) the container from the devcontainer.json Monoceros generates. No SSH involved. It is the most native path for VS Code and works on Windows/WSL out of the box. VS Codium can’t use it (the extension isn’t on Open VSX), and JetBrains has its own model.

SSH attach (every editor)

The runtime image runs an SSH server inside the container. monoceros apply wires it up with zero configuration: it mints a per-container key and adds an SSH host named monoceros-<name> to your ~/.ssh/config. Then any SSH-capable editor - and a plain terminal - attaches to it:

ssh monoceros-acme

The transport is portless (it tunnels through Docker), so nothing is published to the host network. On Windows, where the CLI runs in WSL but the editor runs on Windows, apply also writes the Windows-side SSH config automatically - so Windows editors resolve monoceros-<name> too, with nothing to set up by hand.

Tip

monoceros open <name> <tool> is the shortcut: it launches the editor already pointed at the running container. See each editor’s page for the exact tool value.

Prerequisites (all IDEs)

• Docker is running.
• The workbench is applied and up: monoceros apply <name> (check with monoceros status <name>).
• The editor is installed, plus the connection extension named on its page.

Does my IDE state survive a rebuild?

Yes. Installed extensions, settings and indexes are kept across a monoceros apply rebuild (per IDE). JetBrains additionally shares its multi-GB backend across all your containers, so it downloads only once. Details on each editor’s page.