MCP Debugger

# JavaScript Docker Debugging - Final Summary ## Overview We've been working to fix JavaScript debugging in Docker, which was failing with "Proxy exited during initialization. Code: 1, Signal: SIGTERM" errors. ## Changes Implemented ### 1. Centralized Path Resolution - **File**: `src/utils/container-path-utils.ts` - Created a centralized path resolution utility that: - Checks for container mode using `MCP_CONTAINER` environment variable - Resolves paths consistently using `MCP_WORKSPACE_ROOT` - Handles both relative and absolute paths properly - No longer does any "smart" path transformations ### 2. Server Path Handling - **File**: `src/server.ts` - Updated to use the centralized path resolution: - All path-related tool handlers now use `resolvePathForRuntime()` - Consistent environment passing to SessionManager - Paths are resolved before file existence checks and before passing to adapters ### 3. SimpleFileChecker Updates - **File**: `src/utils/simple-file-checker.ts` - Updated to use the new container path utilities - Removed manual path prefixing logic - Now logs both original and resolved paths for debugging ### 4. JavaScript Adapter Cleanup - **File**: `packages/adapter-javascript/src/javascript-debug-adapter.ts` - Removed all container-specific path handling - Fixed working directory issue: - Now uses `/workspace` as default in container mode instead of `/` - Properly derives cwd from program path when in container ### 5. Docker Configuration - **File**: `Dockerfile` - Added `tini` init system for proper signal handling - Configured as entrypoint to prevent orphan processes - Set proper environment variables (`MCP_CONTAINER=true`, `MCP_WORKSPACE_ROOT=/workspace`) ## Current Status ### What's Working ✅ Path resolution is centralized and consistent ✅ Python debugging works perfectly in Docker ✅ File existence checks work correctly ✅ Environment variables are properly set ✅ Node.js is available in the container ✅ js-debug vendor files are present and accessible ✅ Tini is installed and configured for signal handling ✅ Working directory is now correctly set to `/workspace` for JavaScript ### Still Not Working ❌ JavaScript debugging still fails with SIGTERM during proxy initialization ## Root Cause Analysis The proxy process starts successfully but immediately receives SIGTERM. The sequence is: 1. Proxy worker starts 2. Signal handlers are installed 3. Proxy receives init command 4. SIGTERM is received immediately 5. Proxy exits with code 1 This suggests the issue is not with: - Path resolution (paths are correct) - File access (files are accessible) - Working directory (now correctly set) - Signal handling (tini is in place) ## Possible Remaining Issues 1. **js-debug Adapter Compatibility**: The vendored js-debug adapter might have issues running in the Docker container environment. 2. **Process Launch Configuration**: The way the proxy is launching the js-debug process might be incompatible with the container environment. 3. **Resource Constraints**: The container might be hitting memory or other resource limits. 4. **Node.js Version Mismatch**: There might be a compatibility issue between the Node.js version in the container and the js-debug adapter. ## Next Steps 1. **Deep Debug the Proxy**: - Add more detailed logging in the proxy to see exactly what command is being executed - Log the full environment variables being passed to js-debug - Check if js-debug is actually starting before the SIGTERM 2. **Test js-debug Directly**: - Try running the js-debug adapter directly in the container without the proxy - This will help determine if the issue is with js-debug or the proxy 3. **Check Resource Usage**: - Monitor memory usage during proxy startup - Check if there are any ulimits or other constraints 4. **Alternative Approach**: - Consider using a different Node.js debugging approach in containers - Perhaps use the built-in Node.js inspector protocol directly ## Files Modified - `src/utils/container-path-utils.ts` - New centralized path utilities - `src/server.ts` - Updated to use new path resolution - `src/utils/simple-file-checker.ts` - Updated to use new utilities - `packages/adapter-javascript/src/javascript-debug-adapter.ts` - Removed path logic, fixed cwd - `Dockerfile` - Added tini for signal handling - Various test and documentation files ## Testing Created several test scripts: - `scripts/test-js-docker-debug.cjs` - Basic Docker debugging test - `scripts/test-js-docker-debug-detailed.cjs` - Detailed test with multiple path formats Both Python and JavaScript debugging work correctly on the host. Only JavaScript debugging fails in Docker. ## Conclusion We've successfully: 1. Centralized and simplified path handling 2. Ensured consistent behavior across the codebase 3. Fixed the working directory issue 4. Added proper signal handling However, the JavaScript debugging in Docker still fails due to the proxy receiving SIGTERM during initialization. This appears to be a deeper issue with either the js-debug adapter itself or how it's being launched in the container environment. The path handling improvements make the codebase more maintainable and consistent, even though they haven't resolved the immediate JavaScript Docker debugging issue.