Repository navigation
Claude.ai Desktop App still cannot start mcp #1582
Description
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.
Activity
DeusData commentedon Aug 13, 2026
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
initializewith 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 toBUILTIN\\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 commentedon Aug 13, 2026
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
Merge pull request #1583 from DeusData/fix/batch3-windows-owner
DeusData commentedon Aug 13, 2026
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.
fix(windows): accept the owner Windows actually stamps on what we create
Merge pull request #1591 from DeusData/fix/silent-client-startup-exit
fix(mcp): never let a client-path startup failure die silently (DeusD…
cillvius commentedon Aug 13, 2026
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:
\REGISTRY\WC\Silo*namespace across the full process lifetime. Creates the daemon endpoint and responds toinitializenormally.\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_newrefuses 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 LoopbackExemptfor 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.
gotspatel commentedon Aug 14, 2026
installed 0.10.4 just now below the errors
during install error for opencode json
error: agent_config agent=OpenCode op=mcp_install path=C:/Users/Administrator/.config/opencode/opencode.json
the full log below form mcp-server-codebase-memory-mcp.log from Claude
the error surfacedi in Claude dekstop UI
Need more info please ask for it, happy to help.
gotspatel commentedon Aug 14, 2026
may be late to party ;-) but still here is the opencode.json
DeusData commentedon Aug 14, 2026
Not late at all — this confirms it on a second operating system, independently.
Your entry:
is the same three-key shape @iandol has on Linux, and the cause is now pinned (#1630): our ownership check at
src/cli/config_json_like.c:2837requires the entry's key set to match exactly. We only writecommandandtype. Your entry has three keys, we recognise two, so we classify our own entry as foreign and refuse to touch it.Your file makes the case stronger than @iandol's did, because every MCP server in it carries
enabled—mssql,forgetful,chrome-devtools, ours. That is OpenCode's normal shape, not an unusual hand-edit, so this will affect essentially every OpenCode user who has ever toggled a server on or off.So the
op=mcp_installhalf of your report has a confirmed root cause. That is separate from thesecure daemon endpoint could not be createdhalf, which was the AppContainer/ACL issue — #1623 shipped the ancestor tolerance for that, and #1625 fixes the installer staging ACL.Fix is tracked in #1630. It needs two parts in order: preserve unknown keys through the edit, then relax the ownership check. Doing only the second would make us accept your entry and rewrite it without
enabled— swapping a visible refusal for a silent deletion of your setting, which is worse.One small thing, offered kindly rather than as criticism: the config you pasted includes
"apiKey": "local-matrix-bypass"and some internal hostnames/IPs. That key points at127.0.0.1so it is probably not sensitive, but GitHub keeps edit history — if any of it is real, rotating it is cheap insurance. Thank you for posting the file; it is what made this diagnosable, and I would rather say this than stay quiet.gotspatel commentedon Aug 14, 2026
nothing is real cheers to point it out
and yes ""enabled": true" was added to opencode schema i think somewhere around version version 0.10.0 (not very sure of exact version)
https://opencode.ai/config.json
gotspatel commentedon Aug 14, 2026
major issue is to get it working with claude.ai where it is disconnected immediately
fix(cli): name the rule that refused CLI coordination, not just the s…
fix(cli): accept an MCP entry the client annotated, instead of refusi…
DeusData commentedon Aug 15, 2026
@cillvius — your Procmon work never got an answer, and it should have. Our last reply here addressed only the OpenCode half of this thread and skipped yours entirely. Sorry.
Yes, please — the full Procmon CSV excerpt would be very useful. Your observation is the most specific evidence anyone has produced on this failure:
That reading matches what we found from a different direction. A
\REGISTRY\WC\Silo<GUID>\prefix means the process is running inside a server silo — the container the desktop app spawns it in — and "exits before ever touching the pipe" is the signature of our own admission check refusing before any coordination is attempted. It is not a connection failure; it is us declining to start.Two changes in v0.10.5 bear directly on that path:
S-1-15-2-*) and capability SIDs (S-1-15-3-*). On reported machines the blocking entry resolved to a shipping desktop application, i.e. something no user could reasonably remove. The private runtime directory stays strict; only ancestors relax.(endpoint). Previously the ancestor walk printed the name of the child it was about to enter, so several people were sent to inspect a directory that was fine.I am not going to claim this fixes your case — a silo may still present an identity we refuse, and your trace is the only evidence that could tell us. If it still self-refuses after upgrading, the new message should finally name the path and rule, and that plus your CSV would pin it exactly.
@gotspatel — on your half: the OpenCode
op=mcp_installrefusal is fixed in v0.10.5 (your config was one of the two that proved it — every MCP server in it carried"enabled": true, which is what our ownership check was wrongly rejecting). The Claude Desktop disconnect is a different failure, the one described above, and is not confirmed fixed. If you are still disconnected after upgrading, please post the new error text — it should now say considerably more than it did.There is also a relevant escape hatch shipping in v0.10.5:
CBM_RUNTIME_DIRrelocates the daemon rendezvous directory in a shipped build. It does not relax any check — you point it at an ancestry that passes — but until now there was no way to move it at all, which left affected machines with no path forward.Thank you both. Instrumenting this yourselves was well beyond what should be needed, and the fact that it was is our problem, not yours.
gotspatel commentedon Aug 16, 2026
installed 0.10.5 the installer problem with opencode still stays, the config file is exactly what i provided just with correct data (ip, pass, keys) no other change, if it helps the file is UTF-8 and Line ending: LF
Claude.ai Tools found and working no errors
fix(cli): compare our binary path separator-insensitively in MCP owne…
DeusData commentedon Aug 17, 2026
The remaining OpenCode refusal on your machine is root-caused and fixed in 93e9308 (PR #1683, v0.10.6): your entry stores the command with backslashes while the installer compares its own path with forward slashes — same file, refused over the separator spelling (and the dead-path probe then rightly said the binary exists, hardening the refusal). Ownership comparison is now separator-insensitive and case-folds on Windows. Your posted config was the file that cracked it — thank you for the persistence across releases. Please re-test on v0.10.6; if anything still refuses, the error now names the reason.
cillvius commentedon Aug 17, 2026
Here it is: https://gist.github.com/cillvius/6090d2967f2115f366c0e8d5d60e9e6d
(Captured on v0.10.3, same machine/setup as before. A few fields — cache filenames, one env-var dump, one impersonation entry — were redacted/genericized before posting since they revealed unrelated local project names; nothing in the Silo/pipe/registry evidence was touched.)
Update: I upgraded to v0.10.6 and the error is gone — Claude Desktop connects cleanly now. So whatever landed between 0.10.3 and 0.10.6 (the AppContainer/capability SID tolerance you described, plus anything in 0.10.6) fixed it on this machine. Thanks for chasing this down and for the detailed explanation of what the trace meant.
DeusData commentedon Sep 25, 2026
Thank you, @gotspatel, for sticking with this across four releases. Your logs and your opencode.json cracked both halves. Thanks also to @cillvius for the Procmon trace and for confirming that Claude Desktop connects on v0.10.6.
What was fixed:
Your setup runs as Administrator, which is the one path we couldn't test ourselves. Could you confirm on v0.11.0 that Claude Desktop and OpenCode both connect? If they do, we'll close this. Thanks again!
gotspatel commentedon Sep 26, 2026
Thanks I can confirm it works on V1 opencode desktop.
but i think you will have to make changes again for it to work on V2 opencode which has introduced some breaking changes and the mcp doesn't work on it. https://opencode.ai/v2/docs/migrate-v1/
Hope to see new version soon compatible with V2 opencode also
DeusData commentedon Oct 25, 2026
Thank you for confirming the V1 OpenCode setup works, and to @cillvius for the successful Claude Desktop retest. The newly reported OpenCode V2 compatibility problem needs separate maintainer follow-through. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.