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.
The canonical fix for VSCode killing any running process to activate a Python environment after opening a terminal is to set
autoActivationTypeto 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
defaultAutoActivationTypesetting that syncs, so the user can choose the syncing version or the other at will? Alternatively, setting the default toshellStartupmight 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.