#3879·mamba

`mamba activate` fails in Windows after starting cmd.exe with `activate.bat`, shell not initialized

Author: noragenCreated Apr 5, 2025Updated Aug 5, 2026
Labelswhere::windows

Troubleshooting docs

  • My problem is not solved in the Troubleshooting docs

Anaconda default channels

  • I do NOT use the Anaconda default channels (pkgs/* etc.)

How did you install Mamba?

Other (please describe)

Search tried in issue tracker

done, something like related: https://github.com/mamba-org/mamba/issues/3684

Latest version of Mamba

  • My problem is not solved with the latest version

Tried in Conda?

I do not have this problem with Conda, just with Mamba

Describe your issue

When launching cmd.exe with the following command on Windows:

%windir%\System32\cmd.exe "/K" C:\Anaconda3\Scripts\activate.bat C:\Anaconda3

This brings up a base environment (as expected). However, attempting to switch to another environment using mamba activate <env> results in the following error:

(base) C:\Users\\\user>mamba activate beeware
critical libmamba Shell not initialized

'mamba' is running as a subprocess and can't modify the parent shell.
Thus you must initialize your shell before using activate and deactivate.

To automatically initialize all future (cmd.exe) shells, run:
    $ mamba shell init --shell cmd.exe --root-prefix=~/.local/share/mamba

This makes it impossible to use mamba properly in this setup, as no environment can be activated this way.

Interestingly, this works as expected if I run:

(base) > conda deactivate
> mamba activate beeware
(beeware) >

So the problem seems to be that mamba activate cannot function if a base environment was pre-activated using the legacy activate.bat script, or mamba itself. It also lacks a mamba deactivate command, which could be used to work around the issue.

Expected behavior:

  • It should be possible to switch between environments using mamba activate <env> without manually deactivating beforehand.
  • Either support should be improved for sessions started via activate.bat, or mamba should detect and handle that state more gracefully.

mamba info / micromamba info

bash
(base) C:\Users\\\user>mamba info

       libmamba version : 2.0.8
          mamba version : 2.0.8
           curl version : libcurl/8.13.0 Schannel zlib/1.3.1 libssh2/1.11.1
     libarchive version : libarchive 3.7.7 zlib/1.3.1 liblzma/5.6.3 bz2lib/1.0.8 liblz4/1.10.0 libzstd/1.5.6
       envs directories : C:\Anaconda3\envs
          package cache : C:\Anaconda3\pkgs
                          C:\Users\\\user\.mamba\pkgs
                          C:\Users\\\user\AppData\Roaming\.mamba\pkgs
            environment : base (active)
           env location : C:\Anaconda3
      user config files : C:\Users\\\user\.mambarc
 populated config files : C:\Users\\\user\.condarc
       virtual packages : __win=10.0.19045=0
                          __archspec=1=x86_64_v3
               channels : https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/nodefaults/noarch
                          https://conda.anaconda.org/nodefaults/win-64
       base environment : C:\Anaconda3
               platform : win-64

Logs

bash
(base) C:\Users\\\user>mamba activate beeware
critical libmamba Shell not initialized

'mamba' is running as a subprocess and can't modify the parent shell.
Thus you must initialize your shell before using activate and deactivate.

To automatically initialize all future (cmd.exe) shells, run:
    $ mamba shell init --shell cmd.exe --root-prefix=~/.local/share/mamba

environment.yml

yaml

~/.condarc

yaml
channels:
  - conda-forge
  - nodefaults
ssl_verify: true
pip_interop_enabled: true