Fix environment-dependent git pre-commit hooks

This is a follow up to #9948 and vscode#90178. After looking at the problem of environment-dependent pre-commit hooks from both the extension's and the editor's side, it seems to me the best solution would be for the Python extension to make sure that whatever environment the user has selected in the status bar is also active during the commit process (using VS Code's source control panel).

I think this would be the expected behavior by most users if you asked them. At least it took me by surprise that my active environment doesn't apply during the commit process even though it's indicated in the status bar. Hence why it took me a while to figure out this is the reason my pre-commit hooks aren't working.

One way to activate the status bar environment in the spawned git process might be as @joaomoreno mentioned to have a git wrapper that's local to the source control panel (i.e. doesn't affect git anywhere else) and simply activates the environment before handing over to real git.

João Moreno (@joaomoreno)

João Moreno (@joaomoreno) Janosh Riebesell (@janosh) In think the best (generic) way is here is if python extension can provide the environment variables. This way pyhton extension can provide the activated environment variables or set the PATH variable (depends on the type of environment). To achieve this the extension will need a hook from VS Code so we can provide these env vars when it spawns git process.

We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

Any updates? I would realy appreciate this behaviour!

Until your comment it seemed like there was little to no activity from devs towards closing this issue.

As you can see by our issue count, there's unfortunately simply too many issues for us to keep all ancillary issues up-to-date while we are working on something. Plus we don't want to give people false hopes on when things will be completed.

Maybe some fleshed out CLI documentation

"CLI documentation" for which CLI? code?

I appreciate your input. It is nice to know this issue has eyes on it and some impactful changes are indeed on the way which may enable moving this issue along.

"CLI documentation" for which CLI? code?

Yes, both `code` and `code-server` Just about the only commands and options I know the CLI to accept are the ones which are documented explicitly in the CLI documentation (i.e. install extensions, add folders to workspace, set ports). If more exist I don't know of them. This is all relatively unrelated to the original thread but in particular it would be nice if the CLI supported any of the menu commands. In my case I struggled setting up a Docker container with `code-server` for development because I couldn't find a CLI command to import a profile. AFAIK `devcontainers` wouldn't work because it creates a "docker-in-docker" problem. Eventually i settled with saving a `code-workspace` file but this is limited in its abilities too... such as the position and layout settings of tools.

…

On Wed, Aug 23, 2023, 14:55 Brett Cannon ***@***.***> wrote: Until your comment it seemed like there was little to no activity from devs towards closing this issue. As you can see by our issue count, there's unfortunately simply too many issues for us to keep all ancillary issues up-to-date while we are working on something. Plus we don't want to give people false hopes on when things will be completed. Maybe some fleshed out CLI documentation "CLI documentation" for which CLI? code? — Reply to this email directly, view it on GitHub <#10165 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB45WG6M4ZBUAXFUMSNK6ELXWZGZNANCNFSM4KW74PJQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

This is all relatively unrelated to the original thread but in particular it would be nice if the CLI

All feedback on the CLI should go to https://github.com/microsoft/vscode .

Not sure if this helps, but we had a similar problem, however, we're using pre-commit hooks via nix (https://github.com/cachix/pre-commit-hooks.nix). Nevertheless, I think our workaround could be adapted to other circumstances like python virtual environment. Essentially, we're "polluting" pre-commit hooks, so they'll load the necessary environment without needing VSCode to run in the environment. I hope this helps:

We use direnv to load nix environment
We enable nix in .envrc via use nix. That could be replaced with appropriate code to load python env without the need of nix.
We update pre-commit hook scripts with a small shell script. This is all managed by nix in our case, so pre-commit hooks as well as the patch are installed automatically

    if [ -f .envrc ] && [ -f .git/hooks/pre-commit ]; then
      cat .git/hooks/pre-commit | grep --silent "direnv export bash" || sed --in-place '2 i eval "$(direnv export bash)"' .git/hooks/pre-commit
    fi

Kamil Figiela (@kfigiela)

This is all relatively unrelated to the original thread but in particular it would be nice if the CLI

All feedback on the CLI should go to https://github.com/microsoft/vscode .

very good, will do!

Kamil Figiela (@kfigiela) very good! That is actually pretty similar to what I've done as well - I also use sed to insert the commands for activating my conda environment in the shell opened by .git/hooks/pre-commit... I will have to look at automating it more as you have done.

My biggest gripe with doing it this way is that if the project/workspace interpreter is changed later on by the user then the script will need to be updated and then sed gets a little trickier if you want to clean up the prior statements. I have not yet been able to discover where VS Code (or VS Code Server, for that matter) store the setting of the workspace interpreter once it's been set through the command pallet (note the setting from command pallet takes precedence over the python.defaultInterpreter setting in settings.json). This is another example of where the documentation, overall API, and especially CLI could be improved

I've been poking around on this and am considering trying to put together an Open Source Contribution (though I'll have some learning to do with VSCode extensions) to try resolving this, but have a couple questions I'm trying to track down/understand before I can do that.

