`doctor --fix` leaves multiple MCP processes running after `stop` on Windows

[keitharoby-byte]

Summary

On Windows, multiple agent-launched Memtrace MCP processes remained alive after running npx memtrace stop followed by npx memtrace doctor --fix.

doctor --fix detected 29 running memtrace.exe processes and warned that multiple owners or stray MCP children could contend for port 3030 and .memdb, but it did not stop those processes. The resulting overhead caused severe system and Electron UI lag; manual shutdown was required to recover.

Environment

• Windows
• Memtrace v0.8.62
• Update available at the time: v0.8.63
• Multiple editor/agent MCP integrations configured

Steps to reproduce

1. Use several concurrent agent sessions that invoke Memtrace MCP tools.
2. Run:

   npx memtrace stop

3. Run:

   npx memtrace doctor --fix

4. Inspect the process list and doctor output.

Actual behavior

• memtrace stop stopped the workspace runtime/sidecars but reported that MCP servers spawned by editor or agent clients were outside its scope.
• memtrace doctor --fix reported 29 running memtrace.exe processes.
• Doctor warned that multiple owners or stray MCP children could fight over port 3030 and .memdb.
• Doctor also reported a stale PID/failed HTTP health check and an OS supervisor artifact that could not be stopped because the service was not installed.
• The surviving processes caused enough overhead and input lag to make an Electron-based agent harness effectively unusable.

Expected behavior

There should be a supported, safe shutdown/update workflow that can terminate orphaned or stray Memtrace MCP processes, or an explicit command for stopping all Memtrace-owned processes across editor/agent sessions.

At minimum, doctor --fix should either clean up processes it identifies as stale/orphaned or clearly report which active external supervisors must be closed and provide the exact remediation command.

Sanitized diagnostic excerpt

memtrace doctor (v0.8.62)

Processes
  29 memtrace.exe processes detected

Findings
  Multiple owners or stray MCP children can fight over port 3030 and .memdb.
  Heartbeat alive but HTTP health check failed.

Fixes applied
  Stopped 0 of 1 OS supervisor artifact(s).
  Supervisor stop failed because the service was not installed.

The original diagnostic output contained local usernames, workspace names, and machine-specific paths, so it has intentionally not been attached.

[blocksorg]

Mention Blocks like a regular teammate with your question or request:

@blocks can you add technical details to this issue?
@blocks make the following changes ...
@blocks create an issue from what was mentioned in the following comment ...
@blocks explain the following code ...
@blocks are there any security or performance concerns?

Run @blocks /help for more information.

Workspace settings | Disable this message

[keitharoby-byte]

@blocks please review this issue against the current Memtrace source and report your findings before making any changes.

Please:

1. Trace the Windows code paths for memtrace stop and memtrace doctor --fix.
2. Identify how memtrace mcp child processes are spawned, owned, tracked, and classified as active versus stale/orphaned.
3. Explain why doctor --fix detects many memtrace.exe processes but appears to remediate only the OS supervisor artifact.
4. Identify the relevant source files, functions, and tests, including any duplicated process-discovery or cleanup logic.
5. Assess the safest fix. Do not recommend blindly killing active MCP sessions owned by editors or agents; distinguish safe orphan cleanup from an explicit emergency/all-process shutdown workflow.
6. Compare this report with doctor --fix leaves 29 Memtrace processes running and does not remediate its own finding on Windows #59, which appears to describe the same incident, and recommend which issue should remain canonical.
7. Return a concise root-cause assessment, proposed implementation plan, risks, and test cases.

Review and planning only for now; please do not implement or open a pull request yet.

[blocksorg]

Unable to fulfill this request because your GitHub account is not associated with this workspace.

Link your account in workspace settings

[keitharoby-byte]

Follow-up: reproduced on v0.8.63 with runaway/inconsistent graph accounting

This is a current-revision recurrence and expands the impact beyond the original v0.8.62 process-cleanup report.

Environment

• Windows
• Global npm package: memtrace@0.8.63
• CLI: memtrace 0.8.63
• One local MemDB listener on 127.0.0.1:50051
• Multiple concurrent editor/agent MCP integrations
• Sanitized paths and process IDs omitted

Current process state

A read-only process inventory found:

• 30 memtrace.exe processes
• 4 memcortex-mcp.exe processes
• 1 memcore-server.exe
• 1 memcortex-daemon.exe
• Additional Node/cmd wrapper processes

Approximate aggregate private memory:

• memtrace.exe: 43.86 GB
• MemDB server: 6.00 GB
• Cortex MCP processes: 2.49 GB
• Cortex daemon: 1.45 GB

This is substantially the same surviving multi-process condition described in the original issue, now on 0.8.63.

New graph-growth symptom

The runtime also began continuously generating nodes while the indexed source identity and source-change evidence remained fixed.

Repository identity stayed:

branch: worktree/warm-moose
commit: 111a28d2353f65504e7f3e207afe2bd292599b50
last_indexed_at: 2026-07-16T04:02:49.843682900Z

