Windows support: CGO/tree-sitter build fails — WSL2 workaround included #1

Problem

Building on Windows fails with MinGW-w64 gcc:

# github.com/tree-sitter/tree-sitter-python/bindings/go
cgo: cannot parse $WORK\b165\_cgo_.o as ELF, Mach-O, PE or XCOFF

This happens with both Go 1.23 and Go 1.25 on Windows (amd64). The README correctly states "Windows: Not currently supported", but there is a straightforward workaround.

Environment

• Windows 11 (MINGW64_NT-10.0-26100)
• Go 1.25.7 windows/amd64 (also tested with Go 1.23.0 via GOTOOLCHAIN)
• gcc (MinGW-w64 x86_64-w64-mingw32, 13.3.0) — produces COFF object files
• CGO_ENABLED=1, CC explicitly set to MinGW gcc

Root Cause

Go's CGO toolchain cannot parse the COFF object files produced by MinGW-w64 gcc on Windows. It expects ELF, Mach-O, PE, or XCOFF but gets raw COFF from the tree-sitter C compilation step.

WSL2 Workaround (confirmed working)

Build the Linux binary inside WSL2 and run it via wsl.exe:

# 1. Install Ubuntu in WSL2
wsl --install -d Ubuntu

# 2. Install build tools (inside WSL Ubuntu)
sudo apt install build-essential
# Install Go 1.23+ (apt default may be too old)
curl -sL https://go.dev/dl/go1.23.6.linux-amd64.tar.gz | sudo tar -C /usr/local -xzf -
export PATH=/usr/local/go/bin:$PATH

# 3. Build (from WSL, accessing Windows filesystem)
cd /mnt/c/path/to/codebase-memory-mcp
CGO_ENABLED=1 go build -buildvcs=false -o codebase-memory-mcp ./cmd/codebase-memory-mcp/

# 4. Copy binary to WSL PATH
sudo cp codebase-memory-mcp /usr/local/bin/

Note: -buildvcs=false is needed because git status doesn't work correctly across the WSL/Windows filesystem boundary.

Claude Code MCP config (.claude.json)

{
  "mcpServers": {
    "codebase-memory-mcp": {
      "type": "stdio",
      "command": "wsl.exe",
      "args": ["-d", "Ubuntu", "--", "codebase-memory-mcp"]
    }
  }
}

This works perfectly — the server starts via WSL and communicates over stdio as expected.

Suggestion

Consider adding the WSL2 workaround to the README under the Windows section, since it is a reliable solution that takes about 5 minutes to set up.