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 ?

[ai]

Try new Zed preview. They just recently fixed some bugs with custom Dev Container Rust implementation for devcontainer.json with custom Dockerfile as you have.

[Pioneer-1-1]

@blue42u just tried it. dev container creation still failed. I got the error message:

2026-04-17T23:45:34+01:00 INFO  [dev_container::devcontainer_api] find_configs_in_snapshot: Found 1 configurations
2026-04-17T23:45:34+01:00 INFO  [recent_projects::remote_servers] SSH: Watching User Config at: "/home/user/.ssh/config"
2026-04-17T23:45:34+01:00 INFO  [recent_projects::remote_servers] SSH: Watching Global Config at: "/etc/ssh/ssh_config"
2026-04-17T23:45:34+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-17T23:45:34+01:00 WARN  [dev_container::devcontainer_manifest] No initialize command found
2026-04-17T23:45:41+01:00 ERROR [dev_container::devcontainer_manifest] docker buildx build failed: Error: building at STEP "COPY --from=dev_containers_feature_content_source ./devcontainer-features.builtin.env /tmp/build-features/": checking on sources under "/tmp/devcontainer-zed/container-features-1776465940197": error in copier subprocess: changing to intended-new-root directory "/tmp/devcontainer-zed/container-features-1776465940197": chdir /tmp/devcontainer-zed/container-features-1776465940197: no such file or directory


2026-04-17T23:45:41+01:00 ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

[Pioneer-1-1]

@blue42u actually this may be unrelated I've tried to run dev containers with the latest build of zed flatpak the zed-preview flatpak and the version of zed-flatpak I previously used and which worked fine.

