Add support for Devcontainers in sandbox mode

[blue42u]

Fixes #336. This is #340 but also installs the docker and podman CLIs, which avoids the "docker CLI not found" errors that otherwise appear when Zed attempts to start a Devcontainer.

This works for me on Bluefin DX, based on Fedora 43. @Pioneer-1-1 @tomaswarynyca @acch can you give this a try?

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/272402/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

[acch]

Thank you very much @blue42u! I gave your version a try:
I can successfully interact with both, docker and podman from within Zed's Terminal. However, I'm still exposed to the leaked LD_LIBRARY_PATH issue (#330 / #334), which prevents Dev Containers from starting:

... ERROR [dev_container::devcontainer_api] Non-success status running devcontainer up for workspace: out: {"outcome":"error","message":"An error occurred setting up the container.","description":"An error occurred setting up the container.","containerId":"ddb7e9f240e4b5750613903d3894ccac85a87cea37f7d673b41813b3d5a5e4ac"}
, err: [...] @devcontainers/cli 0.81.0. Node.js v22.22.0. linux 6.19.10-100.fc42.x86_64 x64.
Shell server terminated (code: 255, signal: null)

podman: /home/.../.local/share/flatpak/app/dev.zed.Zed/x86_64/test/6dae153960bf8b4e08cbe26d34708ab409e2a5e0ae2b2b0a5e654570b8a5e75f/files/lib/libselinux.so.1: no version information available (required by /lib64/libsubid.so.5)
podman: /home/.../.local/share/flatpak/app/dev.zed.Zed/x86_64/test/6dae153960bf8b4e08cbe26d34708ab409e2a5e0ae2b2b0a5e654570b8a5e75f/files/lib/libselinux.so.1: no version information available (required by /lib64/libsemanage.so.2)
Error: cannot run conmon: exit status 127

Error: An error occurred setting up the container.
    at y6 (/home/.../.var/app/dev.zed.Zed/data/zed/devcontainer/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:467:1277)
    at Cx (/home/.../.var/app/dev.zed.Zed/data/zed/devcontainer/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:467:1021)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async P6 (/home/.../.var/app/dev.zed.Zed/data/zed/devcontainer/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:485:3870)
    at async BC (/home/.../.var/app/dev.zed.Zed/data/zed/devcontainer/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:485:4989)
    at async w7 (/home/.../.var/app/dev.zed.Zed/data/zed/devcontainer/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:666:205)
    at async D7 (/home/.../.var/app/dev.zed.Zed/data/zed/devcontainer/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:665:15118)
    at async /home/.../.var/app/dev.zed.Zed/data/zed/devcontainer/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:485:1188

... ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: DevContainer creation failed")
... ERROR [crates/fs/src/fs_watcher.rs:303] Error { kind: Io(Os { code: 22, kind: InvalidInput

[Pioneer-1-1]

doesn't docker collect user data?

If I remember correctly podman doesn't collect user data (podman desktop does though it can be turned off) but I'm pretty sure there are a bunch of closed source bits which collect user data in docker cli.

Personally I wouldn't be a fan of adding a bunch of data collection into the flatpak.

[blue42u]

@acch Just to check, do you have ZED_FLATPAK_NO_ESCAPE=1 set (i.e. sandbox mode)? In sandbox mode I don't see this error, but if I re-enable the sandbox escape I get the same error you do.

FWIW this PR doesn't solve the underlying LD_LIBRARY_PATH leakage issue (#224 / #330 / #334), it just makes Devcontainers work with sandbox mode enabled. I presume sandbox mode was made the new default because it's the current "best" solution for the LD_LIBRARY_PATH problem (#330 (comment)).

---

@Pioneer-1-1 AFAICT according to a quick web search: the Docker CLI is open-source (Apache license). Any telemetry is fully opt-in, and you get full customization on the endpoint (https://docs.docker.com/engine/cli/otel/). This PR also builds it from source so there's full source provenance available.

Some of Docker's other, proprietary products including Docker Desktop do collect data. You don't need any of them to use Zed's Devcontainer support + this PR.

[egerlach]

This version works for me on Aurora 43 (not hugely surprising as it is in the uBlue family).

[Pioneer-1-1]

@Pioneer-1-1 AFAICT according to a quick web search: the Docker CLI is open-source (Apache license). Any telemetry is fully opt-in, and you get full customization on the endpoint (https://docs.docker.com/engine/cli/otel/). This PR also builds it from source so there's full source provenance available.

I checked again and while I can't find anything explicitly stating it it appears you are right and that docker's telemetry is only in the docker desktop application. In that case no objection from me and thanks for the fix.

[Pioneer-1-1]

Works for me on PopOS 24.04LTS

[Hizoul]

Confirmed working on Fedora Silverblue 43.20260407.0 without escaping sandbox.

[alexojegu]

One option would be to add compatibility via an extension; this would allow users who need it to install it without increasing the file size for those who don't, something like:

• https://github.com/flathub/com.visualstudio.code.tool.podman

Or better yet, join forces and create a plugin that works with multiple code editors, if possible.

[Pioneer-1-1]

One option would be to add compatibility via an extension; this would allow users who need it to install it without increasing the file size for those who don't, something like:

• https://github.com/flathub/com.visualstudio.code.tool.podman

Or better yet, join forces and create a plugin that works with multiple code editors, if possible.

I can see the rational, but considering how popular devcontainers are now and that their features are baked in to zed it would seem pretty strange to ship a zed flatpak which can't run them

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/273389/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

[Pioneer-1-1]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/273389/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

I tried the previous build (the first one in this PR which I believe was based on zed v0.230) and that worked fine. However, when I attempted to build a devcontainer with this build it failed.

I suspect the reason for this is that between 0.230 and 0.231 zed switched from the node reference implementation of devcontainers to a native implementation so presumably something about the change has broken dev containers again.

The error I received was:

2026-04-10T16:09:54+01:00 WARN  [fs] Failed to watch /etc/ssh/ssh_config and its parent directory /etc/ssh:
No path was found. about ["/etc/ssh/ssh_config"]
No path was found. about ["/etc/ssh"]
2026-04-10T16:09:54+01:00 WARN  [dev_container::devcontainer_manifest] No initialize command found
2026-04-10T16:10:36+01:00 ERROR [dev_container::command_json] Error running command Command("podman" "inspect" "--format={{json . }}" "fedora:latest"): Error deserializing from raw json: missing field `devcontainer.metadata` at line 1 column 1044
2026-04-10T16:10:36+01:00 ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

[blue42u]

@Pioneer-1-1 I think you're hitting upstream issue zed-industries/zed#52924. I'm running into a similar issue but elsewhere in the deserialization:

... WARN  [fs] Failed to watch /etc/ssh/ssh_config and its parent directory /etc/ssh:
No path was found. about ["/etc/ssh/ssh_config"]
No path was found. about ["/etc/ssh"]
... WARN  [dev_container::devcontainer_manifest] No initialize command found
... ERROR [dev_container::docker] Error deserializing metadata: invalid type: map, expected a sequence at line 1 column 0
... ERROR [dev_container::command_json] Error running command Command("podman" "inspect" "--format={{json . }}" "registry.gitlab.com/hpctoolkit/rtt-images:2.0.0"): Error deserializing from raw json: invalid type: map, expected a sequence at line 1 column 0
... ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

Both seem to be issues with the native devcontainers implementation itself, not the Flatpak sandbox...

[Pioneer-1-1]

@Pioneer-1-1 I think you're hitting upstream issue zed-industries/zed#52924. I'm running into a similar issue but elsewhere in the deserialization:

... WARN  [fs] Failed to watch /etc/ssh/ssh_config and its parent directory /etc/ssh:
No path was found. about ["/etc/ssh/ssh_config"]
No path was found. about ["/etc/ssh"]
... WARN  [dev_container::devcontainer_manifest] No initialize command found
... ERROR [dev_container::docker] Error deserializing metadata: invalid type: map, expected a sequence at line 1 column 0
... ERROR [dev_container::command_json] Error running command Command("podman" "inspect" "--format={{json . }}" "registry.gitlab.com/hpctoolkit/rtt-images:2.0.0"): Error deserializing from raw json: invalid type: map, expected a sequence at line 1 column 0
... ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

Both seem to be issues with the native devcontainers implementation itself, not the Flatpak sandbox...

It's possible it's an upstream error but I don't think it's the one you mentioned. I'm attempting to create a new dev container not launch an existing one.

The WARN [fs] Failed to watch /etc/ssh/ssh_config and its parent directory /etc/ssh issue is also one I've seen when trying to get dev containers to work with the flatpak in the past (i.e. before v0.231) and appears to be an issue related to filesystem access so I suspect this is related to the flatpak implementation rather than zed itself

Have you tried to run a devcontainer with this latest version on your own system?

[Pioneer-1-1]

I had a bit more of a check through the issue you linked (zed-industries/zed#52924) and I'm not almost certain this is unrelated. The errorlog for that issue includes the line:

2026-04-02T00:30:45+05:00 INFO  [recent_projects::remote_servers] SSH: Watching User Config at: "/home/voedipus/.ssh/config"
2026-04-02T00:30:45+05:00 INFO  [recent_projects::remote_servers] SSH: Watching Global Config at: "/etc/ssh/ssh_config" 

Whereas my issue appears to be due to:

... WARN  [fs] Failed to watch /etc/ssh/ssh_config and its parent directory /etc/ssh:
No path was found. about ["/etc/ssh/ssh_config"]
No path was found. about ["/etc/ssh"]

So SSH is succeeding in watching in that issue whereas it fails in mine

[blue42u]

All,

I've copied these changes over to a PR for dev.zed.Zed-Preview (flathub/dev.zed.Zed-Preview#203). The latest preview release (0.232.0-pre) includes a number of devcontainer-related fixes. If you're experiencing errors with this version, please try that version and see if they persist.

[Pioneer-1-1]

All,

I've copied these changes over to a PR for dev.zed.Zed-Preview (flathub/dev.zed.Zed-Preview#203). The latest preview release (0.232.0-pre) includes a number of devcontainer-related fixes. If you're experiencing errors with this version, please try that version and see if they persist.

I replied to your comment over on the preview but TLDR I ran your PR for the preview version and encountered exactly the same issue.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/273980/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

[Pioneer-1-1]

@blue42u you're latest fix works a treat, I can now both create new dev containers and run existing ones thanks.

[napkid]

Thanks for working on this, I too use devcontainers heavily.
I tried the last build on Bluefin (lots of Universal Blue users here BTW !), and it works !

However, I usually use the secrets service integration for registry credentials, and it needs a helper binary (from https://github.com/docker/docker-credential-helpers) that is of course not found in the sandboxed environment.
What could be the best way to handle this kind of issues ?
Docker relies a lot on external binaries to extend it, like the compose CLI plugin, and integrating all of them inside the flatpak does not seem like the best approach IMHO. Should I open another issue for this ?

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/279822/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

[Pioneer-1-1]

@blue42u your latest version ships with the sandbox escape on. That results in the dev container build failing.

You need to disable the flatpak sandbox escape.

[blue42u]

your latest version ships with the sandbox escape on. That results in the dev container build failing.

This is intentional, to match the current state of the sandbox default in master. I don't really want to get into the whole sandbox on/off-by-default debate on this PR, unless maintainers have a different opinion. So yes, right now taking advantage of this fix requires the documented flatpak override from the README.

[Pioneer-1-1]

your latest version ships with the sandbox escape on. That results in the dev container build failing.

This is intentional, to match the current state of the sandbox default in master. I don't really want to get into the whole sandbox on/off-by-default debate on this PR, unless maintainers have a different opinion. So yes, right now taking advantage of this fix requires the documented flatpak override from the README.

Well the whole argument for turning the sandbox off was ease of use.

Therefore, it make little sense to turn the sandbox off in the name of ease of use but then require users to go and check the docs to know to turn the sandbox back on to use dev containers. It achieves the security of sandbox off with the usability of sandbox on; the worst of both worlds.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/285833/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/286680/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

[wallzero]

@flathubbot Can another build be triggered so I can test this?

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/289885/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.

[wallzero]

After a quick glance it works for me with ZED_FLATPAK_NO_ESCAPE=1 and "use_podman": true in the settings.json.

Without sandboxing it doesn't work. It is still able to pull the containers but can't seem to run them. Here's the errors on a fresh install of Fedora Kinoite:

2026-05-30T14:19:52-07:00 INFO  [dev_container::devcontainer_api] find_configs_in_snapshot: Found 1 configurations
2026-05-30T14:19:52-07:00 INFO  [recent_projects::remote_servers] SSH: Watching User Config at: "~/.ssh/config"
2026-05-30T14:19:52-07:00 INFO  [recent_projects::remote_servers] SSH: Watching Global Config at: "/etc/ssh/ssh_config"
2026-05-30T14:19:52-07:00 WARN  [dev_container::devcontainer_manifest] No initialize command found
2026-05-30T14:20:41-07:00 ERROR [dev_container::docker] Non-success result from docker pull: podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsubid.so.5)
podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsemanage.so.2)
Trying to pull localhost/node_j-a955688a66175f03-features:latest...
time="2026-05-30T14:20:37-07:00" level=warning msg="Failed, retrying in 1s ... (1/3). Error: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get \"https://localhost/v2/\": dial tcp [::1]:443: connect: connection refused"
time="2026-05-30T14:20:38-07:00" level=warning msg="Failed, retrying in 1s ... (2/3). Error: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get \"https://localhost/v2/\": dial tcp [::1]:443: connect: connection refused"
time="2026-05-30T14:20:39-07:00" level=warning msg="Failed, retrying in 1s ... (3/3). Error: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get \"https://localhost/v2/\": dial tcp [::1]:443: connect: connection refused"
Error: unable to copy from source docker://localhost/node_j-a955688a66175f03-features:latest: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused

2026-05-30T14:20:45-07:00 ERROR [dev_container::devcontainer_manifest] Non-success status from docker run. StdErr: podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsubid.so.5)
podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsemanage.so.2)
Error: creating container storage: creating an ID-mapped copy of layer "e88f396e182763ca447f810caafee0b7b8b699747116a526ddfc374bf86b8a4e": storage-chown-by-maps: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsubid.so.5)
storage-chown-by-maps: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsemanage.so.2)


2026-05-30T14:20:45-07:00 ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

Thanks for getting this working! I'm excited to use dev containers!

[Pioneer-1-1]

After a quick glance it works for me with ZED_FLATPAK_NO_ESCAPE=1 and "use_podman": true in the settings.json.

Without sandboxing it doesn't work. It is still able to pull the containers but can't seem to run them. Here's the errors on a fresh install of Fedora Kinoite:

2026-05-30T14:19:52-07:00 INFO  [dev_container::devcontainer_api] find_configs_in_snapshot: Found 1 configurations
2026-05-30T14:19:52-07:00 INFO  [recent_projects::remote_servers] SSH: Watching User Config at: "~/.ssh/config"
2026-05-30T14:19:52-07:00 INFO  [recent_projects::remote_servers] SSH: Watching Global Config at: "/etc/ssh/ssh_config"
2026-05-30T14:19:52-07:00 WARN  [dev_container::devcontainer_manifest] No initialize command found
2026-05-30T14:20:41-07:00 ERROR [dev_container::docker] Non-success result from docker pull: podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsubid.so.5)
podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsemanage.so.2)
Trying to pull localhost/node_j-a955688a66175f03-features:latest...
time="2026-05-30T14:20:37-07:00" level=warning msg="Failed, retrying in 1s ... (1/3). Error: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get \"https://localhost/v2/\": dial tcp [::1]:443: connect: connection refused"
time="2026-05-30T14:20:38-07:00" level=warning msg="Failed, retrying in 1s ... (2/3). Error: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get \"https://localhost/v2/\": dial tcp [::1]:443: connect: connection refused"
time="2026-05-30T14:20:39-07:00" level=warning msg="Failed, retrying in 1s ... (3/3). Error: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get \"https://localhost/v2/\": dial tcp [::1]:443: connect: connection refused"
Error: unable to copy from source docker://localhost/node_j-a955688a66175f03-features:latest: initializing source docker://localhost/node_j-a955688a66175f03-features:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused

2026-05-30T14:20:45-07:00 ERROR [dev_container::devcontainer_manifest] Non-success status from docker run. StdErr: podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsubid.so.5)
podman: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsemanage.so.2)
Error: creating container storage: creating an ID-mapped copy of layer "e88f396e182763ca447f810caafee0b7b8b699747116a526ddfc374bf86b8a4e": storage-chown-by-maps: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsubid.so.5)
storage-chown-by-maps: ~/.local/share/flatpak/app/dev.zed.Zed/x86_64/test/aaad149d20296c70002848a4c8d6c6bcec6537d066e9d1db668561c33703c242/files/lib/libselinux.so.1: no version information available (required by /lib64/libsemanage.so.2)