During two read-only repository listings in the same diagnostic pass:

nodes: 1,429,149 -> 1,465,942  (+36,793)
edges: 28,144  -> 28,144       (unchanged)

There were no indexing jobs. Repository stats reported only 19,091 typed nodes and 16,868 symbol nodes.

Three supported read paths materially disagreed:

list_indexed_repositories: 1,465,942 nodes / 28,144 edges
get_repository_stats:       499,882 nodes / 28,144 edges
memtrace status --json:    1,492,592 nodes / 148,198 edges

The listing endpoint also took roughly two minutes per call, while repository stats returned much faster.

This does not look like useful source indexing:

• indexed commit and index timestamp did not advance
• edge count on the repository endpoints stayed fixed
• no index job was active
• typed/source-symbol counts did not explain the growing population
• only one repository/branch identity was exposed, despite multiple worktrees existing
• the growing excess appears untyped, duplicated, session/runtime-related, or incorrectly counted

Worktrees may amplify the problem, but current evidence does not show legitimate separate worktree repositories being indexed. The stronger correlation is many MCP/client processes sharing one MemDB owner. This does not yet prove which client or component writes the additional nodes.

Diagnostic failure

A read-only:

memtrace doctor --json

produced no output before timing out after approximately 64 seconds.

Embedding diagnostics remained nominal:

• auth: Valid / not degraded
• pressure: Normal
• breaker: Closed

Expected behavior

1. One authoritative runtime/store owner, or explicit safe multi-client ownership semantics.
2. A supported command/workflow to drain all Memtrace-owned MCP children across agent hosts.
3. Stable, explainable node counts when no source/index episode occurs.
4. Consistent count scope—or explicit scope labels—across repository listing, repository stats, and CLI status.
5. doctor should complete under this failure state and identify which processes are active, stale, externally supervised, or safe to terminate.
6. If worktrees intentionally share/deduplicate graph state, the behavior and accounting should be documented.

Current mitigation

The factory has been told to stop all Memtrace and Cortex calls. I am rebooting the complete runtime and regenerating the index from a clean state. I am not attempting live prune, reindex, reset, store deletion, or blind process termination during the contested state.

I will add a clean-start baseline and recurrence timing after reboot/regeneration if the issue persists.

This should remain canonical in #60; #59 is already closed as the duplicate.

[keitharoby-byte]

v0.8.63 post-stop evidence (Windows)

The founder ran npx memtrace stop during the controlled incident recovery. The command reported:

• Background supervisor discovery found dev.memtrace.daemon, but Windows returned OpenService FAILED 1060 because that service is not installed.
• No Memtrace workspace runtime was listening on port 3030.
• The pre-reap MemDB sync failed: connect http://127.0.0.1:50051: transport: transport error.
• Sidecar reap then terminated four processes (PIDs 57420, 62668, 90296, and 94688) and the command ended with cleaned / Done.
• The command explicitly noted that Cursor remains configured to launch memtrace mcp; memtrace stop does not unregister or disable that externally managed MCP, which can respawn when an agent next invokes a Memtrace tool.

This narrows the lifecycle defect: sidecar reaping works, but stop can report a clean result after supervisor cleanup and MemDB synchronization failed, while externally managed MCP registration remains capable of respawning clients. In this incident the MemDB endpoint was already unreachable before reap, so the command could not confirm a clean persistence sync.

The factory-wide Memtrace/Cortex call hold remains active specifically to prevent client respawn while the founder reboots and regenerates the index. We will provide a clean post-regeneration baseline separately.

[keitharoby-byte]

Sanitized v0.8.63 doctor --fix follow-up (Windows)

After stop, the founder ran memtrace doctor --fix. Machine- and user-identifying details have been omitted.

Observed results:

• An initial attempted process operation raced with process exit (process not found).
• Doctor still enumerated 30 memtrace processes, all from the same global npm package installation.
• It reported a live heartbeat whose HTTP health check on the workspace runtime port failed.
• Agent/MCP configuration was detected across multiple supported editors/agents.
• The applied-fix summary reported 0 of 1 OS supervisor artifacts stopped.
• The supervisor stop again failed with Windows service error 1060 because the discovered service artifact is not installed.

This output does not yet demonstrate successful cleanup of the 30 processes: the captured result ends after the supervisor failure and contains no successful process-reap or post-fix zero-process verification. It does strengthen the suspected race/stale-supervisor portion of the lifecycle defect: doctor can encounter an already-exited PID, retain a stale heartbeat/failed health state, and attempt to stop a nonexistent service while many MCP processes remain visible.

The factory call hold remains active during founder-controlled reboot/regeneration. A sanitized post-reboot baseline will be added separately.

[keitharoby-byte]

Working hypothesis: repeated npx MCP launches expose missing runtime reuse/deduplication

Current npm behavior supports the founder's hypothesis: npx/npm exec executes the requested package binary; it does not discover or reuse an already-running application service. On Windows, npm package binaries are invoked through generated command/PowerShell shims, adding wrapper processes to the ownership tree.

