Every shell command emits a spurious error under PowerShell ConstrainedLanguage mode (AppLocker/WDAC): $host.SetShouldExit() is not permitted

Describe the bug

On Windows machines where PowerShell runs in ConstrainedLanguage mode (enforced by AppLocker or WDAC, common in managed enterprise environments), every single shell command run by the agent prints a spurious error block.

Copilot CLI appends an exit-status epilogue to each command it runs:

} finally { $__copilotSuccess = $?; if (-not $__copilotSuccess -and $LASTEXITCODE -is [int] -and $LASTEXITCODE -ne 0) { $host.SetShouldExit($LASTEXITCODE) } elseif (-not $__copilotSuccess) { $host.SetShouldExit(1) } else { $host.SetShouldExit(0) } }

$host.SetShouldExit() is a .NET method call on a non-core type, which ConstrainedLanguage forbids. The wrapper itself therefore fails and emits:

Cannot invoke the method. Method invocation is supported only on core types in this language mode.
At line:2 char:225
+ ... Success) { $host.SetShouldExit(1) } else { $host.SetShouldExit(0) } }
+                                                ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation : (:) [], RuntimeException
    + FullyQualifiedErrorId : MethodInvocationNotSupportedInConstrainedLanguage

Why this matters

• Affects every command: Get-Item, python, curl — all of them.
• Pollutes the model context. The block is ~150 tokens.
• Risks incorrect failure detection. The text goes to stderr.

Suggested fix

Replace the $host.SetShouldExit(...) calls with the exit keyword, which is fully permitted in ConstrainedLanguage:

} finally { $__copilotSuccess = $?; if (-not $__copilotSuccess -and $LASTEXITCODE -is [int] -and $LASTEXITCODE -ne 0) { exit $LASTEXITCODE } elseif (-not $__copilotSuccess) { exit 1 } else { exit 0 } }

Alternatively, guard the call with a language-mode check and fall back to exit.

Affected version

1.0.81-0 (also reproduced on 1.0.82)

Steps to reproduce the behavior

1. On a Windows machine where AppLocker/WDAC forces PowerShell into ConstrainedLanguage mode.
   Verify with $ExecutionContext.SessionState.LanguageMode, which returns ConstrainedLanguage.
2. Run any trivial shell command via the agent, e.g. Get-Item $env:TEMP or python --version.
3. Observe the MethodInvocationNotSupportedInConstrainedLanguage error block shown above.

Expected behavior

The exit-status wrapper should use constructs permitted in ConstrainedLanguage (e.g. the exit keyword), so no spurious output is appended to successful commands.

Additional context

• OS: Windows 11, domain-joined, managed by corporate GPO
• CPU architecture: x86_64
• Shell: Windows PowerShell 5.1 (powershell.exe) — also reproduced on PowerShell 7.6.5 (pwsh.exe), so this is not version-specific
• Language mode: ConstrainedLanguage, enforced by AppLocker (Exe rule collection, EnforcementMode=1, pushed via domain GPO)
• Host: Copilot CLI running as the VS Code agent host (@github/copilot-win32-x64)

Verification performed

• Confirmed the offending template string is present in prebuilds/win32-x64/runtime.node.
• Confirmed it is still present in 1.0.82, so updating does not resolve it.
• Confirmed the wrapped commands themselves succeed and the process exit code is still correct (0 on success). The failure is limited to the epilogue, making this primarily output noise plus a stderr false-positive risk.
• A user-side trap cannot suppress it, because the error is raised from the wrapper's own finally block.

Start by inspecting the offending template string in prebuilds/win32-x64/runtime.node and reproduce the wrapper under ConstrainedLanguage with $ExecutionContext.SessionState.LanguageMode and a command such as Get-Item $env:TEMP. Verify that the exit-status epilogue uses permitted constructs and that successful and failing commands no longer emit MethodInvocationNotSupportedInConstrainedLanguage errors.