SSH MCP Server

/** * Command Execution Path Debug Test * * PURPOSE: Debug exactly which execution path MCP commands are taking and why * subsequent commands are not executing. */ import { EnhancedCommandParameter } from './integration/terminal-history-framework/post-websocket-command-executor'; describe('Command Execution Path Debug', () => { /** * TEST: Verify command parsing for MCP commands */ describe('Command Parsing Verification', () => { it('should correctly parse ssh_exec commands as MCP commands', () => { // Test command parsing logic // Test command parsing - this should be an MCP command const testCommand = 'ssh_exec {"sessionName": "test", "command": "whoami"}'; // Since parseCommand is private, let's test the public interface behavior // The command should be converted to { initiator: 'mcp-client', command: '...' } const enhancedCommand: EnhancedCommandParameter = { initiator: 'mcp-client', command: testCommand }; expect(enhancedCommand.initiator).toBe('mcp-client'); expect(enhancedCommand.command).toContain('ssh_exec'); expect(enhancedCommand.command).toContain('whoami'); }); }); /** * TEST: Check if the issue is in the Command State Synchronization logic */ describe('Command State Synchronization Logic Analysis', () => { it('should identify if browserCommandsExecuted flag is causing the blocking', () => { // Create a mock scenario to test the logic // According to the source code, the problematic logic is: // if (this.browserCommandsExecuted && !this.config.enableSequentialExecution) { // success = false; // error = 'BROWSER_COMMANDS_EXECUTED'; // commandExecutionPromise = Promise.resolve(false); // } // Test case 1: browserCommandsExecuted = false, enableSequentialExecution = false // This should allow MCP commands to execute let browserCommandsExecuted = false; let enableSequentialExecution = false; let shouldBlock = browserCommandsExecuted && !enableSequentialExecution; expect(shouldBlock).toBe(false); // Should not block // Test case 2: browserCommandsExecuted = true, enableSequentialExecution = false // This should block MCP commands (intended behavior when browser commands were used) browserCommandsExecuted = true; enableSequentialExecution = false; shouldBlock = browserCommandsExecuted && !enableSequentialExecution; expect(shouldBlock).toBe(true); // Should block // Test case 3: browserCommandsExecuted = true, enableSequentialExecution = true // This should allow MCP commands even after browser commands browserCommandsExecuted = true; enableSequentialExecution = true; shouldBlock = browserCommandsExecuted && !enableSequentialExecution; expect(shouldBlock).toBe(false); // Should not block // HYPOTHESIS: The issue is that browserCommandsExecuted is getting set to true incorrectly // when it should remain false for MCP-only command sequences }); }); /** * TEST: Verify MCP command execution timeout behavior */ describe('MCP Command Timeout Analysis', () => { it('should identify if MCP commands are incorrectly waiting for browser completion', async () => { // The key insight: MCP commands should NOT wait for WebSocket completion detection // They should complete based on the MCP response, not WebSocket prompt detection // From the code, MCP commands should: // 1. Call this.mcpClient.callTool(toolName, args) // 2. Get a response directly from MCP // 3. Set success = mcpResponse.success // 4. NOT wait for WebSocket prompt patterns // The bug might be that MCP commands are somehow going through the browser code path // which includes waitForCommandCompletion() and WebSocket prompt detection const mcpCommandFlow = { shouldUseWebSocketCompletion: false, shouldUseMCPDirectResponse: true, shouldWaitForPrompts: false }; expect(mcpCommandFlow.shouldUseWebSocketCompletion).toBe(false); expect(mcpCommandFlow.shouldUseMCPDirectResponse).toBe(true); expect(mcpCommandFlow.shouldWaitForPrompts).toBe(false); // If MCP commands are going through browser completion logic, that's the bug }); }); /** * TEST: Identify the exact execution flow issue */ describe('Execution Flow Issue Identification', () => { it('should trace the logical execution path for sequential MCP commands', () => { // HYPOTHESIS: The issue is in the execution sequencing, not command state synchronization // Expected flow for our test: // 1. First MCP command: ssh_exec pwd - should execute via MCP client, complete immediately // 2. Second MCP command: ssh_exec whoami - should execute via MCP client, complete immediately // Potential issues: // 1. Commands are being routed to browser path instead of MCP path // 2. MCP commands are incorrectly waiting for WebSocket completion // 3. Inter-command delay is causing problems // 4. WebSocket connection is interfering with MCP execution const potentialIssues = { incorrectRouting: 'MCP commands routed to browser execution path', incorrectCompletion: 'MCP commands waiting for WebSocket completion instead of MCP response', timingIssue: 'Inter-command delay or WebSocket interference', stateCorruption: 'Command execution state getting corrupted between commands' }; // Based on test results, the most likely issue is incorrectCompletion expect(potentialIssues.incorrectCompletion).toContain('WebSocket completion'); }); }); /** * TEST: Analyze the inter-command delay impact */ describe('Inter-Command Delay Analysis', () => { it('should verify if delays are causing execution issues', () => { // From the source code, there's a 1000ms delay between commands: // if (command !== commands[commands.length - 1]) { // await this.delay(this.config.interCommandDelay); // } const defaultInterCommandDelay = 1000; // ms const commandTimeout = 30000; // ms // With our test having 2 commands: // - Command 1: executes immediately // - Delay: 1000ms // - Command 2: should execute after delay // Total expected time: execution + delay + execution should be < 30s timeout const expectedMaxTime = (2 * 5000) + defaultInterCommandDelay; // 11 seconds max expect(expectedMaxTime).toBeLessThan(commandTimeout); // The delay itself shouldn't cause timeout, so the issue is elsewhere }); }); });