#16333·conda

Make "conda run -n <env> conda ..." execute the target environment's conda

Author: CallekCreated Jul 2, 2026Updated Sep 18, 2026
Labelstype::bugsource::community

Checklist

  • I added a descriptive title
  • I searched open requests and couldn't find a duplicate

What is the idea?

Today, conda run .. conda executes the conda entry point from the invoking installation, rather than the target environment.

For example:

bash
$ conda --version
conda 24.11.3

$ conda create -y -n tmp-bld conda conda-build anaconda-anon-usage

$ conda list -n tmp-bld | rg conda
conda                     26.5.3
conda-build               26.5.0
...

$ conda run -n tmp-bld conda --version
conda 24.11.3

In contrast, ordinary executables are resolved from the target environment:

bash
$ conda run -n tmp-bld python --version
Python 3.14.x

Likewise,

bash
$ conda run -n tmp-bld python -m conda --version
conda 26.5.3

uses the conda installed in the target environment.

This also affects conda plugins.

While

bash
conda run -n <env> <plugin-executable> ...

runs the executable from the target environment, invoking a plugin through

bash
conda run -n <env> conda <plugin> ...

uses the invoking installation's conda, meaning plugin discovery and plugin versions come from the invoking installation rather than the target environment.

Why is this needed?

The command explicitly requests execution inside another environment, so it is natural to expect executable resolution to happen within that environment.

Today conda behaves differently from other executables:

  • conda run -n <env> python → target environment
  • conda run -n <env> python -m conda ... → target environment
  • conda run -n <env> conda ... → invoking installation
  • conda run -n <env> conda <plugin> ... → invoking installation's plugin discovery and plugin versions

Besides being surprising, this makes it difficult to test newer versions of conda and its plugins from an isolated environment using conda run, since the command continues to execute the invoking installation instead.

What should happen?

If the target environment contains a conda installation, then

bash
conda run -n <env> conda ...

should execute that installation's conda.

Likewise,

bash
conda run -n <env> conda <plugin> ...

should use the target environment's plugin discovery and execute the plugin versions installed there.

This would make conda consistent with how conda run resolves other executables and would allow users to reliably exercise the conda installation and plugins contained within the target environment.

Additional Context

Current workarounds are:

bash
conda run -n <env> python -m conda ...

or invoking the target environment's conda executable by absolute path.

I searched for an existing issue but didn't find one describing this specific behavior.

I'm intentionally filing this as a feature request rather than a bug report because this behavior appears to be longstanding, but from a user perspective it feels inconsistent with how conda run treats other executables.