Deleting a conda environment is one command: conda remove —name myenv —all. You must deactivate it first, and if you were expecting a large amount of disk space back, you will be disappointed — the packages live in a shared cache that the removal does not touch.
That second half is the part nobody mentions. People delete four environments, check df, find they have recovered almost nothing, and conclude the deletion silently failed. It did not. Conda hard-links packages from a central cache into each environment, so removing the environment removes the links, not the files.
Table of contents
- The command, and the deactivate that has to come first
- Why your disk space did not come back
- Cleaning selectively
- Recreating what you deleted
- When deleting is the actual fix
- The same problem on a deployed service
- How this fits the rest of the stack
- FAQ
The command, and the deactivate that has to come first
Two forms do the same thing:
conda remove --name myenv --all
# or
conda env remove --name myenvThe —all flag on the first form is not optional. Without it, conda interprets the command as removing named packages from the environment and, given no package names, does nothing useful.
If the environment is currently active, deactivate it first:
conda deactivate
conda remove --name myenv --allRemoving an active environment fails on Windows because files are locked, and on Linux and macOS it can appear to succeed while leaving your shell pointing at paths that no longer exist. Deactivating first avoids both.
To remove by path rather than by name — which is what you need for environments created with —prefix:
conda remove --prefix /path/to/envs/myenv --allConfirm it is gone with conda env list. The environment should no longer appear.
Why your disk space did not come back
Conda keeps downloaded packages in a package cache, typically under the pkgs directory of your installation. When an environment is created, conda hard-links files from that cache into the environment rather than copying them.
The consequence: five environments that all use numpy share one copy of numpy on disk. Deleting one environment removes its links and frees essentially nothing, because the underlying file still has links from the cache and from the other four environments.
To actually reclaim space you clean the cache:
conda clean --allThat removes cached package tarballs, unused packages, index caches, and temporary files. It is safe — anything it deletes can be re-downloaded — but it means the next environment you create fetches from the network instead of the cache, so the next create is slower.
For a preview before committing, conda clean —dry-run —all lists what would go without removing anything. Worth running the first time so the number is not a surprise.
Cleaning selectively
conda clean —all is a blunt instrument. The finer-grained flags are more useful day to day:
conda clean --tarballs— removes the compressed downloads but keeps the extracted packages. This is the safe default; extracted packages are what new environments link against, and tarballs are pure archive.conda clean --packages— removes extracted packages no environment currently uses. Bigger win, slower next install.conda clean --index-cache— removes the channel metadata cache. Small, but worth clearing if conda is resolving strangely or reporting packages that do not exist.conda clean --logfiles— removes log files, which is usually trivial in size.
Starting with —tarballs recovers a surprising amount on a machine that has been building environments for a year, and costs nothing in future install speed.
Recreating what you deleted
The reason to be relaxed about deleting environments is that a good environment is reproducible from a file. Export before you delete:
conda env export --name myenv > environment.ymlThat captures everything including transitive dependencies and exact builds, which makes it precise and also platform-specific — an environment.yml exported on macOS often will not solve on Linux.
For something portable, export only what you asked for:
conda env export --from-history --name myenv > environment.ymlThis records only the packages you explicitly installed, letting the solver pick appropriate builds on whatever platform recreates it. That is the version to commit to a repository. Recreate with conda env create -f environment.yml.
The habit worth forming: if an environment does not have a committed environment.yml, deleting it loses information. If it does, deleting it is free and you should do it more often.
When deleting is the actual fix
A surprising share of conda problems are best solved by deleting the environment rather than repairing it.
- The solver hangs for minutes and fails. Environments accumulate pinned versions and mixed channels until no solution exists. Recreating from —from-history usually resolves in seconds.
- Mixed conda and pip installs have broken something. pip installing into a conda environment writes files conda does not track, and the two package managers disagree about what is present. This is very hard to untangle and trivial to fix by recreating.
- An import fails with a binary incompatibility. Usually a package built against a different version of a shared library than the one now present. Rebuilding the environment gets a consistent set.
The general shape: conda environments are cheap and disposable if you have the yml file, and expensive to debug if you treat them as precious. Treat them as build artifacts.
The same problem on a deployed service
Locally, a broken environment costs you a rebuild. In production, the equivalent failure is a deploy that works on your machine and not on the server, because the environment was assembled by hand rather than declared in a file.
The fix is the same idea one level up: the dependency set should be a committed file that a build reads, not state that accumulated on a machine. Whether that file is an environment.yml, a requirements.txt with pinned versions, or a lockfile matters less than the fact that recreating the environment from scratch is a normal operation rather than an emergency.
If you can delete the whole thing and get it back identically in two minutes, you have it right.
How this fits the rest of the stack
The reason to keep environments disposable is that it makes the gap between your machine and the server small. A Python service that builds from a committed dependency file behaves the same in both places; one assembled by hand does not, and the difference only shows up at deploy time. Python services on RunxBuild build from the repository, so the dependency file in the repo is the environment that runs — there is no separate manual step to drift. When you are working out what the service and its database cost together, the RunxBuild hosting calculator lays them out as separate line items.
Useful related references:
- Delete Directory Linux: rmdir, rm -rf, and find -delete
- MySQL Delete Database: DROP DATABASE and Recovery Considerations
- Remove Directory Linux Not Empty: rm -rf, find -delete, and Safety
- Services on RunxBuild
FAQ
What is the command to delete a conda environment?
conda remove —name myenv —all, or the equivalent conda env remove —name myenv. Deactivate the environment first with conda deactivate if it is currently active.
Why did deleting a conda environment not free disk space?
Conda hard-links packages from a shared cache into each environment, so removing the environment removes links rather than files. Run conda clean —all to clear the cache and actually reclaim the space.
Is conda clean —all safe?
Yes. Everything it removes can be re-downloaded from the channels. The only cost is that the next environment you create fetches from the network instead of the local cache, making it slower.
How do I delete an environment created with —prefix?
Use the path instead of the name: conda remove —prefix /path/to/envs/myenv —all. Environments created outside the default envs directory do not have a name conda can resolve.
How do I back up an environment before deleting it?
Run conda env export —from-history —name myenv > environment.yml. The —from-history flag records only packages you explicitly installed, which makes the file portable across platforms.