Old Python environments on Mac: conda, venvs and pyenv versions

If conda is taking up space on your Mac, the space is almost always in two folders inside your conda installation: envs, which holds your environments, and pkgs, the package cache conda builds them from. Anaconda Distribution asks for at least 5 GB before you create a single environment.

The fix is to remove environments you no longer use, in Anaconda Navigator or Anaconda Desktop, and then let conda's own cleanup trim the package cache. Dragging an environment folder to the Trash frees the space but leaves conda with a record of an environment that no longer exists.

The same idea applies to every other kind of Python environment: .venv folders inside projects, environments Poetry and Pipenv keep in central folders, and whole Python versions installed with pyenv or uv. All of them can be made again. What differs is the cost, and whether anything still depends on them.

This post covers environments and Python versions. The download caches of pip, uv and Poetry are a separate topic: they only cost time to refill. For the wider picture, see how to free up disk space on a developer's Mac.

Why conda takes up so much space on a Mac

conda installs everything it manages into one folder, and nearly all the growth happens in two places inside it. Every environment is a full set of packages, and every package version conda has ever downloaded can stay in the cache.

Where does conda keep its files?

Where the folder is depends on which installer you used. Anaconda's own documentation gives the defaults:

Installer	Folder	Environments inside
Anaconda, graphical installer	/opt/anaconda3	/opt/anaconda3/envs
Miniconda, graphical installer	/opt/miniconda3	/opt/miniconda3/envs
Anaconda, command-line installer	~/anaconda3	~/anaconda3/envs
Miniconda, command-line installer	~/miniconda3	~/miniconda3/envs
Miniforge	~/miniforge3	~/miniforge3/envs
Homebrew's miniconda or miniforge, Apple silicon	/opt/homebrew/Caskroom/…/base	base/envs

The package cache is the pkgs folder next to envs in each case. A Mac that has had more than one of these installed over the years can have two or three complete sets.

Settings in a file named .condarc in your home folder can move environments and the cache elsewhere. If the folders above are small but conda clearly isn't, that file is the place to look.

How big are Anaconda, Miniconda and Miniforge?

Anaconda Distribution is the large one. Its system requirements ask for at least 5 GB of disk space to download and install, because it puts Navigator and hundreds of data science and machine learning packages into its base environment.

Miniconda asks for at least 400 MB: it installs conda, Python and little else. Miniforge works the same way with the community conda-forge channel. With either, the size depends on what you install afterwards.

• Anaconda Distribution, minimum5 GB
• Environment with PyTorch1.1 GB · Usually safe
• Environment with MLX0.7 GB · Usually safe
• Miniconda, minimum0.4 GB
• Project environment with Playwright0.2 GB · Usually safe
• One Python version from uv0.1 GB · Usually safe

The Anaconda and Miniconda figures are the minimum disk space Anaconda's system requirements ask for. The rest were measured on one Mac with Apple silicon in October 2026. Environments made by uv share some data with its cache, so removing one can free less than its size.

The pattern on that Mac is typical: the Python inside an environment is small, and the packages decide its size. One machine learning library, such as PyTorch, can be several hundred megabytes on its own.

Why do the envs and pkgs folders look so large together?

Because they share most of their files. conda's documentation explains that the contents of the package cache are hard linked into environments when possible, so the same file appears in both folders while taking space once.

Finder's Get Info doesn't know that. It counts the full size of each folder, so adding up envs and pkgs overstates what conda really uses. This is also why removing an environment can free less than its size: files it shares with the cache stay until the cache is cleaned.

Hard links only work within one volume. If environments and the cache are on different drives, conda copies files instead, and every environment takes its full size.

Why doesn't Storage settings show conda?

System Settings › General › Storage has no category for developer tools' folders. Depending on where they are, conda's folders and your environments are counted under Documents or fall into System Data, which Apple describes as files that don't fit the other categories. The System Data guide explains what else ends up there.

To see the real sizes, select a folder in Finder and choose File › Get Info. The steps are the same in macOS 26 Tahoe and macOS 27.

How to remove conda environments you no longer use

Environments are usually the larger part, and they're also the part you control. Each one exists because someone created it, and nothing removes it automatically.

How do you see all your conda environments?

If you have Anaconda Distribution, open Anaconda Navigator and click Environments in the sidebar. The list shows every environment conda knows, with a search box to filter by name.

The newer Anaconda Desktop app, which needs macOS 13 or later, has an Environments page with a table you can sort by name, number of packages or when each was last updated. Sorting by last updated is the quickest way to spot environments nobody has touched in months.

