Terminal Shell Integration requires update for newer PowerShell 7.4+ ConstrainedLanguage AUDIT mode

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.107.0
• OS Version: Windows 11 25H2

Steps to Reproduce:

1. On Windows 11, enable a WDAC / App Control audit-only policy (On newer systems this is slowly being automatically enabled)
2. Install PowerShell 7.4 or later. It will run in ConstrainedLanguage AUDIT Mode
3. Launch VS Code
4. Open the integrated terminal using pwsh profile
5. Observe that PowerShell terminal shell integration does not initialize (prompt tracking / command boundaries unavailable)

Expected Result:

Shell integration should initialize when:

• $ExecutionContext.SessionState.LanguageMode is FullLanguage, or
• $ExecutionContext.SessionState.LanguageMode is ConstrainedLanguage and the system lockdown policy is Audit (Refer to Additional Information below for more details as to why)

Shell integration should continue to be blocked when constrained language mode is enforced. (However it would be nice if the integration explicitly states that it is being blocked due to a restricted language mode - something that is not super evident to unfamiliar devs).

Actual Result:

• PowerShell runs normally, in unrestricted fashion
• Scripts execute without restriction. For example, dynamic code (e.g. Add-Type) works fine
• However, Terminal shell integration does not initialize because it assumes restricted shell
• VS Code reports terminal integration failure, despite a fully functional shell
• This issue also affects downstream IDEs that reuse VS Code’s terminal integration logic (e.g. Windsurf, Cursor).

A minimal fix that allows shell integration in ConstrainedLanguage + Audit mode, while continuing to block other enforced restricted language modes, is being prepared as a follow-up PR and should be up soon.

Additional Information:

PowerShell 7.4 (released Nov 2023) introduced Constrained Language Audit Mode.

In this mode:

• LanguageMode reports ConstrainedLanguage
• But runtime semantics are equivalent to FullLanguage
• No restrictions are actually enforced
• The mode exists solely to log what would be blocked under enforcement

Audit vs enforced CLM can be detected via:

[System.Management.Automation.Security.SystemPolicy]::GetSystemLockdownPolicy()

The current language mode guard appears to originate from: #158548

That change predates the introduction of audit-only constrained language mode and was totally correct at the time. Since PowerShell semantics have evolved, the same guard now produces false negatives in audit-only scenarios by treating all ConstrainedLanguage sessions as enforced.

It is also worth noting that WDAC / App Control audit policies can become active implicitly on Windows 11 without explicit user configuration. Common cases include:

1. Activation of the Verified and Reputable Desktop baseline policy on consumer, developer-mode enabled machines not enrolled in any kind of MDM (think freelance/solo devs or small teams).
2. PowerShell Developer-oriented configurations where Windows prefers audit-first behavior instead of enforcement of PS1 script-breaking policies
3. OEM or security tooling that deploys audit policies as part of a hardening baseline, to meet Copilot+ PC certifications for example
4. User Toggling of advanced platform features (e.g. Copilot+ / Recall–class features), and connected VBS and related security protections

As a result, audit-only ConstrainedLanguage mode is becoming increasingly common on modern Windows 11 systems. In its defense, this is just FullLanguage mode with extra logs and accountability and should be treated as such.