Dev containers: implement & standardize sandboxed extensions

[nnullcolumn]

Body

What are you proposing?

extensions (language servers, debuggers, themes, etc..) could allow usage sandboxed through dev containers. In the text of https://zed.dev/docs/dev-containers#known-limitations it states extensions are not supported yet, but that the feature is still in development. Separating locally installed extensions from ones which should run sandboxed through containers is something other editors can already do, and is a useful feature.

Why does this matter?

closes #58831. sandboxing extensions is important because:

• supply chain attacks for development environments are prevalent now more than ever
• sandboxing and reproducibility of extension behavior is important. standardizing extension use through containers makes repros a lot simpler
• consequentially, extensions which need to access resources will be doing so in a way that is ergonomic for the place those resources are stored. this should improve dev container performance significantly

Are there any examples or context?

VSCode has dev containers and separates extensions into ui extensions / workspace extensions

• user docs at https://code.visualstudio.com/docs/devcontainers/containers#_managing-extensions
• dev docs at https://code.visualstudio.com/api/advanced-topics/remote-extensions#architecture-and-extension-kinds
• extensions get categorized
  • we should discuss if automatic / extension-defined categorization has merits over general-purpose interfaces or extra user control
  • 
  • 
  • 

Possible approach

it would be nice if extensions could all allow dev containers, although that may be overly optimistic. an alternative approach is to do what vscode does and ask an extension be designed for the workspace or for ui, but it seems more sane to me to find ways to containerize almost any given extension and leave the rest to user configuration if at all possible.

[nnullcolumn]

thinking about it for more than like 5 seconds it definitely has to be allowed on an extension basis, ui integrations (among other things) can't rlly be containerized easily, but i do wonder if there's a more flexible approach (e.g. a user saying they don't need ui features enabled for an extension and to only use features supported by containers)

was very new to zed upon writing this, ui extensions actually seem pretty tame and could probably run on the container too

[insunaa]

Also language servers, MCP servers, etc. These can all go into containers imo. There's a very good reason that I hard block every execution of npm, node, bun, .. and all these other kind of malware applications on my host computer and have the IP subnet of npm blacklisted in my firewall...