Without either app, conda keeps its own list in a plain text file, ~/.conda/environments.txt, with the full path of every environment it created, including ones outside the envs folder. In Finder, choose Go › Go to Folder, type ~/.conda and open the file with TextEdit or Quick Look.

How do you delete an environment in Anaconda Navigator?

1. Open Anaconda Navigator and click Environments in the sidebar.
2. Click the environment you want to remove in the list.
3. Click Remove at the bottom of the environments list.
4. Click Remove again to confirm.

Environments you backed up to Anaconda.com are stored separately, in your account settings online. Removing the local copy doesn't remove that backup.

How do you delete one in Anaconda Desktop?

1. Open Anaconda Desktop and click Environments in the sidebar.
2. Click Actions, the button with three dots, beside the environment.
3. Choose Delete, then click Delete again to confirm.

Both apps delete the environment rather than moving it to the Trash, so there's no Put Back. Back it up first if there's any chance you'll want it.

How do you back up an environment before removing it?

Both apps save an environment's recipe as a small .yml file listing its packages. In Navigator, select the environment, click Backup, choose Local drive and click Save. In Anaconda Desktop, click Actions and choose Export.

The file is a few kilobytes, not a copy of the environment. To get the environment back, Navigator's Import button and Anaconda Desktop's Create dialog make it again from the file, downloading its packages.

Why not drag the environment folder to the Trash?

Because conda keeps a register. Anaconda's documentation says plainly that deleting an environment folder with your file browser frees the space but leaves its path listed in environments.txt. conda and Navigator then keep showing an environment that no longer exists.

conda's own remove command deletes the folder and takes it off the list in one step, and that's what Navigator and Anaconda Desktop use. Miniconda and Miniforge don't come with Navigator, so unless you add it, conda's command in Terminal is the only documented way. There's no menu for it.

Can you remove the base environment?

No, not on its own. base is the environment conda itself runs from, so removing it means uninstalling conda. Navigator doesn't even let you clone it, and with Anaconda's protected base installer it's frozen against changes.

If base is what's large, the honest options are to leave it, or to replace Anaconda Distribution with Miniconda or Miniforge and create only the environments you need.

The conda package cache, and what conda's cleanup removes

What's in the pkgs folder?

conda downloads each package into pkgs, unpacks it there and links its files into your environments. Old package versions and the downloaded archives stay after you update or remove environments. The page on the conda package cache has the details and sources.

The folder can't be trimmed by looking inside it. Packages your environments still use and packages nothing uses sit side by side, with similar names and no flag to tell them apart.

What does each conda cleanup option remove?

conda's cleanup is a command with several targets. Its documentation lists what each one removes:

Option	What it removes	Included in "all"?
Index cache	conda's saved copy of channel package lists	Yes
Tarballs	Downloaded package archives	Yes
Packages	Unpacked packages no known environment uses	Yes
Temp files and logs	Leftovers from earlier conda runs	Yes
Force package folders	Every writable package cache, used or not	No

The "all" option is the useful one. It keeps every package an environment still uses, so environments keep working. The force option isn't part of it, and conda's documentation warns that it breaks environments whose packages link back to the cache.

Is it safe to delete the pkgs folder in Finder?

No. Users who emptied it by hand have reported that new environments then failed to install, because conda still expected files it had recorded there. And if any environment's packages were installed as symbolic links back to the cache, conda's documentation warns that those environments break.

conda's cleanup is Safe because it decides what's unused. It costs a download when you next create or update an environment that needs a package it removed.

Does Navigator have a cleanup button?

Anaconda's documentation for Navigator and Anaconda Desktop doesn't describe one for the package cache. conda's cleanup is a command in Terminal, with a dry-run option that shows what it would do without removing anything.

Why does the cleanup free less than the folder's size?

Because of the hard links above. Packages an environment uses stay in pkgs, and their space would stay in the environment anyway. The cleanup frees what only the cache holds.

That's also why order matters. Remove the environments you don't need first, then run the cleanup: packages only those environments used become unused, and the cleanup can take them too.

One more catch from conda's documentation: when it removes unused packages, it doesn't check environments missing from its register. That's another reason to add and remove environments only through conda, Navigator or Anaconda Desktop, so the register stays accurate.

Virtual environments inside your projects

Outside conda, most Python projects keep their packages in a virtual environment: a folder, usually named .venv or venv, next to the project's code. It holds a link to a Python installation and the packages installed for that project.

What is a .venv folder, and who makes it?

