[QUESTION] Conda environment workflow guidance needed - inherited environment but missing shell functions

Update: conda run Testing Results

I've tested conda run as a potential workaround and found mixed results:

✅ What Works with conda run

# Correct Python environment selection
conda run -n thuts28x python -c "import sys; print(sys.executable)"
# Output: /opt/miniconda3/envs/thuts28x/bin/python ✅

# Basic conda environment variables
conda run -n thuts28x python -c "import os; print(os.environ.get('CONDA_DEFAULT_ENV'))"
# Output: thuts28x ✅

❌ What Doesn't Work with conda run

# Environment variables set via conda env config vars
conda env config vars set PYTHONPATH=. -n thuts28x
conda env config vars list -n thuts28x
# Output: PYTHONPATH = . (shows as set)

conda run -n thuts28x python -c "import os; print('PYTHONPATH:', os.environ.get('PYTHONPATH', 'NOT_FOUND'))"
# Output: PYTHONPATH: NOT_FOUND ❌

Required Workaround

Even with conda run, environment variables must be set manually:

PYTHONPATH=. conda run -n thuts28x python analysis/script.py

Conclusion

• conda run solves the Python interpreter selection problem (no need for conda activate)
• conda run does NOT solve the environment variable problem
• This is related to the broader environment variable persistence issue (#2508)

So while conda run is better than the eval hook && activate workaround, it still requires manual environment variable management."

Here is a workaround that worked for me.

1) I removed conda initialization part from my .bashrc. So now in shell the $PATH does not contain any anaconda3 folder
2) go to your project folder and activate a conda env
3) start claude and enter "! which python" to verify that it is the one from the activated conda env

I've made a StackOverflow question for the conda activation failure and the workarounds you have found already to increase visibility/findability: https://stackoverflow.com/questions/79742342/cannot-activate-conda-mamba-environment-in-claude-code-session

Thanks for flagging! I just pushed an update to the docs to clarify this behavior. The docs should be live later this week.

Pasting new docs here for reference:

Bash tool behavior

The Bash tool executes shell commands with the following persistence behavior:

• Working directory persists: When Claude changes the working directory (e.g., cd /path/to/dir), subsequent Bash commands will execute in that directory. You can use CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 to reset to the project directory after each command.
• Environment variables do NOT persist: Environment variables set in one Bash command (e.g., export MY_VAR=value) are not available in subsequent Bash commands. Each Bash command runs in a fresh shell environment.

To make environment variables available in Bash commands, you have three options:

Option 1: Activate environment before starting Claude Code (simplest approach)

Activate your virtual environment in your terminal before launching Claude Code:

conda activate myenv
# or: source /path/to/venv/bin/activate
claude

This works for shell environments but environment variables set within Claude's Bash commands will not persist between commands.

Option 2: Set CLAUDE_ENV_FILE before starting Claude Code (persistent environment setup)

Export the path to a shell script containing your environment setup:

export CLAUDE_ENV_FILE=/path/to/env-setup.sh
claude

Where /path/to/env-setup.sh contains:

conda activate myenv
# or: source /path/to/venv/bin/activate
# or: export MY_VAR=value

Claude Code will source this file before each Bash command, making the environment persistent across all commands.

Option 3: Use a SessionStart hook (project-specific configuration)

Configure in .claude/settings.json:

{
  "hooks": {
    "SessionStart": [{
      "matcher": "startup",
      "hooks": [{
        "type": "command",
        "command": "echo 'conda activate myenv' >> \"$CLAUDE_ENV_FILE\""
      }]
    }]
  }
}

The hook writes to $CLAUDE_ENV_FILE, which is then sourced before each Bash command. This is ideal for team-shared project configurations.

See [SessionStart hooks](/en/hooks#persisting-environment-variables) for more details on Option 3.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.