{"id":1416,"date":"2026-06-10T21:15:23","date_gmt":"2026-06-10T19:15:23","guid":{"rendered":"https:\/\/pletzenauer.com\/2026\/06\/10\/troubleshooting-claude-desktop\/"},"modified":"2026-08-22T01:07:33","modified_gmt":"2026-08-21T23:07:33","slug":"troubleshooting-claude-desktop","status":"publish","type":"post","link":"https:\/\/pletzenauer.com\/en\/2026\/06\/10\/troubleshooting-claude-desktop\/","title":{"rendered":"Claude Desktop not responding? My structured diagnostic path"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><strong>The short answer:<\/strong> before you change anything in your configuration, run three checks, read the log file, look at the Anthropic status page, isolate the network path. In my experience those three steps resolve the large majority of cases within minutes. The most expensive mistake with Claude Desktop is not the fault itself, it is rearranging a configuration that was never the cause.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>As of August 2026. Claude Desktop moves quickly, especially around the connector interface. The log paths and the diagnostic steps are stable, but individual menu labels may differ in your version.<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The essentials<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>The log file answers the question almost every time<\/strong>: as long as you open the right one: <code>mcp.log<\/code> for connection problems, <code>mcp-server-NAME.log<\/code> for a single server.<\/li>\n<li><strong>First check whether the fault is yours at all.<\/strong> A look at status.anthropic.com costs ten seconds and can save you half a day.<\/li>\n<li><strong>On a corporate network it is almost always the network<\/strong>, not the app: TLS inspection, an authenticated proxy, blocked hosts.<\/li>\n<li><strong>With MCP servers, three causes explain nearly everything:<\/strong> broken JSON, relative instead of absolute paths, and Node or <code>npx<\/code> not being findable by the app.<\/li>\n<li><strong>Reinstalling is the last step, not the first.<\/strong> Reinstall first and you destroy the very information the log would have given you.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Three diagnostic steps before you change anything<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1. Open the right log file<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Claude Desktop writes its logs to a fixed location, depending on the operating system:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>macOS:<\/strong> <code>~\/Library\/Logs\/Claude<\/code><\/li>\n<li><strong>Windows:<\/strong> <code>%APPDATA%\\Claude\\logs<\/code><\/li>\n<li><strong>Linux (beta):<\/strong> <code>~\/.config\/Claude\/logs<\/code><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">There is a distinction many people miss. <code>mcp.log<\/code> holds the general record of MCP connections and failed connection attempts. Files named <code>mcp-server-NAME.log<\/code> hold the output of that specific server. When a single server refuses to start, the real error message sits in its own file, not in <code>mcp.log<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">On macOS and Linux you can follow both live with <code>tail -n 50 -f ~\/Library\/Logs\/Claude\/mcp*.log<\/code>. On Windows, <code>type \"%APPDATA%\\Claude\\logs\\mcp*.log\"<\/code> shows you what is already there. Leave the window open and restart Claude Desktop, then you watch the error appear at the moment it happens. That is far more informative than digging through a long file afterwards.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Check whether the fault is yours at all<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">status.anthropic.com reports incidents affecting the API and the applications. If an incident is running, stop troubleshooting and wait. I have watched people take apart a working configuration more than once while the actual fault sat in a data center two thousand kilometers away. That is why the status page belongs at the beginning of the process, not at the end.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. Isolate the network path<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Connect the machine to your phone&#8217;s hotspot for a moment and restart the app. If it works there, the problem is in the corporate network. VPN, proxy, firewall, or TLS inspection. If it fails there too, the problem is local. This single test halves the search space and takes two minutes. That is why I run it before any analysis of the configuration itself.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Symptom index: what each failure pattern means<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The table below covers the failure patterns I meet most often in client projects. The first step listed is the one I actually start with, not the complete fix, but the move that narrows down the cause.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Symptom<\/th><th>Likely cause<\/th><th>First step<\/th><\/tr><\/thead><tbody>\n<tr><td>Black or blank screen at startup<\/td><td>GPU conflict or corrupted cache<\/td><td>Delete the cache directory, restart the app, then disable hardware acceleration as a test<\/td><\/tr>\n<tr><td>App loads forever, spinner keeps turning<\/td><td>Network blocked by VPN, proxy, or TLS inspection<\/td><td>Run the hotspot test, then allow <code>api.anthropic.com<\/code> and <code>claude.ai<\/code><\/td><\/tr>\n<tr><td>403 Forbidden or \u201cinvalid authorization\u201d<\/td><td>Session expired, or headers altered by a proxy<\/td><td>Sign out and back in, then check the proxy for header manipulation<\/td><\/tr>\n<tr><td>500 Internal Server Error<\/td><td>Incident on the provider side<\/td><td>Check status.anthropic.com and retry after a few minutes<\/td><\/tr>\n<tr><td>No connectors visible, no MCP tools<\/td><td>Syntax error in <code>claude_desktop_config.json<\/code> or a wrong command path<\/td><td>Validate the JSON, make paths absolute, quit the app completely and restart<\/td><\/tr>\n<tr><td>One server missing, the others work<\/td><td>That server fails to start<\/td><td>Open <code>mcp-server-NAME.log<\/code> and run the server manually in a terminal<\/td><\/tr>\n<tr><td>On Windows: <code>ENOENT<\/code> with <code>${APPDATA}<\/code> in the path<\/td><td>Environment variable not expanded, npm not installed globally<\/td><td>Put the expanded <code>APPDATA<\/code> value into the <code>env<\/code> block of that server definition<\/td><\/tr>\n<tr><td>App starts and closes immediately on Linux<\/td><td>Missing system libraries or an unsupported distribution<\/td><td>Launch from a terminal and read the message, then check against Ubuntu 22.04+ \/ Debian 12+<\/td><\/tr>\n<tr><td>Tools are offered but fail silently<\/td><td>Server runs but responds incorrectly<\/td><td>Watch the server log during the call, then restart Claude Desktop<\/td><\/tr>\n<tr><td>Configuration changes have no effect<\/td><td>The app was closed, not quit<\/td><td>Quit fully (closing the window is not enough) and restart<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">When MCP servers will not connect<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is where I spend most of my time, and where the interface has changed most recently. Older guides talk about the \u201chammer icon\u201d that shows available tools. In current versions you find your servers through the attachments and connectors control at the bottom left of the input box, under \u201cManage connectors\u201d. If a guide has you hunting for a hammer that is not there, your installation is not broken, the guide is old.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The configuration file lives at <code>~\/Library\/Application Support\/Claude\/claude_desktop_config.json<\/code> on macOS and at <code>%APPDATA%\\Claude\\claude_desktop_config.json<\/code> on Windows. The fastest way there is the developer section of the settings, via \u201cEdit Config\u201d. How I structure that file and which servers I keep running permanently is in <a href=\"https:\/\/pletzenauer.com\/en\/2026\/06\/10\/configuring-mcp-servers-for-claude-desktop\/\">Configuring MCP servers for Claude Desktop<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When a server does not appear, I work through this list in order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Validate the JSON.<\/strong> A single stray comma disables the entire configuration, not just the server you touched. That explains the confusing pattern where every server suddenly disappears after you edited one of them.<\/li>\n<li><strong>Make paths absolute.<\/strong> Relative paths do not work, because the app does not start from the directory you assume it does.<\/li>\n<li><strong>Quit the app completely.<\/strong> Closing the window is not enough, the configuration is only read on a real start.<\/li>\n<li><strong>Run the server manually in a terminal<\/strong>, with exactly the same command and arguments as in the configuration. Here you get the error message in plain text, whereas the app only shows you a silent failure. This step saves me more time than any other.<\/li>\n<li><strong>Check Node and <code>npx<\/code>.<\/strong> Many servers run on Node. If <code>node --version<\/code> works in your terminal but nothing starts inside the app, the app cannot find the installation, it does not inherit your shell environment.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">One special case deserves its own mention, because it comes up regularly on Windows. If the server log shows an <code>ENOENT<\/code> error with <code>${APPDATA}<\/code> appearing as unresolved text inside a path, put the expanded value into the <code>env<\/code> block of that server definition, for example <code>\"env\": { \"APPDATA\": \"C:\\\\Users\\\\yourname\\\\AppData\\\\Roaming\\\\\" }<\/code>. This requires npm to be installed globally, which you can verify by checking whether the directory <code>%APPDATA%\\npm<\/code> exists. If it does not, <code>npm install -g npm<\/code> fixes it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What usually goes wrong on a corporate network<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>TLS inspection.<\/strong> Products like Zscaler break the traffic open and re-sign it with their own certificate. Claude Desktop rejects that certificate, and to your users the whole thing simply looks like \u201cthe app is broken\u201d. There are two clean routes: exempt the Anthropic hosts from TLS inspection, or place your proxy&#8217;s root certificate in the system trust store so the app trusts it. Which route you take is your security team&#8217;s call, not mine.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Authenticated proxy.<\/strong> Set <code>HTTPS_PROXY<\/code> and <code>HTTP_PROXY<\/code> in the system context, not just in the shell of the signed-in user. A desktop application does not start from your shell and never sees those variables. That is exactly why the test in the terminal succeeds while the app runs into timeouts, a contradiction that stays mysterious for a very long time without this explanation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Deployment via Intune.<\/strong> Packaged installations need a correct detection path. Get it wrong and Intune reports success while nothing happens on the devices. So do not check the deployment status, check an actual machine.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you are working out what is allowed in your organization anyway, the data protection side belongs in the same conversation. I wrote that up in <a href=\"https:\/\/pletzenauer.com\/en\/2026\/06\/10\/claude-desktop-gdpr-compliance\/\">Claude Desktop in the enterprise: data protection and GDPR in practice<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">If nothing helps: the clean rebuild path<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Reinstalling is legitimate, but in this order, so that you lose nothing and know afterwards what the cause was:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Back up the configuration.<\/strong> Copy <code>claude_desktop_config.json<\/code> somewhere safe. That file is your work, everything else is replaceable.<\/li>\n<li><strong>Keep the logs.<\/strong> A folder with the most recent log files costs nothing and is the only thing that can still explain the fault later.<\/li>\n<li><strong>Quit the app completely<\/strong>, and only then delete the cache directory.<\/li>\n<li><strong>Start without a configuration.<\/strong> Rename the configuration file briefly and start the app empty. If it runs now, the fault is in your configuration and not in the installation, that is the most important fork in the whole process.<\/li>\n<li><strong>Bring servers back one at a time<\/strong> instead of restoring the whole file. After three rounds at most you know which entry caused it.<\/li>\n<li><strong>Only now reinstall<\/strong>, if it still misbehaves. On Linux, install from the package repository rather than a downloaded <code>.deb<\/code> file, otherwise you will not get updates.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">If at this point you realize the installation was never clean to begin with, a look at <a href=\"https:\/\/pletzenauer.com\/en\/2026\/06\/10\/installing-claude-desktop\/\">Installing Claude Desktop<\/a> is quicker than more repair work.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">When to stop looking<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Some faults are not yours. If the log shows a server error, the status page reports an incident, or a failure pattern appears on several machines at once after an update, stop repairing and start documenting. A screenshot, the affected version, and the last few log lines are all Anthropic support needs, and they save you two rounds of questions.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">My rule of thumb from practice: if 30 minutes of structured searching has not produced a cause, you are usually searching in the wrong place. Then the right move is back to the log file, or to someone who has seen the same failure pattern before. And if the real question is whether Claude Desktop is the right tool for your job at all, <a href=\"https:\/\/pletzenauer.com\/en\/2026\/06\/10\/claude-desktop-vs-claude-code-comparison\/\">Claude Desktop or Claude Code<\/a> answers that faster than any troubleshooting session. For an overview of everything around the application, see my page on <a href=\"https:\/\/pletzenauer.com\/en\/claude-desktop\/\">Claude Desktop<\/a>.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Log file, status page, network path: three checks find the cause in minutes. Symptom index, MCP servers and corporate networks, with the actual commands.<\/p>\n","protected":false},"author":1,"featured_media":1465,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17],"tags":[],"class_list":["post-1416","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automatisierung"],"_links":{"self":[{"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/posts\/1416","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/comments?post=1416"}],"version-history":[{"count":2,"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/posts\/1416\/revisions"}],"predecessor-version":[{"id":3305,"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/posts\/1416\/revisions\/3305"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/media\/1465"}],"wp:attachment":[{"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/media?parent=1416"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/categories?post=1416"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pletzenauer.com\/en\/wp-json\/wp\/v2\/tags?post=1416"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}