Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.86.0 (user setup) OS: Windows_NT x64 10.0. Steps to Reproduce: debugging a Python file using the Python extension, for debug console terminal, shell integration script isn't used: ! when a normal terminal is opened, it is used: ! This is leading to broken experience when applying environment collection just using shell integration.
do you set the executable in ?
Can you help with how Python debugger is launched?
Debugger uses the DAP request to launch user code, the extension does not control this terminal launch. The DAP server itself is launched by DAP client (VS code) using instances returned by provider registered with .
I think this is by design, can't you control debug terminal environments separately?
I'm not clear, can you instruct specifically if there's anything we can check Python's debugger end that might be preventing from using shell integration? Based on previous discussions, I think VS Code controls the entire experience, and as it predates shell integration feature, maybe shell integration is not getting invoked for such terminals.
Debug terminals normally run a single command and therefore would get very little out of shell integration. I wouldn't think we should touch such processes anyway in case shell integration somehow conflicts with them. Can't you control debug terminal environments separately?
Users expect our debug terminals to be activated, hence shell integration to set environment variables reliably is required there. I would expect debug terminal's environment to be the same as any other normal terminal, or at least an option to make it same as normal terminal would be nice. We can configure the "env" before launching, but that does not persist in terminal after debugging finishes, also shell integration would still be inactive.
I haven't used in a long time for JS, just used it again and your request makes sense. I thought it launched and was terminated after it was done, much like the debug console: ! It is probably safe to add this, it's not being activated because the shell is passed in explicitly here: Which disables shell integration here (): I think the reason for passing and is to support the setting. This could be passed through in the options as a so shell integration init knows about it?
Thanks, is it also possible to enable it for task terminals: ? Some users launch certain apps via tasks, expecting environment to be activated, and hence are failing because shell integration isn't active.
It's harder for tasks as we run the command in a similar way to how we initialize shell integration as opposed to sending the command in the debug terminal. We could probably do it, but I worry there would be changes in behavior and sometimes it might not work if shell integration is in a weird state. cc
I see, the thing we wanted to accomplish was to prepend an env variable exactly once via env collection, be it via shell integration (preferred) or process creation but not both. If shell integration isn't available for a terminal type, if we can apply those variables at process creation instead, that would also solve the issue.
Doing this for debug terminals makes sense. For tasks I don't think it's possible, I believe you can set the environment for the tasks you make?
Can we use to alter the environment for the terminal launched via debugging?
That's not us running tasks, it's the users, so we cannot control their environment unfortunately, unless it's via env collection. Also, what do you think about falling back to process creation if shell integration does not work for a terminal?
I'd ask about how to handle the tasks case
Had a chat with and he says that as the whole debugging experience is configured by core, Python extension does not control the in the debug terminal which is launched. So unfortunately the flag here as is would not work: Is there a possibility to always enable shell integration for integrated terminal, instead of providing an option? Can you help with what options Python extension does control when launching the "Python debug console" terminal when debugging? And if there is a way to influence for the debug terminal.
, are you aware if we, the Python extension, can influence the DAP client so that when it creates the debug terminal, we control the creationOptions?
No. But I would also be fine if we wanted to add a custom property in VS Code+the Python extension to that VS Code could interpret to control whether shell integration is enabled. This is a very client-specific behavior and not something we'd want to put in DAP.

Discussion:
isTransient?: boolean; /** <ins> * Attempt to force shell integration to be enabled by bypassing the {@link isFeatureTerminal} * equals false requirement. */ forceShellIntegration?: boolean; /** </ins> * Create a terminal without shell integration even when it's enabled */ ignoreShellIntegration?: boolean;

// - There is no executable (not sure what script to run) // - The terminal is used by a feature like tasks or debugging const useWinpty = isWindows && (!options.windowsEnableConpty || getWindowsBuildNumber() < 18309); <del> if (!options.shellIntegration.enabled || !shellLaunchConfig.executable || shellLaunchConfig.isFeatureTerminal || shellLaunchConfig.hideFromUser || shellLaunchConfig.ignoreShellIntegration || useWinpty) { </del> <ins> if (!options.shellIntegration.enabled || !shellLaunchConfig.executable || (shellLaunchConfig.isFeatureTerminal && !shellLaunchConfig.forceShellIntegration) || shellLaunchConfig.hideFromUser || shellLaunchConfig.ignoreShellIntegration || useWinpty) { </ins> return undefined; }

? (id, cols, rows) => new TerminalProcessExtHostProxy(id, cols, rows, this._terminalService) : undefined, extHostTerminalId, <ins> forceShellIntegration: launchConfig.forceShellIntegration, </ins> isFeatureTerminal: launchConfig.isFeatureTerminal, isExtensionOwnedTerminal: launchConfig.isExtensionOwnedTerminal, useShellEnvironment: launchConfig.useShellEnvironment,

strictEnv?: boolean; hideFromUser?: boolean; isExtensionCustomPtyTerminal?: boolean; <ins> forceShellIntegration?: boolean; </ins> isFeatureTerminal?: boolean; isExtensionOwnedTerminal?: boolean; useShellEnvironment?: boolean;

export interface ITerminalInternalOptions { cwd?: string | URI; isFeatureTerminal?: boolean; <ins> forceShellIntegration?: boolean; </ins> useShellEnvironment?: boolean; resolvedExtHostIdentifier?: ExtHostTerminalIdentifier; /**

initialText: options.message ?? undefined, strictEnv: options.strictEnv ?? undefined, hideFromUser: options.hideFromUser ?? undefined, <ins> forceShellIntegration: internalOptions?.forceShellIntegration ?? undefined, </ins> isFeatureTerminal: internalOptions?.isFeatureTerminal ?? undefined, isExtensionOwnedTerminal: true, useShellEnvironment: internalOptions?.useShellEnvironment ?? undefined,

giveShellTimeToInitialize = true; terminal = this._terminalService.createTerminalFromOptions(options, { isFeatureTerminal: true, <ins> // Since debug termnials are REPLs, we want shell integration to be enabled. // Ignore isFeatureTerminal when evaluating shell integration enablement. forceShellIntegration: true, </ins> useShellEnvironment: true }); this._integratedTerminalInstances.insert(terminal, shellConfig);