Claude.ai Desktop App still cannot start mcp

[gotspatel]

Version

codebase-memory-mcp 0.10.3

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

install went well but cannot run mcp in claude, logs attached

Reproduction

it was a fresh install

Logs

Claude Code:
  skills: 1 installed
  agent: C:/Users/Administrator/.claude/agents/codebase-memory-scout.md
  agent: C:/Users/Administrator/.claude/agents/codebase-memory.md
  agent: C:/Users/Administrator/.claude/agents/codebase-memory-auditor.md
  mcp: C:/Users/Administrator/.claude.json
  hooks: PreToolUse Grep/Glob search augmentation + PostToolUse Read coverage (non-blocking)
  hooks: SessionStart (MCP usage reminder on startup/resume/clear/compact)
  hooks: SubagentStart (MCP usage reminder for subagents)


but on opening the app the errors below in log and mcp cannot start

mcp.log

2026-08-13T07:09:45.382Z [info] [codebase-memory-mcp] Message from client: method="initialize" id=0 params
2026-08-13T07:09:45.892Z [info] [codebase-memory-mcp] Server transport closed
2026-08-13T07:09:45.893Z [info] [codebase-memory-mcp] Server transport closed unexpectedly, this is likely due to the process exiting early. If you are developing this MCP server you can add output to stderr (i.e. `console.error('...')` in JavaScript, `print('...', file=sys.stderr)` in python) and it will appear in this log.
2026-08-13T07:09:45.893Z [error] [codebase-memory-mcp] Server disconnected. For troubleshooting guidance, please visit our [debugging documentation](https://modelcontextprotocol.io/docs/tools/debugging)
2026-08-13T07:09:45.893Z [info] [codebase-memory-mcp] Client transport closed
2026-08-13T07:09:45.894Z [info] [codebase-memory-mcp] Client transport closed



mcp-server-codebase-memory-mcp.log


2026-08-13T07:09:42.636Z [codebase-memory-mcp] [info] Initializing server... { metadata: undefined }
2026-08-13T07:09:42.652Z [codebase-memory-mcp] [info] Using MCP server command: C:\Users\Administrator\AppData\Local\Programs\codebase-memory-mcp\codebase-memory-mcp.exe with path: {
  metadata: {
    paths: [
      'C:\\Program Files\\nodejs',
      'C:\\Python314',
      'C:\\Python311',
      'C:\\Program Files\\Git\\cmd',
      'C:\\Program Files\\Git\\mingw64\\bin',
      'C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\java8path',
      'C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\javapath',
      'C:\\Program Files\\PowerShell\\7',
      'C:\\Python314\\Scripts\\',
      'C:\\Python314\\',
      'C:\\Program Files\\Microsoft MPI\\Bin\\',
      'C:\\Python311\\Scripts\\',
      'C:\\Python311\\',
      'C:\\Windows\\system32',
      'C:\\Windows',
      'C:\\Windows\\System32\\Wbem',
      'C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\',
      'C:\\Windows\\System32\\OpenSSH\\',
      'C:\\Program Files (x86)\\Microsoft SQL Server\\160\\Tools\\Binn\\',
      'C:\\Program Files\\Microsoft SQL Server\\160\\Tools\\Binn\\',
      'C:\\Program Files\\Microsoft SQL Server\\Client SDK\\ODBC\\170\\Tools\\Binn\\',
      'C:\\Program Files\\Microsoft SQL Server\\160\\DTS\\Binn\\',
      'C:\\Program Files\\dotnet\\',
      'C:\\Program Files\\GTK3-Runtime Win64\\bin',
      'C:\\Program Files (x86)\\WinSCP\\',
      'C:\\Program Files\\PuTTY\\',
      'C:\\Program Files\\Tesseract-OCR',
      'C:\\Program Files\\wkhtmltopdf\\bin',
      'C:\\Program Files\\Microsoft VS Code\\bin',
      'C:\\Poppler24.07.0-0\\Library\\bin',
      'C:\\Program Files\\gs\\gs10.05.1\\bin',
      'C:\\Program Files\\JAM Software\\SpamAssassin for Windows',
      'C:\\ripgrep',
      'C:\\Program Files\\PowerShell\\7\\',
      'C:\\Program Files (x86)\\Diffuse',
      'C:\\Users\\Administrator\\.local\\\\bin',
      'C:\\Program Files\\Git\\usr\\bin',
      'C:\\Users\\Administrator\\bin',
      'C:\\Users\\Administrator\\.local\\bin',
      'C:\\Strawberry\\c\\bin',
      'C:\\Strawberry\\perl\\site\\bin',
      'C:\\Users\\Administrator\\AppData\\Local\\GitHubDesktop\\bin',
      'C:\\Users\\Administrator\\AppData\\Local\\Programs\\codebase-memory-mcp',
      'C:\\Users\\Administrator\\.bun\\bin',
      'C:\\Users\\Administrator\\AppData\\Roaming\\npm',
      'd:\\Ollama',
      'C:\\Users\\Administrator\\.local\\bin\\',
      'D:\\llamacpp',
      'C:\\Users\\Administrator\\.dotnet\\tools',
      [length]: 49
    ]
  }
} %o
2026-08-13T07:09:42.658Z [codebase-memory-mcp] [info] Server started and connected successfully { metadata: undefined }
2026-08-13T07:09:45.382Z [codebase-memory-mcp] [info] Message from client: method="initialize" id=0 params { metadata: undefined }
codebase-memory-mcp: secure daemon endpoint could not be created
2026-08-13T07:09:45.892Z [codebase-memory-mcp] [info] Server transport closed { metadata: undefined }
2026-08-13T07:09:45.892Z [codebase-memory-mcp] [info] Server transport closed unexpectedly, this is likely due to the process exiting early. If you are developing this MCP server you can add output to stderr (i.e. `console.error('...')` in JavaScript, `print('...', file=sys.stderr)` in python) and it will appear in this log. { metadata: undefined }
2026-08-13T07:09:45.893Z [codebase-memory-mcp] [error] Server disconnected. For troubleshooting guidance, please visit our [debugging documentation](https://modelcontextprotocol.io/docs/tools/debugging) { metadata: { context: 'connection', stack: undefined } }
2026-08-13T07:09:45.893Z [codebase-memory-mcp] [info] Client transport closed { metadata: undefined }
2026-08-13T07:09:45.894Z [codebase-memory-mcp] [info] Client transport closed { metadata: undefined }

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]

Thank you @gotspatel — the logs made this quick, and I think your issue and #1580 are the same bug seen from two ends.

Your install reported success, then the server exited during initialize with nothing on stdout. The detail that points at the cause is the path: C:\\Users\\Administrator. We compare file ownership against your user SID, but Windows stamps newly-created objects with the token's owner SID, which for an Administrators-group member defaults to BUILTIN\\Administrators. The server hits that refusal on its private directory during startup and exits before it can report anything — which is why the client only sees "transport closed unexpectedly".

Fix in PR #1583. It accepts the SID Windows actually stamps on what we create, and is strictly narrower than trusting any administrator: a file owned by a different account is still refused.

A caveat worth stating plainly: our Windows CI and test VM both run as ordinary users, where those two SIDs are identical, so they verify the fix compiles and breaks nothing but cannot exercise the elevated path that is failing for you. I will ping this issue when the next release ships — if you re-run it then and report back, that is the confirmation we cannot produce ourselves.

In the meantime, if you want it working today: running under a normal (non-Administrator) Windows account should avoid the refusal entirely, since the two SIDs then match.

Separately, the silent exit is its own defect — v0.10.3 added a loud JSON-RPC error for exactly this class (#1539), and your log shows it is not covering the daemon-startup path. I am tracking that as a follow-up: a server that cannot start should always say why.

[gotspatel]

I intend to install antigravity, opencode also along with vscode, and Hope the fix you intend to do will allow all clients to use the mcp concurrently.

Regards

[DeusData]

Fixed on main — commit 0215e9b4 (PR #1583), shipping in the next release.

The ownership check now also accepts the SID Windows actually stamps on objects we create (TokenOwner), not just your user SID (TokenUser). On an Administrators-group account those differ, which is why we were refusing files we had written seconds earlier.

Verified on a real Windows VM (302 tests, 0 failures) plus full CI. As I mentioned, neither venue runs elevated, so the elevated path itself is the piece only you can confirm — I will ping here when the release is out.

[cillvius]

Reproduced independently: Windows 11 26200, Claude Desktop (MSIX build, Claude_...pzs8sxrjxfjjc), codebase-memory-mcp 0.10.3, standard (non-elevated-relevant) user token.

Traced with Process Monitor to compare a Desktop-spawned attempt against a manual run of the identical binary:

• Manual run (plain shell, same exe, same user): 0 references to any \REGISTRY\WC\Silo* namespace across the full process lifetime. Creates the daemon endpoint and responds to initialize normally.
• Every Desktop-spawned attempt (5 captured in one session): the process opens keys under \REGISTRY\WC\Silo<GUID>\... before exiting, never attempts \.\pipe\cbm-daemon-* at all, and exits cleanly with no Win32 ACCESS_DENIED on its own operations — i.e. it self-refuses, consistent with Windows: ancestor walk refuses app container / capability SIDs, so 0.10.0 cannot start inside a containerized host #1533's ancestor-walk gate tripping on an app-container/capability SID rather than a genuine OS-level permission failure.

This matches #1533's diagnosis: the host (Claude Desktop, MSIX-packaged) puts the child process in a container/package identity context, and the strict ancestor DACL walk in cbm_daemon_ipc_endpoint_new refuses an ancestor directory whose ACE grants rights to that container/capability SID, without a config knob to work around it. Also ruled out independently on my machine: no %TEMP%/%LOCALAPPDATA% ACL issues, CheckNetIsolation LoopbackExempt for the package, and Windows Defender activity — none of those affected the outcome, narrowing it to the ancestor-walk gate described in #1533.

Happy to share the full Procmon CSV excerpt if useful for triage.