Python's own venv module, virtualenv, uv and Poetry all create them. uv puts a project's environment in .venv next to pyproject.toml by default. Poetry and Pipenv do the same when they're set up to keep environments inside the project.

Every one of them contains a small text file, pyvenv.cfg, whose home line names the Python installation the environment was made from. That file is how you tell a virtual environment from an ordinary folder that happens to be called venv.

Is it safe to delete a venv folder?

Yes, with a cost. Python's documentation describes virtual environments as disposable: simple to delete and create again from scratch, never a place for your code. That's why Python virtual environment (.venv) folders are Usually safe in the catalog rather than safe.

The project won't run until you create the environment again and install its packages. If it has a lock file or a requirements file, that's one install. Packages you added by hand and never recorded have to be found and installed again one by one.

What's in the project	What you get back
uv.lock, poetry.lock or Pipfile.lock	The same versions of every package
requirements.txt with versions	The same packages, if the file is up to date
pyproject.toml without a lock file	The project's packages, possibly newer versions
Nothing listing packages	Whatever you remember to install

How do you find all the virtual environments on your Mac?

Finder's search won't do it. Its search doesn't look inside folders whose names start with a dot, so .venv folders and the pyvenv.cfg files inside them never appear in results. On the Mac measured above, a Spotlight search for pyvenv.cfg found none of the environments on its disk.

Instead, go through your projects folder by hand:

1. Open the folder that holds your projects in Finder.
2. Press Shift-Command-Period to show hidden items. Press it again later to hide them.
3. Choose View › as List, then View › Show View Options, and select Calculate all sizes. Click the Size column to put the largest projects first.
4. Open each large project and look for .venv, venv or env folders next to its code.

Where do environments outside your projects live?

Several tools keep environments in one central folder instead of inside each project. These are the defaults on a Mac:

Tool	Where its environments are
Poetry	~/Library/Caches/pypoetry/virtualenvs
Pipenv	~/.local/share/virtualenvs
Hatch	~/Library/Application Support/hatch/env/virtual
virtualenvwrapper	~/.virtualenvs
pipx	~/Library/Application Support/pipx/venvs, or ~/.local/pipx/venvs on older setups
tox	.tox inside each project

pipx is different from the rest: each folder there is a command-line app you installed, not a project's environment. Removing one removes the app, which is why Apps installed with pipx are Review first. A project's .tox folder, by contrast, is Safe: tox makes its test environments again on its next run.

Why do moved projects leave environments behind?

Central environments are tied to the project's path. Pipenv's documentation says it plainly: rename or move the project folder, and Pipenv can't find its environment anymore, creates a new one and leaves the old one behind.

Poetry names each environment after the project followed by a short code and the Python version. Environments for projects you've deleted or stopped using stay in its folder until you remove them. Each is Usually safe: Poetry makes a new one the next time the project installs its packages.

What about environments apps make for themselves?

Some apps and command-line tools create a Python environment for their own use, often in a hidden folder named after the tool in your home folder. On the Mac measured above, two speech tools kept three such environments of 0.7 to 1.1 GB each, full of machine learning libraries.

Those belong to the tool, not to a project. Removing one breaks the tool until it creates the environment again or you reinstall it, so check the tool's documentation first. If the tool also downloaded models, they're usually stored elsewhere, for example in the Hugging Face cache.

Python versions from pyenv and uv

An environment always starts from a Python installation. Tools that install several versions side by side keep every one you've asked for, and an environment made from a version stops working when that version goes.

How does pyenv store Python versions?

pyenv installs each version in its own folder in ~/.pyenv/versions, named after the version, such as 3.12.4. Most versions are built from source on your Mac during installation, which takes a while and needs build tools.

Packages you install while a pyenv version is active go inside that version's folder. Environments made with the pyenv-virtualenv plug-in live there too, in an envs folder, with a shorter link to each in ~/.pyenv/versions. So an old version can be much larger than Python itself.

Which pyenv versions are still in use?

pyenv picks a version from, in order: a setting in the current Terminal session, a .python-version file in the current folder or the nearest folder above it, and finally the global version file in ~/.pyenv. A version none of those names is a candidate.

To check your projects, show hidden items in your projects folder and look for .python-version files; each contains one version number. Then check the pyvenv.cfg of each environment: a home line pointing into ~/.pyenv/versions names a version you can't remove without breaking that environment.

How do you remove a pyenv version?

pyenv's own uninstall command removes versions, and its documentation also says you can simply delete a version's folder. That makes Finder a valid route:

