Code change:
/** Whether the mouse is within the terminal tabs list. */ export const tabsMouse = new RawContextKey<boolean>(TerminalContextKeyStrings.TabsMouse, false, true); <del> /** The shell type of the active terminal, this is set to the last known value when no terminals exist. */ export const shellType = new RawContextKey<string>(TerminalContextKeyStrings.ShellType, undefined, { type: 'string', description: localize('terminalShellTypeContextKey', "The shell type of the active terminal, this is set to the last known value when no terminals exist.") }); </del> <ins> /** The shell type of the active terminal, this is set if the type can be detected. */ export const shellType = new RawContextKey<string>(TerminalContextKeyStrings.ShellType, undefined, { type: 'string', description: localize('terminalShellTypeContextKey', "The shell type of the active terminal, this is set if the type can be detected.") }); </ins> /** Whether the terminal's alt buffer is active. */ export const altBufferActive = new RawContextKey<boolean>(TerminalContextKeyStrings.AltBufferActive, false, localize('terminalAltBufferActive', "Whether the terminal's alt buffer is active."));

Related discussion:
text: Testing This is sort of unrelated to the TPI, but when I inspect context keys on my terminal area, I notice that it has , even when the active terminal isn't using git bash. Here are my repro steps (not sure if this can be simplified): a terminal profile using an extension and launch the extension. git bash, then close it and open the extension-provided terminal profile. context keys on the extension-provided terminal instance. :bug:
I would like to solve this problem, if it is still an issue. Do you mind if I start?
sure!
After scanning some source, there seems no good way to solve this. Because is no way for extension to specify terminal type when (AFAIK) extension register a terminal profile ( ), and Windows, shell type is determined by some heuristic logic, based on executable string, and default to return . (For WSL, the shell type is always "undefined" in my quick experiment.) When terminal service try to update context key, it fallback to NOP if the shell type is , that's the behavior noticed at first place. See: For this issue to be solved, probably there should be a way for builtin terminal profile to specify shell type (so it works for all bultin profile in all platform), and for extension provided terminal profiles, maybe we can add more optional fields to or method to . As for the wierd behavior noticed currently, maybe we can set to "unknown", to make this state less confusing. But since that this behavior is already state in , I wonder this can be changed.
I think the problem is here: It should check if first, then set it even if it's undefined if
do you want to submit a PR since you investigated and found the problem?
Yes, I can submit a PR for this. But, before doing this, I need to confirm some detail. The current behavior is From A. If new terminal instance is created, and shell type of the new terminal istance is defined, update From B. If active terminal instance change, and shell type of the new terminal istance is defined, update C. If there is no terminal instance, reset D. otherwise, do nothing so the editor keeps last known when shell type is undefined during new terminal creation or active terminal change. If so, what value should be set on this case? should we set it to or just call ?