2026-05-30T14:20:45-07:00 ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

Thanks for getting this working! I'm excited to use dev containers!

I ran into the same issue on popOS 24.04LTS from what I understand blue42u isn't too keen on getting into the sandbox on vs sandbox off debate but personally I'm not a fan of the current setup as to my mind having dev containers fail out of the box eliminates the ease of use argument of sandbox off while also providing worse security defaults.

Currently flatpak is a rather bodgey system so it's very impressive that @blue42u has been able to get this to work nicely at all. There is currently a project to create a new version of flatpak with improved functionality, security and rationalise the codebase. Which sounds great, though it will rely on systemd so I'm sure the whole linux community will be fine with that and there will be no controversy whatsoever.

[wallzero]

Are Podman/Docker compose supported for compose devcontainers? I just tried using podman and received the error:

StdErr: Error: looking up compose provider failed

I also can't get devcontainer features to work. I enabled write access to /tmp and see the directories created but I still receive an error:

ERROR [dev_container::devcontainer_manifest] docker buildx build failed: Error: building at STEP "RUN --mount=type=bind,from=dev_containers_feature_content_source,source=./node_0,target=/tmp/build-features-src/node_0 cp -ar /tmp/build-features-src/node_0 /tmp/dev-container-features && chmod -R 0755 /tmp/dev-container-features/node_0 && cd /tmp/dev-container-features/node_0 && chmod +x ./devcontainer-features-install.sh && ./devcontainer-features-install.sh && rm -rf /tmp/dev-container-features/node_0": while running runtime: exit status 1

