Conda
Base Environment
Conda Configuration
Python
Programming Tips

How do I prevent Conda from activating the base environment by default?

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

Run conda config --set auto_activate_base false to stop Conda from activating the base environment every time you open a new terminal. This is the official, recommended way to prevent the automatic activation. After running it, new shell sessions start with a clean prompt and no Python environment active until you explicitly activate one.

The One-Line Fix

bash
conda config --set auto_activate_base false

That is it. Open a new terminal window to see the change take effect. Your prompt will no longer show (base) at the beginning.

Verify the setting

bash
conda config --show auto_activate_base

Expected output:

 
auto_activate_base: False

If the output still shows True, the setting may be overridden at the system level. More on that in the troubleshooting section below.

What This Setting Actually Changes

When Conda initializes your shell (via conda init), it adds a hook to your shell startup file (.bashrc, .zshrc, etc.). That hook runs every time you open a terminal and does two things:

  1. Makes conda commands available in the shell
  2. Activates the base environment

Setting auto_activate_base to false disables only step 2. Conda commands remain available. You just do not start inside an environment.

Before and after

Before (default behavior):

 
(base) user@machine ~ $

After setting auto_activate_base false:

 
user@machine ~ $

Conda is still fully functional. You just activate environments when you need them:

bash
conda activate myproject

Where the Configuration Is Stored

Conda stores this setting in ~/.condarc, a YAML configuration file in your home directory:

yaml
auto_activate_base: false

You can also edit this file directly instead of using conda config. The command just modifies this file for you.

Check all configuration sources

Conda supports multiple configuration scopes. If the setting does not seem to work, check where values are coming from:

bash
conda config --show-sources

This shows every .condarc file that Conda reads, in priority order. A system-level config at /etc/conda/.condarc or an environment-level config can override your user setting.

bash
1# Example output
2==> /etc/conda/.condarc <==
3auto_activate_base: true
4
5==> /home/user/.condarc <==
6auto_activate_base: false

In this case, the system config wins. You would need admin access to change the system config, or you can override it with an environment variable:

bash
export CONDA_AUTO_ACTIVATE_BASE=false

Add this to your shell profile (.bashrc, .zshrc) to make it permanent.

Reverting to Default Behavior

If you later want Conda to activate base on startup again:

bash
conda config --set auto_activate_base true

Or simply remove the line from ~/.condarc:

bash
conda config --remove-key auto_activate_base

Removing the key returns to Conda's built-in default, which is true.

The Shell Initialization Script Explained

To understand why base activates automatically in the first place, look at what conda init adds to your shell profile. For Bash, it adds something like this to ~/.bashrc:

bash
1# >>> conda initialize >>>
2# !! Contents within this block are managed by 'conda init' !!
3__conda_setup="$('/home/user/miniconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
4if [ $? -eq 0 ]; then
5    eval "$__conda_setup"
6else
7    if [ -f "/home/user/miniconda3/etc/profile.d/conda.sh" ]; then
8        . "/home/user/miniconda3/etc/profile.d/conda.sh"
9    else
10        export PATH="/home/user/miniconda3/bin:$PATH"
11    fi
12fi
13unset __conda_setup
14# <<< conda initialize <<<

This block makes conda commands available. It also checks auto_activate_base internally and activates base if the setting is true. Do not remove this block entirely. Doing so removes Conda shell integration, and commands like conda activate will stop working.

conda init vs auto_activate_base: Two Different Problems

These solve different things:

conda initauto_activate_base
PurposeWire Conda into your shellControl startup environment
Without itconda activate does not workbase is always active
Commandconda init bash (or zsh, fish, etc.)conda config --set auto_activate_base false
ModifiesShell startup file (.bashrc, .zshrc)~/.condarc

If conda commands are not found in a new terminal, the problem is conda init, not auto_activate_base. Run conda init for your shell first, then set the auto-activate preference.

Combining with Environment Auto-activation per Project

Many developers want no environment on startup but automatic activation when they enter a project directory. Tools like direnv or conda's own .condarc in project directories can handle this:

Using direnv

bash
1# Install direnv
2# In your project directory, create .envrc:
3echo 'eval "$(conda shell.bash hook)"' > .envrc
4echo 'conda activate myproject' >> .envrc
5direnv allow

Now entering that directory activates the environment, and leaving it deactivates.

Using a project-level .condarc

Conda reads .condarc files from multiple locations. A project directory can have its own:

yaml
# /path/to/project/.condarc
envs_dirs:
  - /path/to/project/envs

This does not auto-activate, but it helps keep environment management project-scoped.

Common Pitfalls

  • Expecting the current terminal to change immediately. The setting only affects new shell sessions. The terminal where you ran the command still has base active. Open a new terminal to see the change.
  • Confusing conda init with auto_activate_base. If conda commands do not work at all, you need conda init, not auto_activate_base. These are independent settings.
  • Editing the shell startup file manually instead of using the config command. Some developers try to comment out the conda initialize block in .bashrc. This disables all of Conda's shell integration, not just base activation. Use the config setting instead.
  • System-level .condarc overriding user settings. In corporate or shared environments, an admin may have set auto_activate_base: true at the system level. Check with conda config --show-sources.
  • Forgetting to activate an environment before running Python. With auto-activation off, running python in a new terminal uses the system Python, not a Conda-managed one. Always activate an environment first.
  • Not re-running conda init after installing a new shell. If you switch from Bash to Zsh or install Fish, you need conda init zsh (or conda init fish) separately.

Miniforge and Mamba

If you use Miniforge or Mamba (community Conda distributions), the same setting works:

bash
conda config --set auto_activate_base false
# or
mamba config --set auto_activate_base false

The ~/.condarc file is shared across all Conda-compatible tools.

Summary

  • Run conda config --set auto_activate_base false to stop base from activating on every new terminal.
  • This only changes startup behavior. Conda commands remain available, and you can activate any environment manually.
  • The setting is stored in ~/.condarc. You can also edit that file directly.
  • Use conda config --show-sources to debug when the setting does not seem to take effect. A system-level config may be overriding yours.
  • conda init and auto_activate_base solve different problems. Do not remove the conda init block from your shell profile.
  • Open a new terminal after changing the setting. The current terminal is unaffected.
  • Works identically with Miniforge, Mamba, and other Conda-compatible distributions.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.