You've activated your virtual environment, installed your packages, and opened Antigravity — only to find it still flagging imports as unresolved, refusing to autocomplete installed libraries, or pointing to the wrong Python version entirely. Sound familiar?
The root cause is almost always the same: the Python interpreter your terminal is using and the one Antigravity has selected are two completely different processes. Whatever you pip install in one environment doesn't become visible in the other until Antigravity is told explicitly where to look. This guide walks through how to fix it, organized by which environment manager you're using.
First: Confirm Which Pattern You're Hitting
Before jumping to solutions, spend thirty seconds confirming the actual problem. In your terminal, run:
which python
python --versionThen look at the bottom-right status bar in Antigravity — click on the Python version displayed there to open the interpreter picker. Compare the path shown in Antigravity against what which python returned in your terminal.
- Paths match → the interpreter is correctly detected. Your issue is likely something else (check the "Common Mistakes" section below).
- Paths differ → Antigravity is using the wrong interpreter. Keep reading.
A good secondary check is to open Antigravity's integrated terminal (Ctrl+`) and run which python there too. If this path matches the status bar but differs from your external terminal, the integrated terminal has inherited Antigravity's interpreter rather than your shell's activated environment — which is actually the expected behavior and the thing you need to reconfigure.
venv (Python Standard Library)
If you created your environment with python -m venv .venv, the most reliable fix is to point Antigravity directly at the interpreter binary inside the .venv directory.
# Create the virtual environment at project root
python -m venv .venv
# Activate it
source .venv/bin/activate # macOS / Linux
.venv\Scripts\activate # Windows
# Confirm the path
which python
# → /Users/you/your-project/.venv/bin/pythonTake that path and paste it directly into Antigravity's interpreter picker. Open the Command Palette (Cmd+Shift+P / Ctrl+Shift+P), search for "Python: Select Interpreter", and choose "+ Enter interpreter path" to type or paste it manually.
Relying on Antigravity's auto-detection works most of the time, but when it doesn't — particularly when the .venv folder lives in a non-standard location or when you've just created it — direct path entry is the definitive fix.
One thing worth noting: after selecting the interpreter, Antigravity may take a few seconds to re-index the installed packages. If autocomplete for a newly installed library doesn't appear immediately, wait a moment or run "Python: Reload" from the Command Palette.
Poetry
Poetry creates virtual environments in a system-level cache directory by default — something like ~/Library/Caches/pypoetry/virtualenvs/ on macOS or ~/.cache/pypoetry/virtualenvs/ on Linux. Antigravity rarely auto-detects these because they're far from the project root and the naming convention isn't always obvious.
The cleanest solution is to configure Poetry to create the environment inside the project itself:
# Configure Poetry to use in-project virtual environments (one-time, global setting)
poetry config virtualenvs.in-project true
# Rebuild the environment
poetry env remove python # optional: remove the old one first
poetry installAfter this, Poetry creates a .venv/ folder at your project root — exactly where Antigravity looks first. Close and reopen the Antigravity window (or run "Python: Reload"), and it should pick up the environment automatically.
If you're applying this setting to an existing project and don't run poetry env remove python first, the old environment in the cache directory won't be deleted. Poetry will create a fresh .venv/ locally, but the cached one will remain. This is harmless, though it wastes disk space.
For projects where changing the virtualenvs.in-project setting isn't desirable — perhaps because of team-wide Poetry config constraints — you can always fall back to finding the environment path manually:
# Print the path to the current Poetry-managed environment
poetry env info --path
# → /Users/you/Library/Caches/pypoetry/virtualenvs/myproject-abc12345-py3.12Append /bin/python to this and enter it directly in Antigravity's interpreter picker.
uv
uv creates .venv/ at the project root by default, which makes it more Antigravity-friendly than Poetry out of the box. That said, there's sometimes a brief delay between running uv sync and Antigravity picking up the updated environment.
# Install dependencies from pyproject.toml / uv.lock
uv sync
# Or add a new package
uv add httpx
# Confirm the interpreter path
.venv/bin/python --versionAfter running these commands, click the Python version in the status bar and re-select the interpreter to force a refresh. This is especially important when you've just added a new package and want Antigravity's linter to recognize it immediately.
One situation that catches people off-guard: when using uv with uv run, scripts execute inside the managed environment, but Antigravity's status bar may still show the system Python if you haven't explicitly set the interpreter. Always confirm via the status bar after any uv sync or uv add operation.
For deeper troubleshooting — particularly ModuleNotFoundError that persists even after correct interpreter selection — the Antigravity × uv package-not-found error guide covers more edge cases.
Conda
Conda environments are the trickiest to get Antigravity to detect automatically, because they live in a global directory structure rather than inside the project folder. The path can look intimidating, but finding and entering it manually takes less than a minute.
Step 1: Find the exact interpreter path
conda info --envs
# Example output:
# base * /opt/homebrew/Caskroom/miniconda/base
# myenv /opt/homebrew/Caskroom/miniconda/base/envs/myenvTake the full path to your environment (/opt/homebrew/Caskroom/miniconda/base/envs/myenv) and append /bin/python on macOS/Linux, or \python.exe on Windows.
Full example path: /opt/homebrew/Caskroom/miniconda/base/envs/myenv/bin/python
Step 2: Enter it manually in the interpreter picker
Open the Command Palette, select "Python: Select Interpreter", then "+ Enter interpreter path", and paste the full path.
Step 3: Persist the setting in workspace configuration
To avoid repeating this every time you open the project, add the path to .vscode/settings.json:
{
"python.defaultInterpreterPath": "/opt/homebrew/Caskroom/miniconda/base/envs/myenv/bin/python"
}Antigravity reads VS Code-compatible workspace settings, so this works as expected. Keep in mind this path is machine-specific — if you share the repo with a team, either add this file to .gitignore or use an environment variable and a wrapper script, rather than committing a hardcoded path.
Common Mistakes Worth Checking
Even after correctly configuring the interpreter, some issues persist due to easy-to-miss mistakes.
Activating in the terminal doesn't update Antigravity's interpreter
Terminal activation (source .venv/bin/activate) and Antigravity's selected interpreter are independent. Running activate in a shell window has no effect on the interpreter Antigravity uses for linting, IntelliSense, or the integrated terminal. Set it explicitly through the interpreter picker.
Creating the venv after launching Antigravity
Antigravity scans for virtual environments when it first opens a folder. If you create a new virtual environment after the editor is already running, it won't appear in the auto-detection list. Either run "Python: Reload" from the Command Palette, or close and reopen the window.
Opening the wrong folder
Antigravity stores interpreter settings per workspace folder. If you open a parent folder instead of the project root — or open just a subdirectory — the previously configured interpreter setting won't apply, and auto-detection may pick up the wrong environment. Always use File → Open Folder and target the project root directly.
Node.js version issues can look similar
If your project uses both Python and Node.js, node version mismatch errors can appear superficially similar to Python interpreter problems. For Node-specific issues, the Node.js version mismatch troubleshooting guide walks through how to diagnose and fix those separately.
Making the Setup Reproducible for Your Team
If you want every team member to start with the correct Python environment without any manual configuration, a devcontainer is the most reliable approach. By defining the Python version, packages, and environment variables in devcontainer.json, you eliminate the entire category of "works on my machine" interpreter problems.
The Antigravity DevContainer Complete Setup Guide walks through configuring a Python development environment from scratch, including how to pin the exact interpreter version and pre-install dependencies automatically when the container starts.
For solo projects, this might feel like overkill — but if you switch between machines or work across multiple Python versions, the upfront investment pays off quickly.
Where to Start
The fastest way to confirm and fix this today: click the Python version in Antigravity's status bar, see what path is currently selected, and compare it to which python in your terminal. If they don't match, paste the correct path using the "+ Enter interpreter path" option in the interpreter picker.
In the vast majority of cases, that single change resolves import errors, missing completions, and type-checking inconsistencies all at once.