To uninstall pyenv safely, identify its root and the projects using its Python versions before removing anything. Disabling pyenv's shims, uninstalling one interpreter, and removing the manager are three different jobs—not three names for the same cleanup.

Do not delete a Python executable just because it still appears after removing pyenv. It may belong to Homebrew, Apple's developer tools, or another installation you meant to keep. A changed command path is a reason to identify the owner, not to keep deleting until python3 disappears.

First, record what pyenv actually owns

Run these inspection commands in the Terminal environment where you normally use pyenv. They report configuration and paths; they are not removal commands:

command -v pyenv
type -a python python3 pip pip3
printf 'PYENV_ROOT=%s\n' "${PYENV_ROOT:-not explicitly set}"
pyenv root
pyenv versions
pyenv version
pyenv which python

A missing command or an error is useful information. If pyenv is unavailable, stop before issuing its removal commands and inspect the setup you have. Do not substitute a guessed root.

The pyenv README explains that shims intercept Python commands through PATH. It defines PYENV_ROOT as the directory under which versions and shims reside, with ~/.pyenv as the default.[1] A default is not evidence that your installation uses it. Record the actual result of pyenv root before disabling or removing the command.

Also record the directory where you ran pyenv version. Version selection can depend on a project .python-version file, an environment variable, or the global setting. One shell session outside a project is not an inventory of every project's needs.[1]

If Homebrew is present, inspect its ownership separately:

type -a brew
# Example only: use the absolute executable you identified above.
BREW_BIN=/opt/homebrew/bin/brew
"$BREW_BIN" --prefix
"$BREW_BIN" list --formula

These Homebrew commands identify the active package-manager prefix and installed formulae.[3] A Homebrew installation of pyenv and Python interpreters installed by pyenv are separate layers. A Homebrew python formula is another layer again.

Use the absolute BREW_BIN you inventoried, and confirm its reported prefix before removal. Homebrew's usual Apple Silicon prefix is /opt/homebrew; Intel (including a separate Rosetta installation on Apple Silicon) normally uses /usr/local. These are examples, not a hardware-based instruction to pick one. If both exist, inventory /opt/homebrew/bin/brew and /usr/local/bin/brew separately with --prefix and list --formula, then keep the executable that owns the intended formula. Stop if the prefix differs from the installation you intended. Do not switch to a bare brew command later.[3][4]

Option 1: stop using shims without deleting versions

If the goal is “stop pyenv choosing Python when I type a command,” start with disabling rather than uninstalling. The official disable instructions say to remove the pyenv init invocations from shell startup configuration. The manager remains accessible, but future Python invocations are no longer routed through its initialized shims.[1]

Open the startup files for your actual shell in a text editor. For zsh, pyenv documents ~/.zshrc and possible login-shell entries in ~/.zprofile or ~/.zlogin; Bash setups can use different profile files.[1] Save a backup, then comment out only the pyenv initialization lines you recognize. If you added a shim directory directly to PATH, review that entry too.

Open a fresh Terminal session and repeat type -a python python3 pip pip3. You are checking that shims no longer lead the search path. Do not assume a working python command will remain: your Mac may have a different fallback, or none with that exact name.

This option retains installed versions. It is useful when moving to another workflow while keeping an interpreter available for recovery. It does not reclaim the storage used by those retained installations.

Option 2: remove one installed Python version

If you only need to remove an obsolete interpreter, keep the manager. Choose the exact installed version name from pyenv versions, check its path with pyenv prefix VERSION_NAME, and inspect the projects that select it before removal. Replace VERSION_NAME with the exact entry you intend to remove; it is a placeholder, not something to paste literally.

The documented, scoped removal command is:

pyenv uninstall VERSION_NAME

This removes the selected installation. It is not a Trash operation or a project-migration command. Review the prompt rather than adding a force option. The pyenv documentation also warns that plugins can perform extra uninstall operations: pyenv-virtualenv can remove virtual environments linked to the version being uninstalled.[1]

If another project still needs that version, keep it until you have moved and checked that project. Deleting an interpreter first and discovering its dependencies later reverses the safe order.

Protect project environments before removing their base

Preserving source folders is necessary, but it does not guarantee projects will keep running. Python's venv documentation says an environment is created on top of a base Python installation; its configuration records that base, and its executable can be a copy or a symlink.[2] Removing the base can leave an environment unusable even when the .venv directory is still there.