When going to the VSCode Output Tab with "Git" selected, is there a way for me to figure out what shell/terminal that is using? I don't have pre-commit on my system environment, so the fact it is starting it and failing by missing a requirement suggests it isn't using my base system environment.
Re: Discussion on environment variables. I'm using pyenv, which sets an environment variable called VIRTUAL_ENV that seems to point to the version of python in the Terminal that I've assigned to my repo as expected. This may work to pass to SCM when Commit is hit from the UI, as I imagine this environment variable will be set appropriately. Not sure if that's true for other tools like conda. I'm open to trying this though as a first pass, if I can figure out what environment the Git Output in SCM is running in. Or is there something better that the Python Extensions surfaces that it can pass off to the SCM extension?
In the meantime, I've found that having pre-commit in my environment, not installing it with pre-commit install and using the pre-commit extension actually does an ok job as a stop-gap. It doesn't block commits like pre-commit does if there are errors, but if I have the RunOnSave property set to all-hooks, it'll run my standard hooks I want and error in the appropriate environment on the Terminal tab on VSCode. If pre-commit isn't fully installed, than SCM works fine and doesn't get blocked. Using fast linters/formatters like ruff or black work well in this setup. Example of a failure:

Either way, I figured I'd surface what I'd learned and prompt with any potential help to try getting momentum on a potential solution going here.

Kyle Hansen (@kr-hansen)

Kyle Hansen (@kr-hansen) thanks for the input. Here is what I can say in regards to (1) and (2)

When going to the VSCode Output Tab with "Git" selected, is there a way for me to figure out what shell/terminal that is using? I don't have pre-commit on my system environment, so the fact it is starting it and failing by missing a requirement suggests it isn't using my base system environment.

In my case it is using /usr/bin/bash, the shebang at the beginning of the hook file should give an clue of which shell is being used. To be certain you can echo the SHELL environment variable from within your /<path>/<to>/<project>/.git/hooks/pre-commit file like so:

echo SHELL="${SHELL}"

This means that there is no project-specific environment configuration being done - just whatever is in ${HOME}/.bashrc

Re: Discussion on environment variables. I'm using pyenv, which sets an environment variable called VIRTUAL_ENV that seems to point to the version of python in the Terminal that I've assigned to my repo as expected. This may work to pass to SCM when Commit is hit from the UI, as I imagine this environment variable will be set appropriately. Not sure if that's true for other tools like conda. I'm open to trying this though as a first pass, if I can figure out what environment the Git Output in SCM is running in. Or is there something better that the Python Extensions surfaces that it can pass off to the SCM extension?

With conda you should call the activate sub-command rather than setting environment variables directly:

conda activate <env_name>

Not a solution but a simple workaround: Start code from the terminal from within the environment that you want to use for pre-commit. It seems like VSCode then uses this environment for the system hooks.

I have the same problem in WSL when calling commit from the GUI sidebar.

How I solved the problem 🥳 :

open a third-party terminal in Windows and login to WSL
install pre-commit globally pip install pre-commit in WSL dist (Ubuntu in my case)
then walk to the project directory (in the same terminal)
install pre-commit like

$ pre-commit install
pre-commit installed at .git/hooks/pre-commit

then I switched to the VSCode window and tried to commit changes in the sidebar again and the commit was successful
to make sure that pre-commit worked, I opened Output (Ctrl+Shfit+U) and found information about the results of pre-commit

I hope you can do it too! 😄
Don't forget to leave a reaction if you can do it or not.

Fix for this is still wanted in 2025. Though I understand it may never happen

This is now the second-most upvoted issue, and the oldest issue in the top 25.

https://github.com/microsoft/vscode-python/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Any updates?

I'm affected by this

In a Python project using pre-commit, my workaround is to modify the .git/hooks/pre-commit file (created by pre-commit install) as follows:

diff -c .git/hooks/pre-commit pre-commit
*** .git/hooks/pre-commit       Tue Dec  2 13:42:11 2025
--- pre-commit  Tue Dec  2 13:42:08 2025
***************
*** 11,16 ****
--- 11,20 ----
  ARGS+=(--hook-dir "$HERE" -- "$@")
  
  if [ -x "$INSTALL_PYTHON" ]; then
+     INSTALL_DIR="$(dirname "$INSTALL_PYTHON")"
+     export PATH="$INSTALL_DIR:$PATH"
      exec "$INSTALL_PYTHON" -mpre_commit "${ARGS[@]}"
  elif command -v pre-commit > /dev/null; then
      exec pre-commit "${ARGS[@]}"

Navigation Menu

Repository navigation

Fix environment-dependent git pre-commit hooks #10165

43 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Fix environment-dependent git pre-commit hooks #10165

Description

Activity

karthiknadig commented on Feb 25, 2020

karthiknadig commented on Feb 25, 2020

TobiRoby commented on May 27, 2020

43 remaining items

brettcannon commented on Aug 23, 2023

gresavage commented on Aug 23, 2023

brettcannon commented on Aug 24, 2023

kfigiela commented on Aug 25, 2023

gresavage commented on Aug 25, 2023

kr-hansen commented on Apr 24, 2024

gresavage commented on May 10, 2024

stefanbschneider commented on Jul 16, 2024

vyach-vasiliev commented on Apr 11, 2025

mgrundie-r7 commented on May 19, 2025

Paul-Durrant commented on May 19, 2025

ducnv2082001 commented on May 30, 2025

RalfKow commented on Oct 15, 2025

boileaum commented on Dec 2, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions