[FEATURE] Support external container runtimes as an alternative to the bundled VM backend

Resolved 💬 1 comment Opened Apr 17, 2026 by glyphVault Closed May 27, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

The desktop app provisions a dedicated VM (claudevm.bundle, ~10GB on disk, ~2GB RAM at runtime) on every launch, even when the host already has virtualization infrastructure running — podman machine, Docker Desktop, OrbStack, Colima, Lima. On macOS this means two VMs competing for Virtualization.framework resources.

Proposed Solution

An opt-in "external runtime" backend that runs Claude's workspace as a container inside a detected, already-running container host.
Detection order, roughly:

podman
Docker Engine / Docker Desktop
OrbStack
Colima / Lima
Fall back to VM for claude

First-launch prompt (or setting toggle): "Detected a running podman machine. Use it to host Claude's workspace?" Keep the bundled VM as the default for users without container tooling — this is an escape hatch, not a replacement.

Alternative Solutions

_No response_

Priority

Low - Nice to have

Feature Category

Other

Use Case Example

I already have a podman machine running, and i imagine many others have similar, so it just makes sense to check and use what is already on the computer.

Additional Context

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