v1.14.0

Behavior Changes

• A blocking call is now capped to what the connected MCP client will actually wait for. The timeout_seconds you pass to execute_command (and wait_for_completion) is silently reduced to a ceiling picked from the client's identity in the MCP handshake: 170s for Claude Code, which was measured not to abort a long call in its default configuration, and 50s for every other or unidentified client. 50 sits below the 60s default request timeout the MCP SDK ships with, so a client that has not overridden it cannot give up before the module answers. The ceiling is a deadline measured from the start of the call, not a budget for the pipeline alone — console discovery, claiming, and above all a cold console spawn are charged against it, so whatever that setup cost turns out to be is subtracted before the pipeline starts — a command dispatched after a 15s spawn gets the remaining 35s, and the spawn is what it is on the day (never less than 5s is granted). Nothing is lost when the cap bites: the command keeps running and its result is cached for the next tool call, exactly as with a timeout_seconds you set yourself. If you know your client waits longer, override with POWERSHELL_MCP_TIMEOUT_CEILING (seconds, still capped at 170). Unlike the standby-reap variables, this one is read by the proxy, so your MCP client's env block is the right place for it.

Bug Fixes

• A finished command's output is no longer lost when the MCP client gives up on the call. If the client timed out — or you cancelled — a tool call, and the pipeline then finished normally before the module's own timeout, the module had already emptied the console's cache into a response that no longer had anywhere to land. The result was gone for good, even though the command had succeeded and its output was sitting visible in the console; only the AI's copy was destroyed, and no later tool call could recover it. The proxy now notices the cancellation and pushes that response back into the console's cache — or onto another of the agent's live consoles, if the original one is gone by then — so the next tool call delivers it, led by a note that explains why it arrives late and warns that anything it says about waiting, cancelling, or closing a console is a snapshot from that moment which may no longer apply. This covers every client that sends notifications/cancelled, which Claude Code does — including when its own tool timeout fires, not just on an explicit stop. It is a net rather than the primary defence: for a client that abandons a call silently, keeping the module's timeout below the client's (see the ceiling above) is what actually guarantees delivery.
• Get-MCPOwner no longer reports a Claude Code session as Claude Desktop. Both are a process named claude — claude.exe on Windows, Claude on macOS — and the client was identified by process name before path, so the Desktop branch swallowed every Claude Code session. (It only began to: the CLI used to be an npm install and matched on node, until it became a standalone binary.) The install path now decides — ...\AnthropicClaude\... or /Applications/Claude.app/... is Desktop, a standalone claude is the CLI. This value is displayed, never branched on; the timeout ceiling above identifies the client from the MCP handshake instead, which is why it was unaffected.

Internal

• The Named Pipe protocol gains a cache_output request, used by the proxy to hand a console back the response it could not deliver. It is handled before the busy gate, since by the time a pushback arrives the console is often already running the next command. execute_command and wait_for_completion are each split into a thin [McpServerTool] shell and a core handler, so the busy auto-route recursion re-enters the core and a nested call cannot stash its own slice of a response the outer call is about to stash whole.

Security

• The bundled .NET runtime is pinned to a patched 9.0.19 build. The proxy binaries shipped in bin/* are self-contained, so they carry their own copy of the .NET runtime rather than using the machine's. That copy moves from 9.0.18 to 9.0.19, picking up fixes for three .NET advisories flagged against this repo (CVE-2026-62899, CVE-2026-62901, CVE-2026-62909). None of the three is reachable in normal use of this module. The first two are HTTP stack issues (request smuggling and a network denial of service), and the proxy speaks stdio and local named pipes only, with no HTTP client or listener anywhere in it. The third is a local elevation of privilege caused by an improper ACL on .NET's diagnostics channel, which every .NET process creates by default; exploiting it requires an attacker who can already sign in to the same machine. No configuration change is needed, updating the module replaces the bundled binaries.