Description
docker image prune does not remove any images when using a negative label filter (label!=...). The command completes successfully with no errors, but no images are deleted even when they clearly do not match the excluded label.
Removing the filter makes the command behave correctly.
This is a regression or behavior change in Docker 29+.
Reproduce
Docker version 29.3.1
My label is on_prune=keep. It is only part of my custom builds.
docker pull mongo
The label is not in the mongo image
docker image inspect mongo:latest --format '{{json .Config.Labels}}'
{"org.opencontainers.image.version":"24.04"}
Negative filter does not work
docker image list --filter=label!=on_prune=keep
i Info → U In Use
IMAGE ID DISK USAGE CONTENT SIZE EXTRA
Images WITHOUT the custom label are not pruned
docker image prune -a -f --filter=label!=on_prune=keep
Total reclaimed space: 0B
The image mongo:latest should be deleted, since it does not have the label on_prune=keep.
Expected behavior
As in Docker 28.1.1
Negative filter allows to prune all images that DON'T have the label
docker pull mongo
Using default tag: latest
latest: Pulling from library/mongo
689b91d88a0f: Pull complete
db782b49bd71: Pull complete
66e4666e3305: Pull complete
cd5dd782e823: Pull complete
b286261d1310: Pull complete
a7231d1eab25: Pull complete
5283059b6331: Pull complete
2a1aa97b40be: Pull complete
Digest: sha256:f071cbf97a6e52fb7f07ce9ca5d862ad79876bf0eba9ba97758337d740449638
Status: Downloaded newer image for mongo:latest
docker.io/library/mongo:latest
docker image prune -a -f --filter=label!=on_prune=keep
Deleted Images:
untagged: mongo:latest
untagged: mongo@sha256:f071cbf97a6e52fb7f07ce9ca5d862ad79876bf0eba9ba97758337d740449638
deleted: sha256:54f808fc62647d6b9bc5eb991fce8d628e2b2989d032e9df7d85cefa47cd9cc3
deleted: sha256:364489d7c38ce4d80dcbfcd24c65d5a084c0ea8ecad388670c068bd7261f04e9
deleted: sha256:37981eb2f6f6a8dad3e2657479563efc1270cb619bdbd95926589ae2ff1da5ce
deleted: sha256:e3b7ce1db8f32dac3fc23c801ff0974f82eb45c1348c27846ebb6d33d9bb4dfc
deleted: sha256:275d7436e9ff11633a1f4547e97132e72c96365a12cfe3c5f8a2dd88753197e4
deleted: sha256:b767a2f2bdb8af31858d9065f4f398c6568132502aa1f770b7a7358173b2f6b3
deleted: sha256:1ec14ae652349bfed797ba6f242ff0e872ee805bdeea66a0b1484cc742585e46
deleted: sha256:99f80900d6004ed107a97a88471d48056558dce4ee6e527829a9e5e3d7fcfc0a
deleted: sha256:5e732af9e7c568c9b41ecabc76ac93a58471934d5155070dfd64a9567667fd9d
Total reclaimed space: 950.1MB
docker version
docker version
Client: Docker Engine - Community
Version: 29.3.1
API version: 1.54
Go version: go1.25.8
Git commit: c2be9cc
Built: Wed Mar 25 16:13:32 2026
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 29.3.1
API version: 1.54 (minimum version 1.40)
Go version: go1.25.8
Git commit: f78c987
Built: Wed Mar 25 16:13:32 2026
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.2
GitCommit: 301b2dac98f15c27117da5c8af12118a041a31d9
runc:
Version: 1.3.4
GitCommit: v1.3.4-0-gd6d73eb8
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client: Docker Engine - Community
Version: 29.3.1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.33.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v5.1.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 38
Running: 38
Paused: 0
Stopped: 0
Images: 36
Server Version: 29.3.1
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 301b2dac98f15c27117da5c8af12118a041a31d9
runc version: v1.3.4-0-gd6d73eb8
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 5.15.0-173-generic
Operating System: Ubuntu 22.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 29.8GiB
Name: lmio-bat
ID: af576cde-5255-437d-81e5-d20c7f89ebb0
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
::1/128
Live Restore Enabled: false
Firewall Backend: iptablesAdditional Info
This breaks workflows that depend on preserving specific images via labels while pruning all others. The failure is silent, which makes it particularly dangerous in automation.
Description
docker image prune does not remove any images when using a negative label filter (label!=...). The command completes successfully with no errors, but no images are deleted even when they clearly do not match the excluded label.
Removing the filter makes the command behave correctly.
This is a regression or behavior change in Docker 29+.
Reproduce
Docker version 29.3.1
My label is
on_prune=keep. It is only part of my custom builds.docker pull mongoThe label is not in the mongo image
Negative filter does not work
Images WITHOUT the custom label are not pruned
The image mongo:latest should be deleted, since it does not have the label on_prune=keep.
Expected behavior
As in Docker 28.1.1
Negative filter allows to prune all images that DON'T have the label
docker version
docker version Client: Docker Engine - Community Version: 29.3.1 API version: 1.54 Go version: go1.25.8 Git commit: c2be9cc Built: Wed Mar 25 16:13:32 2026 OS/Arch: linux/amd64 Context: default Server: Docker Engine - Community Engine: Version: 29.3.1 API version: 1.54 (minimum version 1.40) Go version: go1.25.8 Git commit: f78c987 Built: Wed Mar 25 16:13:32 2026 OS/Arch: linux/amd64 Experimental: false containerd: Version: v2.2.2 GitCommit: 301b2dac98f15c27117da5c8af12118a041a31d9 runc: Version: 1.3.4 GitCommit: v1.3.4-0-gd6d73eb8 docker-init: Version: 0.19.0 GitCommit: de40ad0docker info
Additional Info
This breaks workflows that depend on preserving specific images via labels while pruning all others. The failure is silent, which makes it particularly dangerous in automation.