feat: Add cloudflared tunnel support to MCP Process Manager

[buremba]

• Install cloudflared in worker Docker image for all CPU architectures
• Add optional port parameter to start_process MCP tool
• Automatically create cloudflared tunnel when port is specified
• Transform trycloudflare.com URLs to peerbot.ai for branding
• Pipe all process and tunnel logs to worker stdout/stderr
• Enable process monitoring by default (auto-restart on failure)
• Remove monitor_processes tool (monitoring now always enabled)
• Preserve file-based logging in /tmp/claude-logs directory

When a process is started with a port, it automatically:

1. Starts the main process
2. Launches cloudflared tunnel for the specified port
3. Extracts and returns the branded tunnel URL
4. Pipes all logs to k3s-visible worker output
5. Cleans up tunnel when process stops

🤖 Generated with Claude Code

[claude]

Claude finished @buremba's task —— View job

---

Code Review Complete ✅

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze Dockerfile.worker changes
• Review package.json and bun.lock updates
• Deep dive into process-manager-server.ts implementation
• Check for code quality and best practices
• Identify potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Consider test coverage needs
• Provide comprehensive feedback

Code Review Feedback

Overall, this is a well-implemented feature that adds valuable cloudflared tunnel functionality. The code is clean and follows good practices, but there are several areas for improvement:

✅ Strengths

• Good Architecture: Clean separation of concerns with tunnel management isolated from process management
• Proper Logging: Both file-based and stdout/stderr piping for k8s visibility
• Error Handling: Graceful tunnel startup with timeout and fallback suggestions
• Resource Management: Proper cleanup of tunnel processes when main process stops
• URL Transformation: Nice branding touch with peerbot.ai domain transformation

⚠️ Security Concerns

• Line 207: The regex /https?:\/\/([a-z0-9-]+)\.trycloudflare\.com/ could potentially match malicious URLs if cloudflared output is compromised. Consider more specific validation
• Lines 258-266, 186-194: Process termination uses SIGTERM followed by SIGKILL but doesn't validate PID ownership, potentially allowing termination of unrelated processes

🐛 Potential Bugs

• Lines 392-393: Fixed 3-second delay for tunnel URL extraction could be insufficient on slower networks. Consider making this configurable or implementing proper readiness checks
• Lines 185-194: Race condition in URL extraction timeout - if multiple tunnel processes start simultaneously, the timeout handling could interfere
• Line 211: URL transformation assumes all trycloudflare.com URLs should be transformed to peerbot.ai, but there's no validation that this domain is actually controlled by the organization

🏎️ Performance Considerations

• Lines 334-336: Default 30-second monitoring interval may be too frequent for systems with many processes. Consider making this configurable
• Line 392: Synchronous 3-second wait blocks the entire MCP tool call. Consider implementing an async callback pattern
• Lines 114-124: Stdout/stderr piping could become a memory bottleneck with high-volume output from managed processes

🧪 Code Quality & Best Practices

• Lines 180-196: The extractTimeout logic is complex and could be extracted into a separate method for better testability
• Lines 157-244: The startTunnel method is quite long (87 lines) and handles multiple responsibilities. Consider breaking it down
• Lines 198-215: The extractUrl nested function makes the code harder to test. Consider extracting as a class method
• No TypeScript strict mode: Consider enabling stricter TypeScript checking for better type safety

📋 Missing Test Coverage

The PR doesn't include tests for:

• Tunnel URL extraction and transformation logic
• Error scenarios (network failures, cloudflared not available)
• Process restart behavior with tunnels
• Concurrent tunnel creation
• Edge cases in URL regex matching

🔧 Suggested Improvements

1. Add validation for extracted tunnel URLs before transformation
2. Make timeouts configurable via environment variables or constructor parameters
3. Extract complex logic into smaller, testable methods
4. Add retry logic for tunnel establishment failures
5. Implement proper health checks instead of fixed delays
6. Add unit tests for the new tunnel functionality
7. Consider adding metrics for tunnel success/failure rates

📁 File-Specific Notes

Dockerfile.worker:23-32: Excellent multi-architecture cloudflared installation approach with proper fallback to amd64.

process-manager-server.ts:384: Good addition of the optional port parameter to the MCP tool schema.

The implementation successfully achieves the goal of automatic tunnel creation with proper cleanup and logging. With the suggested improvements, particularly around security validation and testing, this would be production-ready code.

---