Repository navigation
Please make python-envs.terminal.autoActivationType syncable to all remotes #1640
Description
The canonical fix for VSCode killing any running process to activate a Python environment after opening a terminal is to set autoActivationType to a non-default value.
The problem is that, at least on my machine, this is per-remote. Below screenshots are on an AWS EC2 instance:
This means that every time I start an instance or a new dev container, the first command I run in every terminal is killed until I got change that setting again.
Given that killing running processes indiscriminately is disruptive, I think it would be good to make it possible for a user to change this behavior for good. Otherwise, the only option is "python.terminal.activateEnvironment": false, which isn't ideal either.
Maybe there could be a defaultAutoActivationType setting that syncs, so the user can choose the syncing version or the other at will? Alternatively, setting the default to shellStartup might be less surprising and less likely to cause problems.
A good reason to care about this is that this can cost the user money. In my case, it killed an OpenCode session that had been running for hours, which I discovered too late, leading to a cache miss on the whole conversation when I started it again.
Activity
mohityadav8 commentedon Jul 24, 2026
Karthik Nadig (@karthiknadig) can i work on this
karthiknadig commentedon Jul 24, 2026
Go for it
eleanorjboyd commentedon Sep 23, 2026
🤖 My read of the proposal: give users a Settings Sync–enabled, account-wide default for terminal auto-activation (
command,shellStartup, oroff) that also applies when they connect to a new remote or dev container. Keep the existing machine-specificpython-envs.terminal.autoActivationTypesetting as an override where a particular host needs different behavior. That way, someone who choosesshellStartupto avoid activation interrupting a running terminal process does not have to repeat the setting on every new remote. Does that capture what you had in mind?mohityadav8 commentedon Sep 23, 2026
hii Eleanor Boyd (@eleanorjboyd) yes, exactly. i think this approach makes the most sense to me. Having an account-wide, Settings Sync–enabled default while keeping the existing machine-specific setting as an override seems like a good way to solve the issue without changing the behavior for users who need host-specific configurations.
I’d be happy to go ahead with this approach.
opening pr asap
eleanorjboyd commentedon Sep 30, 2026
Sounds great! Feel free to submit a PR and Ill have a look- thanks!
Make python-envs.terminal.autoActivationType syncable via Settings Sync