1. In Finder, choose Go › Go to Folder, type ~/.pyenv/versions and press Return.
2. Move the folder of the version you don't need to the Trash.
3. If you used pyenv-virtualenv, move the short links named after that version's environments to the Trash too.
4. Empty the Trash once you've checked your projects still run.

Python versions installed with pyenv are Review first in the catalog because getting one back means building it from source again, and anything installed into it is gone.

Where does uv keep Python versions?

uv downloads Python versions by itself, whenever a project or command asks for one that isn't installed. It keeps each in its own folder in ~/.local/share/uv/python. On the Mac measured above, it also kept a short link for each minor version, such as 3.12, pointing to the newest patch release installed.

These are prebuilt and small: on the Mac measured above, each version took about 60 MB. uv has its own uninstall command for Python versions, with an option to remove every version it manages. There's no app or menu for it.

What happens to environments when a uv version goes?

They stop working. An environment's pyvenv.cfg points at the version it was made from, and uv's documentation notes that environments keep pointing at the old location even when its storage moves. They have to be created again.

On the Mac measured above, the home line of a 1.1 GB environment pointed at uv's Python 3.11 link. Removing uv's 3.11 would have broken it, even though no project folder mentioned 3.11. Python versions installed by uv are Usually safe for that reason: uv downloads the version again, but not the environments built on it.

Which other version managers keep Python?

Manager	Where versions live	How to remove one
pyenv	~/.pyenv/versions	pyenv's uninstall, or the folder in Finder
uv	~/.local/share/uv/python	uv's Python uninstall command
mise	~/.local/share/mise/installs	mise's uninstall or prune
asdf	~/.asdf/installs	asdf's uninstall
python.org installer	/Library/Frameworks/Python.framework	Python's documented uninstall steps

mise tool versions and asdf tool versions hold every language those tools manage, not only Python, so they're best trimmed with the tool's own commands, one version at a time. Their Ruby side is in the post on old Rubies and gems.

Which Python should you never remove?

The python3 in /usr/bin. Python's documentation explains that it belongs to Apple's developer tools, Xcode or the Command Line Tools, and says never to modify or delete it. macOS protects it anyway.

Homebrew's Python versions are another case: other Homebrew packages often depend on them. Remove them through Homebrew, which knows what still needs each one, never by deleting folders.

How to tell which environments a project still uses

The question isn't whether an environment can be made again; nearly all can. It's whether you'll be annoyed when a project you open next month won't run.

Which files tie a project to an environment?

File in the project	What it tells you
.python-version	The Python version pyenv and uv pick for it
pyproject.toml	The Python versions it supports, in requires-python
environment.yml	The conda environment's name and packages
uv.lock, poetry.lock, Pipfile.lock	Exact packages, so its environment can be rebuilt
.venv/pyvenv.cfg	Which Python installation its environment uses

All of these are plain text. Select one in Finder and press the Space bar to read it with Quick Look, without opening an editor.

How do you read a pyvenv.cfg file?

It's a few lines long. The home line is the folder of the Python the environment runs on, and the version line is that Python's version. Environments made by uv add a line with uv's own version.

If home points into ~/.pyenv/versions or ~/.local/share/uv/python, that version must stay for the environment to work. If it points at Homebrew's folder, removing that Python from Homebrew breaks the environment too, which is one more reason to keep a lock file.

How do you match a conda environment to a project?

Look for an environment.yml in the project: its name line is the environment's name in Navigator. Notebooks are less direct, since they record the kernel they last used rather than a path.

When neither helps, the environment's age is the next best clue. Anaconda Desktop shows when each was last updated, and in Finder, the Date Modified of the environment's conda-meta folder changes when packages are installed or removed.

Do removed environments leave anything behind?

A little. If you registered an environment with Jupyter, its kernel stays listed in Jupyter after the environment is gone, and fails to start. User kernels live in ~/Library/Jupyter/kernels, one small folder each, and each folder's kernel.json names the Python it starts.

Moving a dead kernel's folder to the Trash takes it off Jupyter's list. It frees almost nothing; it just keeps the list honest.

A decision table for each environment

Situation	What to do
A finished project with a lock file	Remove its environment; it rebuilds in one install
A project you open every week	Keep it
An environment with hand-installed packages	Back it up or record its packages first
An environment for a tutorial or one-off test	Remove it
A conda environment nothing names	Back it up in Navigator, then remove it
A pyenv or uv version an environment points at	Keep it, or rebuild that environment first

A safe order for clearing old Python environments

What does removing each part cost?

