[bug] /api/processes returns empty array on Windows — Control Panel "Active Processes" shows nothing

[EightDoor]

Version

codebase-memory-mcp 0.8.1

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

On Windows, the Control Panel → "Active Processes" section is always empty, even when multiple codebase-memory-mcp.exe processes are running. On macOS/Linux the same section correctly lists all running codebase-memory-mcp processes (with PID, CPU%, RSS, elapsed time, command).

Expected: Windows should enumerate all running codebase-memory-mcp.exe processes, just like macOS/Linux does.

Actual: The "Active Processes" panel is always blank and renders the control.noProcesses placeholder ("No processes found" / "未找到进程"), making process monitoring and the "Kill" action unusable on Windows.

Reproduction

Steps

1. Install codebase-memory-mcp v0.8.1 (UI variant) on Windows 11 via the official release archive / install.ps1.
2. Start the server:

   codebase-memory-mcp serve --ui=true --port=9749

3. Open http://localhost:9749 in a browser and switch to the Control Panel tab.
4. Observe that the "Active Processes" section is empty (renders control.noProcesses).
5. Sanity-check the API directly:

   curl http://localhost:9749/api/processes

   Windows output (bug):

   {"self_pid":12345,"self_rss_mb":42.0,"self_user_cpu_s":0.1,"self_sys_cpu_s":0.0,"processes":[]}

   macOS output (correct):

   {"self_pid":67890,"self_rss_mb":38.0,"self_user_cpu_s":0.2,"self_sys_cpu_s":0.0,"processes":[{"pid":67890,"cpu":0.2,"rss_mb":38.0,"elapsed":"00:42","command":"codebase-memory-mcp","is_self":true}]}

Root cause (source-level)

src/ui/http_server.c → handle_processes() (around line 251).

The #ifdef _WIN32 branch (lines 255–275) only fills self-metrics, then hardcodes "processes":[]}:

pos += snprintf(buf + pos, sizeof(buf) - (size_t)pos,
                "{\"self_pid\":%d,\"self_rss_mb\":%.1f,"
                "\"self_user_cpu_s\":%.1f,\"self_sys_cpu_s\":%.1f,\"processes\":[]}",
                (int)_getpid(), (double)rss_bytes / (1024.0 * 1024.0), user_s, sys_s);

The #else branch (macOS/Linux, lines 276–336) correctly enumerates processes via:

FILE *fp = popen("LC_ALL=C ps -eo pid,pcpu,rss,etime,comm 2>/dev/null"
                 " | grep '[c]odebase-memory-mcp'", "r");

No equivalent enumeration is implemented in the Windows branch — it is simply missing.

Suggested fix

Replace the hardcoded "processes":[]} in the Windows branch with a CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0) enumeration, matching image filenames containing codebase-memory-mcp via GetProcessImageFileNameA (already available via <psapi.h>), then reading GetProcessMemoryInfo + GetProcessTimes per PID. Emit the same JSON shape as the macOS branch (pid/cpu/rss_mb/elapsed/command/is_self).

Related (separate bug, mentioning for visibility)

handle_process_kill in the same file wraps its child-PID whitelist check in #ifndef _WIN32, so on Windows any PID (including unrelated user processes) can be terminated via /api/process-kill. Worth filing as a separate security/correctness issue.

Environment

• codebase-memory-mcp 0.8.1 (UI variant)
• Windows 11 x64
• Install channel: GitHub release archive / install.ps1
• Confirmed not a duplicate against existing open issues.

Logs

$ curl http://localhost:9749/api/processes
{"self_pid":12345,"self_rss_mb":42.0,"self_user_cpu_s":0.1,"self_sys_cpu_s":0.0,"processes":[]}

$ tasklist /FI "IMAGENAME eq codebase-memory-mcp.exe"
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
codebase-memory-mcp.exe      12345 Console                    1     42,108 K
codebase-memory-mcp.exe      12501 Console                    1     18,420 K

(Server reports zero processes despite two running instances being clearly visible to the OS.)

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Thanks for reporting this Windows UI gap. Triage: this looks like a Windows process-enumeration bug in the local UI API. #955 is open for the fix; review should confirm it works without leaking command details and keeps the response shape stable.