Method invocation is supported only on core types in this language mode: what it means and how to fix it

You run one command in your agent CLI. It works. Then a wall of red shows up anyway:

Cannot invoke the method. Method invocation is supported only on core types in this language mode.
    + FullyQualifiedErrorId : MethodInvocationNotSupportedInConstrainedLanguage

Exit code 0. The thing you asked for actually happened. So what's complaining, and why does it keep complaining on every single command?

I keep seeing this one in issue trackers, most recently for Copilot CLI on a domain-joined Windows 11 machine. The same error shows up in other tools too, anywhere a CLI shells out to PowerShell. If I remember correctly, here's the mechanism......

What's actually happening

PowerShell doesn't decide on its own to restrict you. When Windows detects an application control policy, either AppLocker or WDAC (Microsoft now calls that App Control for Business), PowerShell starts the session in ConstrainedLanguage mode. It's documented in about_Language_Modes if you want the source.

Constrained language isn't "no PowerShell". Cmdlets still run. Loops, ifs, functions, strings, all of that works. What changes is .NET method calls: they're only allowed on a short allow-list of core types, and everything else throws.

The tool's wrapper script usually ends like this:

$host.SetShouldExit($LASTEXITCODE)

$host is an InternalHost object, which isn't a core type, so that line fails. It's also the last line of the epilogue, which means it fails after your actual command already ran and returned 0. The cleanup path is complaining, not the work.

One JetBrains user hit the same class of thing from a second call, $Error.RemoveAt(0).

Confirm it in one line

Cmdlets aren't blocked under constrained language, so the diagnostics themselves work fine:

$ExecutionContext.SessionState.LanguageMode

If that prints ConstrainedLanguage, you found it. Then work out what's enforcing it:

Get-AppLockerPolicy -Effective -Xml

Non-empty output means AppLocker is the enforcer. For WDAC the logs are the tell. In Event Viewer:

• Applications and Services Logs > Microsoft > Windows > AppLocker > MSI and Script: 8007 is a script blocked, 8006 is audit only, 8005 is allowed.
• CodeIntegrity > Operational: 3076 (audit) and 3077 (blocked) mean WDAC is enforcing.
• PowerShell > Operational: entries state that the session ran in ConstrainedLanguage.

What actually fixes it

Two levels here, and I want to be careful about which one I'm putting my name behind.

The real fix is a policy exception, and it is documented. Scripts a policy allows run in FullLanguage even when the session is constrained. So the tool's wrapper scripts need to be in the allow list: a WDAC file or signer rule covering the app's payload, or the Managed Installer option if it's deployed through Intune or ConfigMgr. On the AppLocker side, a script rule exception for the tool's path or publisher. That's a change request rather than a workaround, and I know it can take a week to land. Raise it anyway, because it's the only version of this that survives the next update.

For today, stop routing through PowerShell. Most agent CLIs let you choose which shell their shell tool uses. Point it at cmd.exe or bash and the wrapper never runs. That's what people in the Copilot CLI thread reported working. One thing that does not work: setting VS Code's terminal.integrated.automationProfile.windows. Someone tested it and it changed nothing, because the CLI spawns its own shell rather than going through the integrated terminal. Passing that on so you don't burn an afternoon on the same red herring.

What not to do

You'll find these recommended. Don't.

• Flipping __PSLockDownPolicy under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment to turn constrained mode off.
• powershell -Version 2, or launching from a whitelisted directory to dodge the policy.
• Smuggling the command through an allowed helper with encoded arguments.

All of those defeat application control, which is usually there because somebody's audit depends on it. Getting your machine quarantined over a red error message that wasn't even breaking anything is a bad trade. And if the error is pure noise and the command exits 0, letting it scroll past while your ticket sits in the queue is a legitimate option. It's ugly, but it's honest.

The general lesson

If a PowerShell script works on your box and fails on a managed one, check the language mode before you rewrite any logic. Constrained language also hits Add-Type, most COM object use, and plenty of method calls you'd never think twice about. The error text names the method it blocked, which is a decent tell that you're hitting the mode rather than a bug in your script.

And if you maintain one of these CLIs, the fix on your side is small. Use the exit keyword instead of $host.SetShouldExit(), or guard that call behind a language-mode check. The Copilot CLI issue is still open with no merged fix that I could find, so in the meantime it's the shell switch plus a ticket.

The language mode check takes ten seconds, so it's cheap to rule in or out. I could be wrong about the details for your particular tool, but I hope this saves somebody an afternoon.