For each important project, inspect:

  • Its .python-version selection, if present.
  • Its environment's pyvenv.cfg, especially the base installation path.
  • The interpreter selected in the editor, notebooks, scheduled jobs, or build configuration.
  • Dependency manifests and lockfiles, including private or local package references.
  • Uncommitted source, data, and any files mistakenly stored inside an environment directory.

Back up the project and record enough to rebuild its environment before removing the interpreter. Python documents environments as disposable and generally non-portable; copying an old environment folder is not a reliable substitute for recreating it at the intended location.[2]

Create and verify the replacement environment as a separate migration job, using the project's documented tooling. Confirm the application or tests you rely on work with that replacement before removing the old version. A successful python3 --version alone does not prove the project has migrated.

Option 3: remove the manager and its stored versions

The official full-uninstall sequence removes all pyenv shell configuration, then its root directory, then the package-manager installation if applicable. It explicitly warns that removing the root deletes all Python versions installed under its versions directory.[1]

Do these steps in order after project backups and migration checks:

  1. Back up and edit your actual shell startup files. Remove only the identified pyenv configuration: pyenv init, any pyenv virtualenv-init plugin hook, PYENV_ROOT assignments, and pyenv-specific bin/shim PATH entries. Leave unrelated shell configuration alone.
  2. Open a fresh shell; repeat the path checks and confirm the identified shims no longer lead PATH. Do not move the root while startup files still initialize it.
  3. Inspect and then move only the previously recorded root. Moving its interpreters can break virtual environments that depend on them; Trash is not a migration.
  4. Remove a package-manager-owned manager only using its inventoried executable and verified prefix.

Before touching that root, inspect the exact path you recorded. Confirm it is your pyenv data, not a shared directory, unrelated checkout, or custom location containing files you need. This guide deliberately does not provide an unbounded recursive-deletion command. For an ordinary user-owned root, use Finder to inspect and move only the confirmed pyenv directory to Trash after your backups and migrations are complete. Do not empty Trash immediately.

If Homebrew installed the manager, the documented package-removal command is:

"$BREW_BIN" --prefix
"$BREW_BIN" list --formula
"$BREW_BIN" uninstall pyenv

Compare that prefix to your recorded owning prefix and confirm pyenv in that executable's formula list before running the final line. If either check differs, stop. It removes that manager package; do not treat it as proof that every pyenv interpreter, plugin, or shell entry has disappeared.[1][3] If dependency checks refuse removal, stop and review them rather than forcing past them.

For a Git-checkout installation, inspect the recorded checkout and root rather than using Homebrew commands for a package Homebrew does not own. Review plugin initialization and any custom completion entries separately. Leave unrelated Homebrew Python packages and Apple-managed files alone.

Verify the outcome you actually wanted

Open a fresh shell and repeat the path checks. For full manager removal, command -v pyenv should no longer resolve the removed installation. For disabling only, pyenv may still resolve; that is expected. Check your important projects individually for old interpreter references.

If another Python remains, identify it and decide whether it belongs to a separate task. Do not delete anything in Apple's system or developer-tool directories to “finish” a pyenv uninstall. If your real goal was storage cleanup while retaining the runtime, inventory project-local files and interpreter dependencies before choosing a separate cleanup workflow; a generic app uninstall does not replace version-manager ownership checks.

SwoopByte Uninstaller is not released. Its planned toolchain support includes pyenv, with detection and sizes free and removal in Pro. It is not a project-environment migration or backup guarantee. Join the Uninstaller waitlist if that planned review interests you; use the documented workflow above today.

FAQ

Can I disable pyenv without losing its Python versions?

Yes. Removing its initialization from shell startup configuration disables shim-based version switching without deleting the installed versions.[1]

Does Homebrew package removal delete every Python on my Mac?

No. It addresses the Homebrew pyenv package. The official instructions separately address pyenv's root and versions; other Python installations have separate owners.[1]

Will existing virtual environments still work?

Do not assume so. They are based on a particular Python installation and can contain links or absolute interpreter references. Check and recreate affected environments before removing their base.[2]

Why does Python still appear in Terminal afterward?

Your shell may now resolve a different installation. Inspect the path and owner. The existence of another Python is not evidence that the pyenv removal failed.

Is ~/.pyenv always the correct folder to remove?

No. It is the documented default, but PYENV_ROOT can change the location. Record pyenv root and inspect that exact directory first.[1]

Sources

[1] Official source [2] Official source [3] Official source [4] Official upstream documentation/source