Use local containers

[WeeskyBDW]

Problem / Use Case

Adding the support of local containers for codium-devcontainer if dev(s) dont want to use remote ones.

Proposed Solution

An option to use local containers (but maintaining the option to use remote).

Alternatives Considered

Install ssh server on the dev machine to simulate remote environment

Additional Context

Links, prior art, or screenshots.

Also can probably do the PR to add that feature if accepted

[DDorch]

Thanks for this proposal, @WeeskyBDW. Do you mean that it is actually possible to develop inside a container without using SSH Remote? If this is possible, it would simplify this extension a lot. I used this trick with the Open Remote SSH extension only because I don't know how to make Codium directly run inside a container as VSCode does. So if it is possible to do it without SSH Remote, I'm all ears!

[WeeskyBDW]

Afaik the official MS devcontainer extension allow that but idk yet how to do that but if it interest you i will search

[DDorch]

@WeeskyBDW, if you have time for that, I (and many others) would be very grateful. 🙏

[DDorch]

I have ask an IA for which solution can be used for running directly local docker container. Here is its answer:

Got it. If you want a non‑SSH, non‑Microsoft devcontainer experience for Codium‑like IDEs, the only viable path is to build a custom remote authority (your own “remote extension”), because VS Code/Codium will only run the extension host in a container when a remote authority is responsible for it.

There isn’t a lightweight third option that avoids SSH and avoids re‑implementing a remote authority. The official Dev Containers extension works because it is that authority and speaks a private protocol to the server it launches inside the container.

What this means technically

To mimic Dev Containers without SSH:

• You must supply a remote resolver/authority that:
  • Starts the container
  • Copies/launches a server inside it (server.sh, node, etc.)
  • Establishes a transport channel (usually via docker exec + stdio, or a local Unix socket)
  • Exposes files/ports/processes to the IDE

This is more work, but it’s doable. Many alternatives (like SSH) are just shortcuts around that complexity.

A realistic minimal path (still custom)

1. Custom scheme: codium-container://
2. Remote resolver: a local extension that resolves that scheme
3. Transport: use docker exec + a small RPC server inside the container (stdio)
4. VS Code server: start it inside container and connect

If you want, I can help you:

• Design a minimal remote authority architecture
• Identify the smallest subset of capabilities to implement
• Plan a roadmap so you can ship something useful fast

To make this concrete, answer these and I’ll propose a concrete architecture:

1. Which Codium-like IDEs must be supported?
2. Are you OK requiring a helper binary inside the container (small agent)?
3. Is file access required, or are you aiming for “exec + terminal + tasks” first?

[DDorch]

Positron has developed its own DevContainer extension recently: https://github.com/posit-dev/positron/tree/main/extensions/positron-dev-containers.

For the little story, I have developed this extension in the first place because it wasn't available on Positron... and they release their first beta of their extension two weeks before I released this one 😵

Anyway, up to now their extension is buggy on my computer and I continue to use mine but I suppose that as soon as their extension will be stable, I will abandon the development of codium-devcontainer...