Codex invoke_expression dispatch fails with unsupported call on 1.12.0

[sharpninja]

Summary

Codex Desktop can start the PowerShell.MCP server from PowerShell.MCP 1.12.0 and can run non-expression tools such as console startup and current-location discovery, but expression execution fails at the MCP tool dispatch layer before any PowerShell pipeline runs.

Environment

• OS: Windows 11, Microsoft Windows NT 10.0.26200.0
• Host: PAYTON-LEGION2
• PowerShell: 7.6.3 from Microsoft Store WindowsApps package
• PowerShell.MCP installed versions: 1.12.0, 1.11.0, 1.8.0
• Active Codex MCP server command: C:\Users\kingd\OneDrive\Documents\PowerShell\Modules\PowerShell.MCP\1.12.0\bin\win-x64\PowerShell.MCP.Proxy.exe
• 1.12.0 proxy product version: 1.12.0.0+edec71c29d58e183c13912e7ec58e6dac84e3c2a

Observed behavior

Codex tool calls:

• mcp__powershell.start_console succeeds and reports PowerShell.MCP module imported.
• mcp__powershell.get_current_location succeeds.
• mcp__powershell.invoke_expression fails before the PowerShell script executes.

Exact returned error:

unsupported call: mcp__powershellinvoke_expression

The error also occurs for a minimal expression:

probe

Expected behavior

mcp__powershell.invoke_expression should execute the provided PowerShell pipeline in the persistent PowerShell console, or return a structured MCP error that includes enough information to distinguish proxy dispatch failure from PowerShell runtime failure.

Diagnostics performed

• Verified Codex config points to the 1.12.0 proxy executable.
• Verified PowerShell.MCP 1.12.0 is installed and proxy exists.
• Checked Windows Event Viewer logs around the failure window. No PowerShell stack trace or application crash was recorded for the unsupported call failure. PowerShell Operational logs only showed normal console startup and ready events.
• The failure appears to occur before a PowerShell pipeline reaches the runtime.

Impact

This blocks Codex from using PowerShell.MCP for required shell execution because the main command execution tool cannot run expressions.

[yotsuda]

Thanks for the detailed report — and sorry for the time this cost you. The cause is a rename we shipped, not a dispatch bug.

invoke_expression was renamed to execute_command in 1.12.0 (CHANGELOG → 1.12.0 → Behavior Changes). The old name implied the Invoke-Expression cmdlet — which the tool never actually used — and tripped AMSI / antivirus heuristics. Behavior and the pipeline parameter are unchanged. The server advertises exactly six tools: execute_command, start_console, close_console, cancel, wait_for_completion, get_current_location.

Narrowing down where the old name is coming from: unsupported call: ... does not appear anywhere in this codebase, so the call is being rejected on the client side before it reaches the proxy — consistent with your finding that no pipeline runs and nothing lands in the event logs. And since start_console and get_current_location work, Codex is receiving tools/list correctly and can see the current six names. So the stale invoke_expression almost certainly comes from something pinned in your setup rather than a cache: an MCP tool allowlist / approved-tools entry, or an agent instruction file naming the tool. Updating that to execute_command and restarting Codex Desktop should be the whole fix.

Two things I'd like to check:

1. The failing name reads mcp__powershellinvoke_expression — no separator, where the working ones are mcp__powershell.start_console. Is that a transcription artifact in this issue, or literally the string in your config / the error? If it's literal, there may be a second problem worth fixing independently of the rename.

2. On 1.11.0 / 1.8.0, invoke_expression did still exist, so I'd expect a different failure there. You list the proxy as 1.12.0.0 — my guess is those runs were still effectively 1.12.0, either because the MCP client config stores an absolute, version-pinned proxy path (...\Modules\PowerShell.MCP\<version>\bin\<rid>\PowerShell.MCP.Proxy.exe) that a module downgrade doesn't update, or because Import-Module PowerShell.MCP without -RequiredVersion loads the newest installed version. Can you confirm how you downgraded? If you downgrade again, re-run the registration command so the pinned proxy path follows the module.

On shipping a compatibility alias: I'd rather not, for two reasons. Re-advertising invoke_expression in tools/list would put back the exact token that got the module flagged in the first place (#50) — that's what the rename existed to remove. And it would recreate a two-name surface spanning the MCP tool layer, the named-pipe wire protocol, and the DTOs; 1.12.0 deliberately finished the rename through all of those ("Completed the execute_command rename through the Named Pipe wire protocol, DTOs, and handlers"), so an alias would reopen the split that release closed.

I also can't improve the error itself: an unknown tool name is rejected by the client before it reaches the proxy, so nothing on our side runs. What I can improve is discoverability — was the 1.12.0 CHANGELOG entry findable for you, or would a note in the README's tool list have caught this sooner?

[sharpninja]

I have pinned my agents to 1.11.0. Have you made any progress on this?

[yotsuda]

As I said in my previous reply, this is the 1.12.0 rename: invoke_expression became execute_command. There is nothing here for a release to fix.

But here is one thing worth trying, which I should have suggested last time. Go back to 1.14.0 and tell the agent in the prompt: "the tool name invoke_expression is wrong, the correct name is execute_command" — then have it run something.

Codex reads the tool names from the server at startup, which is why start_console and get_current_location work. So the old name is in what your agent has been told, not in your config, and saying the right name in the prompt overrides it.

If that works, name execute_command in AGENTS.md or wherever your agent instructions live, so it sticks — whether the old name is written there or the model is just recalling it from before the rename. If it still fails, post the exact error and what Codex lists as this server's tools; that shows whether Codex sees the current names at all.

(You've registered the server as powershell while the README suggests pwsh — your choice, it makes no difference here; I'm just writing tool names as pwsh.execute_command.)

[sharpninja]

I've updated my environment to 1.14.0. I'll let you know if this fixes it or causes other issues.