Seems to be an issue with VSCode flatpak as well.

But I tried Zed without flatpak and was running into the same issue. Then I found this issue in the main repo and the very recent PR to fix it.

Then I tried non-flatpak Zed with podman compose. Turns out Fedora atomic desktops still require podman-compose for podman compose to work: sudo rpm-ostree install docker-compose. After that I still have an error:

Error: executing /usr/bin/podman-compose --project-name devcontainerproject -f ~/project/.devcontainer/docker-compose.yml -f /tmp/devcontainer-zed/docker_compose_runtime.json up -d: exit status 1

It may be related to the /tmp fix PR. Once that is merged I can test podman compose and devcontainer features.

[blue42u]

Are Podman/Docker compose supported for compose devcontainers?

Short version is no, not really. docker-compose should be provided as part of the Flatpak, but the search path is hardcoded to /usr which is part of the org.freedesktop.* runtime(s) and can't be modified here.

Because the Zed Flatpak uses --filesystem=home it might be possible to install docker-compose to ~/.docker/cli-plugins/ as described in https://docs.docker.com/compose/install/linux/#install-the-plugin-manually. If that works for you I'll add a note to the README about it.

I enabled write access to /tmp and see the directories created but I still receive an error:

Assuming this is the same SELinux labeling issue I reported, I worked around it by setting:

