VS Code, JetBrains IDEs, and Zed installed via Flatpak run sandboxed, so they can't reach the host's podman the way the Devcontainer workflow (or any Podman-based dev setup) expects. org.freedesktop.Sdk.Extension.podman is a community SDK extension (from the same author as this package) that bridges that gap.
flatpak remote-add --if-not-exists francoism90-podman \
https://francoism90.github.io/org.freedesktop.Sdk.Extension.podman/index.flatpakrepo
flatpak install francoism90-podman org.freedesktop.Sdk.Extension.podman
flatpak override --user --env=FLATPAK_ENABLE_SDK_EXT=podman <app-id>
| Editor | <app-id> |
|---|---|
| VSCode | com.visualstudio.code |
| PhpStorm | com.jetbrains.PhpStorm |
| Zed | dev.zed.Zed |
Podman's rootless socket needs to be running and exposed to the sandbox:
systemctl --user enable podman.socket --now
flatpak override --user --filesystem=xdg-run/podman:ro <app-id>
~/.local/bin?Bind-mounting a directory with the host's podman binary into the sandbox doesn't actually work, for reasons beyond Flatpak convention:
newuidmap/newgidmap, /etc/subuid//etc/subgid entries, crun, conmon, slirp4netns/pasta, and cgroup v2 delegation — none of which a plain bind-mounted directory grants inside bubblewrap's sandbox, which is deliberately isolating exactly those things.--filesystem=xdg-run/podman:ro, which exposes only the API socket.The extension instead runs podman fully outside the sandbox as a service and talks to it over that socket — the same model Docker Desktop uses, not a workaround.
If you're talking to a remote Podman host instead of a local rootless socket, set PODMAN_FLATPAK_FORCE_REMOTE=1 to route through podman-remote instead.
This extension is community-maintained, not an official Flatpak or Podman project — upstream rejected including it directly. Use it at your own risk, and check its repo for current VS Code/Zed/PhpStorm-specific configuration.