Commit Helper MCP

# Design Options: Repository Context Management ## Option 1: Modify MCP Context to Include Repository Information ### Approach - Extract repository information from the MCP context - Use this as the default when no explicit `repo_path` is provided - Require MCP clients to send repository context ### Pros - Leverages existing MCP protocol - Client can provide rich context information - No global state in the server ### Cons - Requires changes to MCP clients - Not all clients may support this - Adds complexity to the MCP protocol - Still allows arbitrary path access ## Option 2: Make Repository Parameter Optional in All Tools ### Approach - Update all tool definitions to make `repo_path` optional - Rely on the existing fallback mechanism in `RepositoryManager` - No changes to the underlying architecture ### Pros - Minimal changes required - Maintains backward compatibility - Leverages existing code ### Cons - Doesn't centralize repository context - Each tool must handle the optional parameter - Limited context sharing between tools - Security risks remain ## Option 3: Create a Global Context Provider ### Approach - Create a singleton provider for repository context - Detect context when the MCP server starts - Have all tools use this by default ### Pros - Centralized repository context - Consistent behavior across all tools - Rich context information available ### Cons - Introduces global state - Potential testing challenges - Singleton pattern has known issues - Still allows path overrides ## Option 4: Thread-Local Context Provider ### Approach - Create a thread-local singleton for repository context - Each thread gets its own isolated context - Combine with testing hooks for easy testing ### Pros - Thread safety for parallel execution - Isolated testing without interference - Centralized repository context - Consistent behavior across all tools ### Cons - More complex implementation - Requires careful management in tests - Still uses singleton pattern (though thread-local) - Security concerns remain with path flexibility ## Option 5: Security-Focused CWD-Only Operations (Recommended) ### Approach - Remove all `repo_path` parameters from tools - Eliminate environment variable support - Restrict all operations to current working directory - Simplify architecture by removing path resolution ### Pros - **Maximum Security**: Eliminates path traversal vulnerabilities - **Simplest Implementation**: No complex path resolution - **Clear Mental Model**: Always operates on CWD - **Easier Testing**: No path mocking needed - **Smaller Codebase**: Remove significant complexity ### Cons - **Breaking Change**: Not backward compatible - **Less Flexible**: Users must change directories - **Multi-Repository Workflows**: Require explicit `cd` commands ## Evaluation After evaluating all options, **Option 5: Security-Focused CWD-Only Operations** is recommended because it: 1. **Eliminates Security Risks**: No possibility of accessing arbitrary directories 2. **Simplifies Architecture**: Removes all path resolution complexity 3. **Provides Clear Behavior**: Always operates on current directory 4. **Reduces Code Complexity**: Significant codebase simplification 5. **Improves Maintainability**: Less code to maintain and test While Options 1-4 provide various levels of flexibility, they all maintain the fundamental security risk of allowing operations on arbitrary filesystem locations. Option 5 trades this flexibility for security and simplicity, which aligns with security best practices. ## Comparison Matrix | Feature | Option 1 | Option 2 | Option 3 | Option 4 | Option 5 | |---------|----------|----------|----------|----------|----------| | Security | Low | Low | Low | Low | **High** | | Simplicity | Medium | High | Medium | Low | **High** | | Flexibility | High | High | High | High | Low | | Breaking Change | No | No | No | No | Yes | | Testing Complexity | Medium | Low | Medium | High | **Low** | | Code Reduction | None | Minimal | Some | Some | **Significant** |