Claude Desktop not responding? My structured diagnostic path

The short answer: 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.

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.

The essentials

• The log file answers the question almost every time: as long as you open the right one: mcp.log for connection problems, mcp-server-NAME.log for a single server.
• First check whether the fault is yours at all. A look at status.anthropic.com costs ten seconds and can save you half a day.
• On a corporate network it is almost always the network, not the app: TLS inspection, an authenticated proxy, blocked hosts.
• With MCP servers, three causes explain nearly everything: broken JSON, relative instead of absolute paths, and Node or npx not being findable by the app.
• Reinstalling is the last step, not the first. Reinstall first and you destroy the very information the log would have given you.

Three diagnostic steps before you change anything

1. Open the right log file

Claude Desktop writes its logs to a fixed location, depending on the operating system:

• macOS: ~/Library/Logs/Claude
• Windows: %APPDATA%\Claude\logs
• Linux (beta): ~/.config/Claude/logs

There is a distinction many people miss. mcp.log holds the general record of MCP connections and failed connection attempts. Files named mcp-server-NAME.log 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 mcp.log.

On macOS and Linux you can follow both live with tail -n 50 -f ~/Library/Logs/Claude/mcp*.log. On Windows, type "%APPDATA%\Claude\logs\mcp*.log" 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.

2. Check whether the fault is yours at all

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.

3. Isolate the network path

Connect the machine to your phone’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.

Symptom index: what each failure pattern means

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.

When MCP servers will not connect

This is where I spend most of my time, and where the interface has changed most recently. Older guides talk about the “hammer icon” 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 “Manage connectors”. If a guide has you hunting for a hammer that is not there, your installation is not broken, the guide is old.

The configuration file lives at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and at %APPDATA%\Claude\claude_desktop_config.json on Windows. The fastest way there is the developer section of the settings, via “Edit Config”. How I structure that file and which servers I keep running permanently is in Configuring MCP servers for Claude Desktop.

When a server does not appear, I work through this list in order:

1. Validate the JSON. 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.
2. Make paths absolute. Relative paths do not work, because the app does not start from the directory you assume it does.
3. Quit the app completely. Closing the window is not enough, the configuration is only read on a real start.
4. Run the server manually in a terminal, 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.
5. Check Node and npx. Many servers run on Node. If node --version works in your terminal but nothing starts inside the app, the app cannot find the installation, it does not inherit your shell environment.

One special case deserves its own mention, because it comes up regularly on Windows. If the server log shows an ENOENT error with ${APPDATA} appearing as unresolved text inside a path, put the expanded value into the env block of that server definition, for example "env": { "APPDATA": "C:\\Users\\yourname\\AppData\\Roaming\\" }. This requires npm to be installed globally, which you can verify by checking whether the directory %APPDATA%\npm exists. If it does not, npm install -g npm fixes it.

What usually goes wrong on a corporate network

TLS inspection. 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 “the app is broken”. There are two clean routes: exempt the Anthropic hosts from TLS inspection, or place your proxy’s root certificate in the system trust store so the app trusts it. Which route you take is your security team’s call, not mine.

Authenticated proxy. Set HTTPS_PROXY and HTTP_PROXY 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.

Deployment via Intune. 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.

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 Claude Desktop in the enterprise: data protection and GDPR in practice.

If nothing helps: the clean rebuild path

Reinstalling is legitimate, but in this order, so that you lose nothing and know afterwards what the cause was:

1. Back up the configuration. Copy claude_desktop_config.json somewhere safe. That file is your work, everything else is replaceable.
2. Keep the logs. A folder with the most recent log files costs nothing and is the only thing that can still explain the fault later.
3. Quit the app completely, and only then delete the cache directory.
4. Start without a configuration. 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.
5. Bring servers back one at a time instead of restoring the whole file. After three rounds at most you know which entry caused it.
6. Only now reinstall, if it still misbehaves. On Linux, install from the package repository rather than a downloaded .deb file, otherwise you will not get updates.

If at this point you realize the installation was never clean to begin with, a look at Installing Claude Desktop is quicker than more repair work.

When to stop looking

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.

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, Claude Desktop or Claude Code answers that faster than any troubleshooting session. For an overview of everything around the application, see my page on Claude Desktop.