Limit the number of idle/standby PowerShell consoles (default: 10)

[doraemonkeys]

Is your feature request related to a problem? Please describe.
When using multiple projects, or spawning multiple sub-agents in the same project, PowerShell.MCP can keep opening new
visible PowerShell windows on Windows.

Over time, the desktop fills up with standby consoles that are no longer actively used. This becomes especially
noticeable in long-running agent workflows.

From reading the implementation, this appears to be a lifecycle / resource-management gap rather than just a UX
preference:

• start_powershell_console only reuses an existing standby console when reason is empty.
• If reason is provided, it always forces a new console.
• On Windows, new sessions are launched with CREATE_NEW_CONSOLE, so each additional session becomes a visible
  window.
• I could not find a limit or eviction policy for idle/standby consoles.

Describe the solution you'd like
Add a configurable maximum number of idle/standby consoles, with a default of 10.

Suggested behavior:

• Never terminate busy consoles.
• Reuse an existing standby console whenever possible.
• If the standby pool is already at the limit, either:
  • reuse one of the existing standby consoles, or
  • close the oldest / least-recently-used standby console before creating a new one.
• Ideally this limit should apply globally across PowerShell.MCP instances on the machine, or at least per proxy
  process if global coordination is too large for now.

Describe alternatives you've considered

• Manually closing extra windows.
• Avoiding reason so reuse can happen, but some agent/sub-agent workflows still need isolated sessions and can
  accumulate many windows.
• Hiding windows on Windows, but that only masks the symptom; pool lifecycle control seems like the root fix.

Additional context
This issue is much more visible on Windows because every additional session is a visible terminal window.

[yotsuda]

@doraemonkeys Thank you for the detailed analysis and suggestion.

We've addressed the core problem in v1.7.4 with a different approach than a hard pool cap:

1. Proxy liveness detection
Consoles now monitor their parent proxy PID every ~5 seconds. When a proxy process dies (e.g., the AI client is closed), the console automatically reverts to unowned state and becomes available for the next proxy to claim. This prevents orphaned consoles from accumulating across sessions.

2. Stricter reason parameter guidance
The reason parameter description now explicitly tells LLMs not to specify it unless a separate console is genuinely needed. This reduces unnecessary console creation.

3. Visual state indicator
Unowned consoles display #PID ____ in the window title. When claimed by a proxy, the title updates to #PID Name (e.g., #1234 Sparrow). This makes it easy to identify which consoles are active vs. waiting.

We chose this approach over a configurable pool cap because:

• The main source of accumulation was orphaned consoles from dead proxies, which is now handled automatically
• When reason is omitted, the proxy now prefers reusing an existing standby console rather than creating a new one
• A hard cap risks terminating consoles that still hold useful state (loaded modules, environment variables, authentication)

Tip: Reduce desktop clutter with Windows Terminal tabs
If you use Windows Terminal, you can configure new consoles to open as tabs in the same window instead of separate windows. Go to Settings > Startup > New instance behavior and set it to "Attach to the most recently used window". This way, even when multiple consoles are created, they appear as tabs rather than filling your desktop with windows.

If you still experience excessive console accumulation after upgrading, please let us know your scenario and we can revisit the pool cap idea.

[doraemonkeys]

@yotsuda

Thank you for working on this.

Just a design question, not a request for #40, and the current behavior is fine for me.

When an idle/standby console is later reused or reclaimed by another LLM/agent, is it intentional that the previous
session state remains available? I can see that being useful in the same project, so I’m not suggesting it should be
reset. I was only wondering whether “sticky session state” is the intended model, or whether an optional clean
handoff/reset was ever considered for the future. No action needed if the current behavior is intentional.

[yotsuda]

Good question. The current behavior — session state persisting across reuse — is intentional.

The main reasons:

• PowerShell.MCP assumes the same user on the same machine, so the security concern is low
• Modules installed and authenticated in the previous session (Az, AWS.Tools, etc.) remain available, which is often a benefit

That said, we don't rule out offering an optional session reset in the future. However, fully resetting PowerShell session state is technically challenging:

• Remove-Module can leave incomplete state for some modules (.NET assemblies cannot be unloaded from the AppDomain)
• Global variables and functions can be enumerated and removed, but internal state held by modules is beyond our control

The simplest way to get a clean state is to close the console window. A new console will be launched automatically on the next tool call.

We'll keep the current behavior for now. If you encounter a scenario where inherited session state causes problems, feel free to open a new issue.