That wrapper behavior may make parent/child cleanup harder, but it does not by itself explain the graph growth. The product boundary appears to be:

• Each editor/agent MCP client may legitimately start its own stdio memtrace mcp process.
• Those client processes should attach to one authoritative heavy runtime/store (or otherwise coordinate safely), rather than independently creating durable runtime/index iterations.
• Repository identity and graph writes should be idempotent across clients/worktrees so repeated MCP launches cannot duplicate the same source graph.
• stop/doctor --fix should enumerate the Windows shim/process tree and distinguish externally managed MCP clients from shared sidecars, then report partial cleanup rather than cleaned when sync/supervisor/reap verification fails.

The observed 30-process fan-in, stale repository identity, divergent node/edge views, and continued growth without index jobs are consistent with missing singleton attachment or cross-client deduplication. This remains a hypothesis until a clean single-client post-regeneration baseline is compared with repeated npx memtrace mcp launches.

[keitharoby-byte]

Documented attach model versus observed Windows behavior

Current Memtrace documentation explicitly states that:

• Windows x64 is a shipped/supported platform.
• One memtrace start process owns a workspace.
• Every memtrace mcp client should read the repo-scoped runtime owner, attach to the same MemDB, and avoid a duplicate daemon/index.
• Multiple agents should therefore produce multiple lightweight stdio MCP children but only one authoritative workspace stack.

References:

• https://www.memtrace.io/docs/requirements
• https://www.memtrace.io/docs/concepts/architecture
• https://www.memtrace.io/docs/mcp/overview

The current v0.8.63 Windows incident contradicts that advertised invariant: many client processes coexist with stale owner identity, divergent graph counts, continued node growth, failed health/attach cleanup, and no source indexing jobs.

Founder mitigation under consideration after regeneration:

1. Remove npx from MCP registrations and use the pinned installed memtrace command directly.
2. Start one explicit memtrace start --headless owner from the canonical repository root.
3. Enable clients one at a time and require the documented attaching to existing workspace owner receipt before adding the next client.
4. Treat missing attachment, owner drift, or graph-count growth as a failed invariant.

WSL2 may avoid Windows shim/process-tree behavior, but it should not be required for a supported Windows binary to meet the documented single-owner attach contract. A WSL pilot would also need the repository and Memtrace state to live consistently inside the Linux filesystem; mixing Windows and WSL paths risks creating another repository-identity split.

[keitharoby-byte]

Sanitized memcortex-mcp full-memory dump finding

A founder-created live full-memory dump was inspected locally. The raw dump will not be uploaded because it contains plaintext workspace/session history. User paths, process IDs, source text, tracker content, and other identifying data are omitted here.

Structural findings:

• The dump is a live full-memory snapshot, not a crash dump: it contains no exception stream.
• The process had 4 threads and 11 loaded modules.
• Approximately 611 MB of committed private memory was present in the captured process.
• Private memory contains repeated plaintext historical agent transcripts, tool results, code snippets/diffs, and prior error messages.
• The error-looking strings are therefore largely remembered/indexed corpus content, not proof of a current runtime exception.

Implications:

• Multiple simultaneous memcortex-mcp processes can plausibly multiply RAM by loading or caching overlapping decision/session corpora.
• This strengthens the duplicate-sidecar/failed-reap concern and creates a privacy reason not to share raw dumps.
• It does not yet prove Cortex generated the runaway .memdb code-graph nodes. Memtrace documents Cortex storage separately from the code graph; code-graph counts and Cortex decision counts must be measured independently after regeneration.

Recommended validation remains single-owner and sequential: establish one clean owner/process baseline, record code-graph and Cortex counts separately, then add one MCP client at a time and compare both process memory and durable counts.

[keitharoby-byte]

Deterministic per-turn Cortex MCP orphan reproduction (sanitized)

After the founder manually killed the Memtrace/Cortex process set, the active Codex session was resumed for OS-level inspection only. No Memtrace/Cortex tool was called and no clean workspace runtime was started.

Observed sequence:

• Codex configuration contains only the documented bare registration: command = "memtrace", args = ["mcp"] (no npx, no direct Cortex entry).
• The first resumed assistant turn created one memcortex-mcp child under the existing codex parent.
• The next resumed turn created a second memcortex-mcp child under the same parent 49 seconds later; the first remained alive.
• Each child consumed approximately 620 MB private memory and 805 MB working set, with 5–6 threads.
• There was no listener on ports 3000, 3030, or 50051 and no runtime-owner file.
• The repository .memdb newest write remained at the pre-test timestamp.
• The Cortex store was touched within one second of the first child spawn.

This is not an npx wrapper reproduction: the configuration invokes the installed memtrace command directly. It demonstrates that resuming consecutive Codex turns can create additional Cortex MCP children without reaping the previous child, even with no explicit Memtrace tool invocation and no workspace owner. At the observed footprint, each turn adds roughly 620 MB private / 805 MB working-set memory.

The founder is holding the clean Memtrace start until this pre-start state is recorded. Raw dumps and personal paths are not being shared.