Podman is on my system and running just fine (I'm even able use dev containers running using podman on vscodium). However, for some reason whichever one I run when I try to start dev containers I get an error of:

2026-04-18T02:04:41+01:00 INFO  [dev_container::devcontainer_api] find_configs_in_snapshot: Found 1 configurations
2026-04-18T02:04:41+01:00 INFO  [recent_projects::remote_servers] SSH: Watching User Config at: "/home/user/.ssh/config"
2026-04-18T02:04:41+01:00 INFO  [recent_projects::remote_servers] SSH: Watching Global Config at: "/etc/ssh/ssh_config"
2026-04-18T02:04:41+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-18T02:04:41+01:00 WARN  [dev_container::devcontainer_manifest] No initialize command found
2026-04-18T02:04:45+01:00 ERROR [dev_container::devcontainer_manifest] docker buildx build failed: Error: building at STEP "COPY --from=dev_containers_feature_content_source ./devcontainer-features.builtin.env /tmp/build-features/": checking on sources under "/tmp/devcontainer-zed/container-features-1776474284832": error in copier subprocess: changing to intended-new-root directory "/tmp/devcontainer-zed/container-features-1776474284832": chdir /tmp/devcontainer-zed/container-features-1776474284832: no such file or directory


2026-04-18T02:04:45+01:00 ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

[Pioneer-1-1]

As you suggested it appears to be something to do with custom dev containers (though I don't get why that broke the older version which was previously working)

I ran two tests:

1. bare apline container

projects: initialize dev container => search for templates => Apline => 3.22 => (don't select any features) => confirm selection

2. your suggested devcontainer.json

// .devcontainer/devcontainer.json
{ "image": "ubuntu:latest" }

(1) worked (2) didn't

[Pioneer-1-1]

@blue42u I completely uninstalled and reinstalled both podman and zed then attempted to run a dev container using my custom dev container file (see above).

I got the same error of:

2026-04-18T15:59:51+01:00 INFO  [recent_projects::remote_servers] SSH: Watching User Config at: "/home/user/.ssh/config"
2026-04-18T15:59:51+01:00 INFO  [recent_projects::remote_servers] SSH: Watching Global Config at: "/etc/ssh/ssh_config"
2026-04-18T15:59:51+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-18T15:59:51+01:00 WARN  [dev_container::devcontainer_manifest] No initialize command found
2026-04-18T16:07:30+01:00 ERROR [dev_container::devcontainer_manifest] docker buildx build failed: Error: building at STEP "COPY --from=dev_containers_feature_content_source ./devcontainer-features.builtin.env /tmp/build-features/": checking on sources under "/tmp/devcontainer-zed/container-features-1776524400488": error in copier subprocess: changing to intended-new-root directory "/tmp/devcontainer-zed/container-features-1776524400488": chdir /tmp/devcontainer-zed/container-features-1776524400488: no such file or directory


2026-04-18T16:07:30+01:00 ERROR [recent_projects::remote_servers] Failed to start dev container: DevContainerUpFailed("Failed with nested error: CommandFailed(\"podman\")")

However, it took quite a while between starting the dev container build and getting the error and when I check podman desktop a couple of new images have been created

Therefore I believe that the container is starting correctly but that there is some kind of error getting the container up and running. I've run podman version on both my host system (PopOS 24.04) and the zed terminal . The host system gives:

Client:       Podman Engine
Version:      4.9.3
API Version:  4.9.3
Go Version:   go1.22.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

whereas running within the zed flatpak gives. From a bit of searching it appears that podman 4.9.3 is bundled with a lot of distros (apparently ubuntu and debian ship with it 4.9.3 and RHEL ships with 4.9.4) So I suspect there may be some kind of a conflict going on between the podman 5.8.1 installed in the flatpak and the older version installed on the host system

sh-5.3$ podman version
Client:       Podman Engine
Version:      5.8.1
API Version:  5.8.1
Go Version:   go1.26.2
Git Commit:   c6077f645788743258a1a749f8005b4fb3cbe533
Built:        Fri Nov 11 11:11:11 2011
OS/Arch:      linux/amd64

Server:       Podman Engine
Version:      4.9.3
API Version:  4.9.3
Go Version:   go1.22.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

What I can't work out is why I was able to get this to work with previous builds of this PR but now can't make it work with any of them.

[Pioneer-1-1]

I tried adding /tmp to the flatpak permissions for both the zed and zed preview flatpaks (both with the latest version of this pr). In both it allowed me to build the dev containers. I'm afraid I don't know why this works I just got advice to try it in the past and tried it again. But it does.

[blue42u]

@Pioneer-1-1 This is a bit of a shot in the dark, but can you check the output of which -a podman as a oneshot task in Zed? This should have /app/bin/podman as the first entry. If it doesn't, can you then try starting Zed as:

flatpak run --nofilesystem=home --filesystem=$(realpath <your project dir>) dev.zed.Zed

and see if things suddenly work then?

Basically I suspect that your ~/.profile or ~/.bashrc is somehow injecting a podman on the PATH based on host-spawn. Since Zed writes the Dev Container build files to /tmp, a podman command on the host wouldn't be able to see the files Zed wrote to the sandbox's /tmp. Unless of course you add /tmp to the Flatpak permissions.

Again, this is shot in the dark, app-sh is (supposed to) directly combat such a conflict and seemed to help before, so I'm not sure why this build is any different.

[Pioneer-1-1]

It does have /app/bin/podman but strangely it's got two of them

I checked with both tmp permission and without tmp permission and got the same result I opened up one of my projects with flatpak run --nofilesystem=home --filesystem=/home/user/Code/Uni\ Work\ \(new\)/DSO/ dev.zed.Zed and tried to launch it but got the same error as before.

However, I did find that when running without the \tmp permission while I can't create new dev containers (at least custom ones) I can open existing ones e.g. I have an existing devcontainer for my turbulence project and I can open and run that just fine.

Wish I could be more help but this one's thrown me through a loop.

Thanks,

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[blue42u]

@Pioneer-1-1 I finally figured your crash out, TL;DR it's an anti-feature in Podman until 5.6.0 (containers/podman#23433). Before that version, any extra --build-contexts passed to podman build are referenced from the host instead of being transferred across the remote connection (which is how the Podman CLI exits the Flatpak sandbox here).

The workaround is to grant --filesystem=/tmp as you've been doing, or more specifically --filesystem=/tmp/devcontainer-zed:create should be sufficient. For now I haven't baked that grant as a default permission since I can't test it, but if it works and maintainers prefer it baked I'm happy to oblige.

[flathubbot]

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

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

Built for aarch64 and x86_64 architectures.

[Pioneer-1-1]

@Pioneer-1-1 I finally figured your crash out, TL;DR it's an anti-feature in Podman until 5.6.0 (containers/podman#23433). Before that version, any extra --build-contexts passed to podman build are referenced from the host instead of being transferred across the remote connection (which is how the Podman CLI exits the Flatpak sandbox here).

The workaround is to grant --filesystem=/tmp as you've been doing, or more specifically --filesystem=/tmp/devcontainer-zed:create should be sufficient. For now I haven't baked that grant as a default permission since I can't test it, but if it works and maintainers prefer it baked I'm happy to oblige.

Thank, I added your permission and it worked a treat.

I checked and ubuntu 26.04LTS is (out tomorrow) is shipping with podman 5.7, fedora 44 has podman 5.8. It'll probably be a few months until all the ubuntu based distros (popOS, mint, e.t.c...) are on the 26.04 kernel but after that it should be fixed for everyone but debian users (debian 13 "trixie" ships with podman 5.3.1 and debian 14 won't release for at least another year, maybe two).

I'm currently on popOS24.04LTS but I'm probably going to switch back to fedora once I get some time (COSMIC is a cool desktop and not having to sod around setting up nvidia drivers sounded good but right now they're calling it a "stable" release and it's as buggy as an alpha, maybe even a beta)

[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/277592/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/277638/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/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.