ProxmoxMCP-Plus v0.5.8

Release date: 2026-06-07

Windows SSH Compatibility Fixes (Issue #100)

This release fixes four critical bugs that prevented execute_container_command and get_node_status from working correctly on Windows 11 with Claude Code (VS Code extension). All bugs are also observable on any platform that runs the MCP server headless without a TTY.

Bug 1 - SSH command never includes the username

• File: src/proxmox_mcp/tools/console/container_manager.py
• Method: _execute_via_system_ssh()
• Impact: execute_container_command never worked on Windows out of the box.

_execute_via_system_ssh() correctly read key_file and port from the SSH config, but never added the user field. On Linux, SSH often defaults to the current system user which may match. On Windows, SSH falls back to the Windows login name (e.g. manta), which has no access to the Proxmox host. The command silently timed out after 70 seconds on every call.

Fix: Explicitly pass -l <user> to the OpenSSH command so behaviour is consistent across platforms.

Bug 2 - SSH subprocess hangs because stdin is not closed (Windows-specific)

• File: src/proxmox_mcp/tools/console/container_manager.py
• Method: _execute_via_system_ssh()
• Impact: 70-second hang on every execute_container_command call on Windows.

subprocess.run with capture_output=True only redirects stdout and stderr. stdin was inherited from the parent process, which in the case of an MCP server is a pipe connected to Claude Code. On Windows, OpenSSH read from this inherited stdin and blocked indefinitely, even when -o BatchMode=yes was set. This did not reproduce on Linux.

Fix: Pass stdin=subprocess.DEVNULL to close stdin at the OS level before SSH starts.

Bug 3 - SSH hangs waiting for interactive prompts when running headless

• File: src/proxmox_mcp/tools/console/container_manager.py
• Method: _execute_via_system_ssh()
• Impact: Hangs on first connection or unknown hosts when running headless.

_execute_via_system_ssh() did not pass -o BatchMode=yes to SSH. When the MCP server runs headless (no TTY attached), SSH waited indefinitely for interactive input such as host key confirmation prompts or password prompts.

Fix: Pass BatchMode=yes and StrictHostKeyChecking=accept-new so SSH fails fast on prompts and silently trusts first-seen host keys.

Bug 4 - get_node_status always shows Status: UNKNOWN and CPU Cores: N/A

• Files:
  • src/proxmox_mcp/tools/node.py
  • src/proxmox_mcp/formatting/templates.py
• Impact: Status and CPU fields were always wrong regardless of node health.

Problem A: templates.py node_status() reads status.get('status', 'unknown'). The Proxmox API endpoint GET /nodes/{node}/status does not include a status field in its response. That field only exists in the node list endpoint GET /nodes. Status always fell back to 'unknown'.

Fix A: Inject "status": "online" into the result in get_node_status when missing. A successful API response is itself proof the node is reachable.

Problem B: The template read status.get('maxcpu', 'N/A') for the CPU core count. The node status API does not return a top-level maxcpu field. The CPU count is nested under cpuinfo.cpus.

Fix B: Update the template to read the correct nested field, with maxcpu as a forward-compatibility fallback.

Tests

• Added 5 regression tests in tests/test_container_console.py covering all three SSH fixes (-l user, stdin=DEVNULL, BatchMode/accept-new).
• Added 3 regression tests in tests/test_server.py covering the missing status injection, the cpuinfo.cpus CPU cores path, and the maxcpu fallback.
• Full test suite: 185 passed, 1 skipped (pre-existing).

Runtime Impact

• No public API, MCP tool surface, or configuration schema changed.
• No migration is required from v0.5.7.
• All changes are pure bug fixes for Windows / headless environments; behaviour on Linux/POSIX is unchanged for users who already had a working configuration.

Upgrade Notes

• Upgrade normally from PyPI, Docker/GHCR, or source.
• Windows users running the MCP server through Claude Code, Cursor, or any other headless client should immediately see execute_container_command and get_node_status work as expected.