conda: command not found? Initialise conda in bash and zsh

bash: conda: command not found (or zsh: command not found: conda) almost never means conda is missing. It usually means conda is installed but your shell was never set up to use it. The terminal installers of Miniconda, Anaconda and Miniforge end with Proceed with initialization? [yes|no], and the default answer is no: pressing Enter skips it, and the installer replies You have chosen to not have conda modify your shell scripts at all. An unattended install with -b skips it as well. conda then sits in its own folder, where the shell does not look.

The fix takes a minute: run conda init once, through its full path, for the shell you use, and open a new terminal.

~/miniconda3/bin/conda init bash
source ~/.bashrc

~/miniconda3/bin/conda init zsh
source ~/.zshrc

Replace ~/miniconda3 with your install folder: ~/anaconda3, ~/miniforge3, or on a Mac /opt/miniconda3 and /opt/anaconda3 after the graphical installers. Step 1 finds it if you are not sure.

Which error do you see?

1. Find where conda is installed

ls -d ~/miniconda3 ~/anaconda3 ~/miniforge3 \
      /opt/conda /opt/miniconda3 /opt/anaconda3 2>/dev/null

ls -d ~/miniconda3 ~/anaconda3 ~/miniforge3 ~/opt/anaconda3 \
      /opt/miniconda3 /opt/anaconda3 /opt/homebrew/anaconda3 \
      /opt/homebrew/Caskroom/miniconda/base \
      /opt/homebrew/Caskroom/miniforge/base 2>/dev/null

Nothing listed? Search for the binary itself. If this finds nothing either, conda is genuinely not installed: skip to installing it.

find / -path '*/bin/conda' -type f 2>/dev/null | head

2. Initialise your shell

Run conda init through its full path, as the user who will use conda, not with sudo. Pick the shell you actually use: macOS has defaulted to zsh since Catalina, and most Linux servers use bash. echo "$SHELL" tells you which one is yours.

~/miniconda3/bin/conda init bash

~/miniconda3/bin/conda init zsh

~/miniconda3/bin/conda init fish

Then open a new terminal, or reload the file it changed with source. conda init writes to ~/.bashrc for bash on Linux, ~/.bash_profile for bash on macOS, ~/.zshrc for zsh (inside $ZDOTDIR if you set one) and ~/.config/fish/config.fish for fish. conda init --all sets up every shell it knows; --dry-run shows what it would change without writing anything.

conda --version
conda info --envs

What conda init actually changes

It adds a block between # >>> conda initialize >>> markers to that file. The block runs conda shell.bash hook (or the zsh or fish equivalent), which does two things:

• puts the conda bin directory on your PATH, and
• defines conda as a shell function, which is what makes conda activate able to change the environment of the current shell.

That second point explains the most common follow-up error, covered next. To undo everything, conda init --reverse removes the block again.

“Run 'conda init' before 'conda activate'” and “Your shell has not been properly configured”

You get one of these when the conda binary is on your PATH (for example because you added it with export PATH=…) but the shell function was never loaded. Releases since late 2023 print CondaError: Run 'conda init' before 'conda activate'; older ones print CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'. Adding the directory to PATH is not enough for activate. Run conda init as above and open a new shell, or load the hook for the current session only:

eval "$(~/miniconda3/bin/conda shell.bash hook)"
conda activate ENV_NAME

Use shell.zsh in zsh. type conda shows whether it worked: bash answers conda is a function, zsh conda is a shell function from …; a file path means the hook did not run.

macOS: “zsh: command not found: conda”

zsh reads ~/.zshrc, never ~/.bashrc or ~/.bash_profile. So conda initialised for bash, perhaps by an old install or by following a Linux guide, stays invisible to zsh. Run conda init zsh with the full path and open a new terminal. Where the binary lives depends on how conda arrived:

• Graphical .pkg installers install into /opt/miniconda3 or /opt/anaconda3. Anaconda’s .pkg used your home folder before release 2024.02.
• The terminal (.sh) installers install into ~/miniconda3, ~/anaconda3 or ~/miniforge3, and ask the same yes/no question as on Linux.
• Homebrew’s miniconda and miniforge casks install into /opt/homebrew/Caskroom/<name>/base and link conda into /opt/homebrew/bin. The command is found, but conda activate fails until you run conda init zsh, which the cask’s own notes ask you to do.
• Homebrew’s anaconda cask installs into /opt/homebrew/anaconda3 and links nothing, so zsh cannot find conda at all until you initialise it.

/opt/homebrew/anaconda3/bin/conda init zsh

On an Intel Mac, an existing Homebrew keeps working from /usr/local instead of /opt/homebrew, but a new Homebrew install stops with Homebrew on macOS is only supported on Apple Silicon processors!. There, use the Miniconda .pkg or the Miniforge .sh installer for x86_64 instead of a cask. If brew itself is “not found”, Homebrew’s own PATH line is missing from ~/.zprofile; the macOS section of npx: command not found has it.

Scripts, cron, systemd and SSH commands