# ~/.config/containers/containers.conf
[containers]
label = false

I ran into the same issue on popOS 24.04LTS from what I understand blue42u isn't too keen on getting into the sandbox on vs sandbox off debate but personally I'm not a fan of the current setup as to my mind having dev containers fail out of the box eliminates the ease of use argument of sandbox off while also providing worse security defaults.

I feel the pain, but instead of disabling the sandbox unilaterally and dealing with the resulting backlash, I personally feel the way forward is to get upstream to support running sandboxed. See zed-industries/zed#56435 for one plausible feature that IMHO would help the situation.

[wallzero]

Thanks for the info on docker-compose. I'm having trouble with compose working on the non-flatpak Zed. I'm following the guide. But inside the container I have no /workspaces permissions.

Without compose it works and I can see my project:

drwxr-xr-t.   1 root   root     14 Jun  5 18:17 workspaces

With compose it does not work:

drwxr-xr-x.   1 root   root    162 Jun  4 17:18 workspaces

I'm not sure how to have compose mount the workspaces properly. It seems the only difference is the sticky bit. Until I can get it working there's probably no point in trying further within flatpak.

I'll try your workaround for the SELinux labeling issue next. And when the PR is merged we can try a new build without the workaround.

EDIT:

I tried ~/.config/containers/containers.conf and it did work for non-flatpak Zed. Thank you!

But I still can't get features to work inside flatpak. I am using --filesystem=/tmp/devcontainer-zed:create and I tried adding ~/.var/app/dev.zed.Zed/data/containers/containers.conf and ~/.var/app/dev.zed.Zed/config/containers/containers.conf. If I use non-flatpak to install the features then flatpak Zed can open the completed dev container.

EDIT2:

Your workaround also fixes docker compose and /workspace permissions! So I could try the flatpak zed by installing docker-compose to ~/.docker/cli-plugins/ - but first I need either that PR merged or to figure out why the labelling workaround isn't working.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/295171/dev.zed.Zed.flatpakref

Built for aarch64 and x86_64 architectures.