Part	What removing it costs	How it comes back
conda package cache, via conda's cleanup	A download when an environment needs a package	By itself, on the next install
A project's .tox folder	A slower next test run	By itself, when tox runs
A project's .venv	One install, if there's a lock file	You create it again
A conda environment	Its packages, and anything you changed in it	Import from a backup .yml
A uv Python version	Environments made with it	uv downloads it; environments are rebuilt
A pyenv version	A build from source, and packages inside it	You install and build it again

In what order should you clean up?

1. Measure. Check your conda folder, ~/.pyenv, ~/.local/share/uv and your projects folder with Get Info.
2. Back up conda environments you might want again, with Navigator's Backup or Anaconda Desktop's Export.
3. Remove conda environments you don't use, in Navigator or Anaconda Desktop.
4. Run conda's cleanup afterwards, so packages only those environments used can go too.
5. Remove .venv folders from finished projects, in Finder, after checking each has a lock or requirements file.
6. Remove stale central environments in Poetry's and Pipenv's folders.
7. Check pyvenv.cfg files before removing pyenv or uv versions, then remove the versions nothing points at.
8. Run a project or two, then empty the Trash.

Environments removed by conda, and versions removed by pyenv's or uv's own commands, don't go to the Trash. Folders you move to the Trash in Finder still take space until you empty it.

What should you never delete?

• The whole Anaconda, Miniconda or Miniforge folder, unless you mean to uninstall conda with every environment in it.
• The pkgs folder by hand. conda's cleanup knows which packages are in use; Finder doesn't.
• An environment while Jupyter or a script is running from it.
• Apple's Python in /usr/bin, or Homebrew's Python folders.
• Anything a web page tells you to paste into Terminal. Commands that delete files can't be undone, and fake cleanup guides are a known way to install malware.

Will removing old environments make Python faster?

No. It frees disk space and nothing else. Python, conda and your projects run at the same speed, and the first install after a cleanup is slower while packages download again.

The space matters when the disk is nearly full, for example when a macOS update needs room. It's also worth having when a single new machine learning environment wants a gigabyte or two.

How do you keep environments from piling up again?

• Keep environments inside projects. Poetry's virtualenvs.in-project setting and Pipenv's PIPENV_VENV_IN_PROJECT both put them in .venv, so deleting a project takes its environment with it.
• Commit a lock file in every project, so any environment is one install away.
• If you only use conda for a few environments, start from Miniconda or Miniforge. Miniconda asks for 400 MB to install, against Anaconda Distribution's 5 GB.
• Remove a conda environment when you finish the work it was made for, and run conda's cleanup now and then.
• After a new Python release, remove the oldest pyenv or uv version once no environment points at it.
• Exclude your projects' environments from Time Machine in System Settings › General › Time Machine, by clicking Options. They can be rebuilt, so backing them up only fills the backup disk.

How the app does it

Wombit explains these folders like everything else on the disk. Select one in the map or the list, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.

Cleanup lists them by level:

• The conda package cache and .tox folders are Safe and start checked.
• Project .venv folders, Poetry's environments and uv's Python versions are Usually safe and wait for you to check them.
• pyenv versions and pipx apps are Review first. mise's and asdf's versions are explained, with the tool's own way to remove them.

Folders go to the Trash, where you can put them back. For conda's package cache, the app runs conda's own cleanup instead, after the review sheet. It leaves every package your environments use, so it frees less than the folder's size, and what it removes can't be put back.

Items no catalog entry explains, such as a conda environment's folder, are never offered for removal. On a Mac with Apple Intelligence, the inspector can give a Best guess at what one is, labelled as a guess. Remove conda environments in Navigator or Anaconda Desktop, as above.

• ~/{miniconda3,miniforge3,anaconda3}/pkgs

  conda package cache

  Packages conda downloaded and unpacked, kept to create and update your environments.

  Safe · Runs conda clean --all --yes

• ~/**/{.venv,venv}

  Python virtual environment (.venv)

  A Python project's virtual environment: its own Python setup with the packages installed for it.

  Usually safe · Moves it to the Trash

• ~/Library/Caches/pypoetry/virtualenvs/*

  Poetry virtual environments

  A virtual environment Poetry created for one of your projects, with the project's installed packages.

  Usually safe · Moves it to the Trash

• ~/.local/share/uv/python/*

  Python versions installed by uv

  A version of Python uv downloaded, used by the projects, tools and environments uv manages.

  Usually safe · Moves it to the Trash

• ~/.pyenv/versions/*

  Python versions installed with pyenv

  A version of Python installed with pyenv, along with the packages installed into it.

  Review first · Moves it to the Trash

Seeing all of this is free. Removing it is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.