Remote and automated environments#

conda-completion works in terminals that load the startup file containing its hook. IDE integrated terminals, remote sessions, and containers all follow the same rule: install the hook where that shell session actually starts.

IDE terminals#

VS Code, Cursor, Windsurf, Positron#

VS Code and related editors usually start the integrated terminal with your configured shell. If that shell reads the startup file where conda completion install wrote its hook, completions are available in the integrated terminal.

For Remote SSH and WSL, the hook needs to be installed on the remote machine or inside WSL, not on the local host:

# on the remote machine or inside WSL
conda completion install

JetBrains (PyCharm, IntelliJ, etc.)#

The terminal tool window sources your shell profile. Completions work if the hook is installed for the shell JetBrains runs (check Settings > Tools > Terminal > Shell path).

For Remote Development via Gateway, install the hook on the remote host.

Zed#

Zed’s terminal panel uses your configured shell. Completions are available when that shell reads the startup file containing the hook.

Neovim#

Terminal buffers (:terminal) run your shell with its profile. Completions work if the hook is installed for that shell.

JupyterLab#

The JupyterLab terminal runs your default shell. If the hook is installed, completions work in the terminal panel. Note that JupyterLab notebook cells (!conda install ...) do not go through shell completion.

Common pitfall#

Some terminal configurations skip the full profile (for example, non-login shells or custom shell paths). If completions work in a standalone terminal but not in your IDE, check that the IDE’s terminal loads the file where the hook was installed. Run conda completion status inside the IDE terminal to confirm the manifest and binary come from the environment you expect.

Containers#

Docker#

For images used for interactive development (dev containers, JupyterHub), generate the manifest at build time:

FROM continuumio/miniconda3:latest

RUN conda install -y -c conda-forge conda-completion && \
    conda completion install bash --yes && \
    conda clean -afy

--yes skips the interactive confirmation prompt.

For faster image builds that do not need package name or version completion, add --no-repodata to the install command.

If the container switches from root to a non-root user, run the install step as the final user or regenerate after switching users. The manifest lives in the current user’s cache directory.

Dev containers (VS Code / GitHub Codespaces)#

Add completion setup to postCreateCommand:

{
  "postCreateCommand": "conda completion install bash --yes"
}

Or in the Dockerfile used by the dev container:

RUN conda install -y -c conda-forge conda-completion && \
    conda completion install bash --yes

JetBrains dev containers#

JetBrains Gateway supports dev containers through the Dev Containers plugin. The same postCreateCommand approach works. Make sure the shell path in the container matches the shell you installed the hook for.

Gitpod#

Add completion setup to .gitpod.yml:

tasks:
  - init: conda completion install bash --yes

Or include it in the Dockerfile referenced by your Gitpod config.

DevPod#

DevPod uses the dev container spec, so the postCreateCommand approach from the VS Code section above works directly.

CI#

GitHub Actions#

To test that completions work after a plugin release:

- uses: prefix-dev/setup-pixi@v0.9.6
  with:
    environments: test

- name: Generate and verify completions
  run: |
    pixi run -e test -- conda completion generate
    pixi run -e test -- conda completion status

Caching the manifest#

- uses: actions/cache@v4
  with:
    path: ~/.cache/conda/completion
    key: conda-completion-${{ runner.os }}

After conda install, conda remove, or conda update, the manifest is regenerated when registered conda entry point names changed, so a simple OS-based cache key is usually enough. If a job updates a plugin without changing its entry point name, run conda completion generate before testing completions.

This cache directory also contains versions.index and versions.store when package metadata has been generated.

For jobs that only validate plugin command metadata, prefer:

- name: Generate command completions
  run: conda completion generate --no-repodata

This avoids network-dependent repodata reads.

Non-interactive environments#

generate and status work without a TTY. install and uninstall require --yes when no TTY is available.

See Use completion offline or on restricted networks for private mirrors, air-gapped setups, and restricted network behavior.

On this page
Show Source