~/.bashrc is read by interactive shells only. Cron jobs, systemd units, CI steps and ssh host 'command' skip it, so conda is “not found” there even after conda init. Cron runs each line with /bin/sh, which on Debian and Ubuntu is dash and reports /bin/sh: 1: conda: not found; a #!/bin/sh script names itself and the line instead, as in ./job.sh: 3: conda: not found. Do not try to activate an environment in those places. Call the environment’s own interpreter by its absolute path:

/home/USER/miniconda3/envs/ENV_NAME/bin/python /PATH/TO/SCRIPT.py

That is the most robust form for crontab lines and ExecStart= in systemd units, because it depends on nothing but an absolute path. Or let conda set up the environment for one command:

/home/USER/miniconda3/bin/conda run -n ENV_NAME python /PATH/TO/SCRIPT.py

A bash script that really needs conda activate loads conda first:

source ~/miniconda3/etc/profile.d/conda.sh
conda activate ENV_NAME

“-bash: conda: command not found” after an SSH login

An SSH login starts bash as a login shell, which reads ~/.bash_profile or, if that does not exist, ~/.profile, and not ~/.bashrc where conda init wrote its block. Debian and Ubuntu’s stock ~/.profile loads ~/.bashrc, and so does the ~/.bash_profile that Rocky and AlmaLinux create. One you created yourself usually does not. Add this line to it:

[ -f ~/.bashrc ] && . ~/.bashrc

“sudo: conda: command not found”

A per-user install lives in your home directory, and sudo runs with its own PATH, secure_path from /etc/sudoers. That is expected. Classic sudo prints sudo: conda: command not found; sudo-rs, the default sudo on Ubuntu 25.10 and 26.04, prints sudo: 'conda': command not found. Conda environments should not need root. If one step genuinely does, use the full path to the binary rather than installing a second conda for root.

Installing conda if it really is missing

On a server, a minimal installer is the right choice. Miniforge uses the community conda-forge channel by default. Miniconda uses Anaconda’s channel, whose terms of service matter for commercial use in larger organisations.

wget "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"
bash "Miniforge3-$(uname)-$(uname -m).sh"

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh

Type yes when the installer asks Proceed with initialization? [yes|no]; just pressing Enter means no. For an unattended install, -b skips all questions, so add the init step yourself (the current installers also take -c, which runs it for you in batch mode):

bash Miniforge3-$(uname)-$(uname -m).sh -b -p "$HOME/miniforge3"
"$HOME/miniforge3/bin/conda" init bash

No wget on the box? See wget: command not found, or use curl -LO with the same URL.

In a Docker image

Dockerfile RUN steps are non-interactive shells too. Put conda on the PATH with ENV and use conda run for commands inside an environment. Better still, start from condaforge/miniforge3 or continuumio/miniconda3, which already do this. ENV_NAME is the name: line of your environment.yml.

FROM condaforge/miniforge3
COPY environment.yml .
RUN conda env create -f environment.yml
# run later RUN steps inside the environment
SHELL ["conda", "run", "-n", "ENV_NAME", "/bin/bash", "-c"]
RUN python -c "import numpy; print(numpy.__version__)"

Windows: “'conda' is not recognized as an internal or external command”

In cmd the message is 'conda' is not recognized as an internal or external command, followed by operable program or batch file. PowerShell says The term 'conda' is not recognized as the name of a cmdlet, function, script file, or operable program. (PowerShell 7: “as a name of a cmdlet… or executable program”). The installer leaves conda off the PATH on purpose: Anaconda advises against the installer’s “Add Miniconda3 to my PATH environment variable” option (Anaconda3 in the full distribution), because it puts conda’s programs on the PATH for good, even with no environment active, where other software can pick them up and fail. Open Anaconda Prompt or Miniforge Prompt from the Start menu, where conda is already set up, and run this once to use conda from ordinary terminals:

conda init powershell
conda init cmd.exe

conda init powershell writes to your PowerShell profile; cmd.exe gets a registry AutoRun entry. Open a new window afterwards. If PowerShell then complains that running scripts is disabled, allow local scripts such as your profile for your account with Set-ExecutionPolicy -Scope CurrentUser RemoteSigned (scripts downloaded from the internet still need a signature) and open a new window.

If you only want the conda command in cmd without init, add the condabin folder of your install, for example %USERPROFILE%\miniconda3\condabin, to your user PATH. It holds only conda’s own batch files, such as conda.bat, and no other programs. WSL is a separate Linux system: a Windows install is not visible there, so install conda inside WSL and follow the Linux steps.

Check that it works

type conda
conda --version
conda activate base

type conda should report a function, conda --version prints a version such as conda 26.7.1, and conda activate base puts (base) in front of your prompt. Open a second terminal to confirm it survives a new session, and test cron or SSH separately if that is where it failed.

Data science jobs are usually CPU-bound, and much of a pandas pipeline runs on one core at a time. If you are setting up a box for them, the Hi-CPU KVM line runs on AMD EPYC with ECC memory and is sized for work that leans on one or two cores rather than many.

Another tool missing, or a directory to add to PATH for good in bash, zsh and fish? See command not found: the three causes and the fix for every tool.

Frequently asked