Claude Code incorrectly sets VIRTUAL_ENV for pyenv environments

Description

After a recent Claude Code update, the environment variable VIRTUAL_ENV is being set incorrectly when using pyenv (not pyenv-virtualenv, just plain pyenv).

Environment

• Platform: macOS (Darwin 25.0.0)
• pyenv version: using Python 3.13.2 via pyenv
• Claude Code: latest version

Problem

Claude Code sets VIRTUAL_ENV=/Users/<user>/.pyenv/versions/3.13.2 when running commands, but pyenv base installations are NOT virtual environments.

This breaks applications that check for VIRTUAL_ENV to determine configuration paths. For example, GenroPy checks:

if ('VIRTUAL_ENV' in os.environ or hasattr(sys, 'real_prefix')) and not no_virtualenv:
    prefix = os.environ.get('VIRTUAL_ENV', sys.prefix)
    config_path = expandpath(os.path.join(prefix,'etc','gnr'))
    return config_path

With VIRTUAL_ENV incorrectly set, it looks for config in ~/.pyenv/versions/3.13.2/etc/gnr instead of ~/.gnr.

Steps to Reproduce

1. Have pyenv installed with a Python version (e.g., 3.13.2)
2. Run any command in Claude Code that depends on VIRTUAL_ENV not being set
3. Observe that VIRTUAL_ENV is set to the pyenv version path

Expected Behavior

VIRTUAL_ENV should NOT be set for plain pyenv installations. It should only be set when:

• A pyenv-virtualenv environment is active
• A venv/virtualenv is explicitly activated

Actual Behavior

VIRTUAL_ENV is set to the pyenv version path even though no virtual environment is active.

Verification

From a normal macOS terminal:

echo $VIRTUAL_ENV
# (empty - correct)

From Claude Code:

echo $VIRTUAL_ENV
# /Users/<user>/.pyenv/versions/3.13.2 (incorrect)

Workaround

Applications can work around this by setting their own environment variables to override the behavior, but this shouldn't be necessary.