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.
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
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
Expected output:
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:
- Makes
condacommands available in the shell - Activates the
baseenvironment
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):
After setting auto_activate_base false:
Conda is still fully functional. You just activate environments when you need them:
Where the Configuration Is Stored
Conda stores this setting in ~/.condarc, a YAML configuration file in your home directory:
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:
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.
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:
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:
Or simply remove the line from ~/.condarc:
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:
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 init | auto_activate_base | |
| Purpose | Wire Conda into your shell | Control startup environment |
| Without it | conda activate does not work | base is always active |
| Command | conda init bash (or zsh, fish, etc.) | conda config --set auto_activate_base false |
| Modifies | Shell 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
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:
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
baseactive. Open a new terminal to see the change. - Confusing
conda initwithauto_activate_base. Ifcondacommands do not work at all, you needconda init, notauto_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 initializeblock in.bashrc. This disables all of Conda's shell integration, not just base activation. Use the config setting instead. - System-level
.condarcoverriding user settings. In corporate or shared environments, an admin may have setauto_activate_base: trueat the system level. Check withconda config --show-sources. - Forgetting to activate an environment before running Python. With auto-activation off, running
pythonin a new terminal uses the system Python, not a Conda-managed one. Always activate an environment first. - Not re-running
conda initafter installing a new shell. If you switch from Bash to Zsh or install Fish, you needconda init zsh(orconda init fish) separately.
Miniforge and Mamba
If you use Miniforge or Mamba (community Conda distributions), the same setting works:
The ~/.condarc file is shared across all Conda-compatible tools.
Summary
- Run
conda config --set auto_activate_base falseto stopbasefrom 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-sourcesto debug when the setting does not seem to take effect. A system-level config may be overriding yours. conda initandauto_activate_basesolve 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
- How do I print an exception in Python?
- How do I print an exception in Python?
- How do I print the full NumPy array, without truncation?
- How do I print the full NumPy array, without truncation?
- How do I print the key-value pairs of a dictionary in python
- How do I print to console in pytest?
- How do I print to stderr in Python?
- How do I profile a Python script?
.png&w=3840&q=75)
Tackling System Design Interview Problems
A short course that equips you with the skills to approach system design interviews methodically.
Start the free courseTrack 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.