A Claude desktop setup guide for corporate networks

Installing Claude on a personal machine takes about a minute. One command, a browser login, done. Installing it on a corporate machine can take an afternoon, and the failure that eats the afternoon is almost always the same: the install itself works, and then nothing connects.

That is the pattern worth understanding before you start. Claude Desktop and Claude Code, the two ways Claude lands on a desktop, are easy software to install. The hard part is never the installer. The hard part is the corporate network sitting between the tool and Anthropic’s servers, doing things a home network does not: routing every request through a proxy, inspecting encrypted traffic, blocking domains it does not recognize. Each of those is a primitive, and each one can stop Claude Code dead with an error message that does not name the real cause.

So this guide is built around that reality. It covers the clean install on macOS and Windows, then spends most of its length on the network layer, because that is where the afternoon goes. If the install worked and Claude still cannot reach Anthropic, the answer is in here.

Why it works at home and fails at work

The difference between a home network and a corporate one is not speed or security policy in the abstract. It is three concrete things that sit in the request path. First, a corporate network usually forces all traffic through a proxy server, so Claude Code cannot open a direct connection to Anthropic; it has to be told the proxy exists. Second, many corporate networks run TLS inspection, where a security appliance decrypts, examines, and re-encrypts every HTTPS request, which means the certificate Claude Code sees is not Anthropic’s. Third, the network blocks outbound domains that are not on an approved list, so even a correctly proxied request fails if Anthropic’s domains were never allowlisted. A home network does none of these. That is the whole reason the same install behaves differently, and it is why a setup guide written for a laptop at home is close to useless on a managed work machine.

The errors are what make this hard, because they rarely name the real cause. A blocked outbound domain can surface as a generic timeout. A TLS-inspection failure shows up as an SSL or certificate error that reads as though something is wrong with Claude Code itself, when nothing is. A missing proxy setting looks like the network is down. A developer who has only ever installed software on home machines reads these messages literally, retries the install, and gets the same result, because the install was never the problem. Recognizing that the failure is environmental, not a broken installer, is half the fix. The other half is knowing which of the three primitives is in the way, and the rest of this guide takes them one at a time.

There is a quick way to tell them apart. If Claude Code hangs and then times out, suspect the proxy or a blocked domain: the request is leaving and going nowhere. If it fails fast with an SSL or certificate error, it is TLS inspection: the request reached something, and that something presented a certificate Claude Code would not trust. A timeout points one way, a certificate error points the other, and that single distinction usually tells you which section below to read first. The slow failures and the fast failures have different causes, and chasing the wrong one is how the afternoon disappears.

The clean install on Mac and Windows

Start with the install itself, which is the easy part on every platform. Claude Code’s native installer is the recommended method. On macOS or Linux it is one line, curl -fsSL https://claude.ai/install.sh | bash. On Windows it is irm https://claude.ai/install.ps1 | iex in PowerShell. The installer drops a self-contained binary into your home directory and does not need Node.js, because the native binary is not a Node application. There is also a Claude Desktop app, a download for macOS or Windows, for people who want Claude Code without living in a terminal. The one Windows detail worth knowing is that Claude Code runs natively on Windows now. It does not require WSL. Anthropic recommends installing Git for Windows alongside it, so Claude Code can use Git Bash for its shell tool, but if Git Bash is absent it falls back to PowerShell. WSL stays optional, useful mainly for Linux toolchains and for sandboxed command execution.

One point of confusion worth settling: Claude Desktop and Claude Code are not rival products you choose between. The Desktop app is a graphical wrapper, a window instead of a terminal, and it can run Claude Code inside itself for people who would rather not open a shell. Underneath, the two reach Anthropic the same way and meet the same network the same way. So nothing in the rest of this guide is command-line only. If you install the Desktop app on a corporate machine, the proxy and the certificate trust apply to it exactly as they do to the command-line tool, and so does the domain allowlist. Pick whichever interface suits the person. The network setup does not change.

For teams that manage software centrally, two more facts matter. npm is still a supported install path, npm install -g @anthropic-ai/claude-code, and it needs Node.js 18 or later, but it pulls in the same native binary the standalone installer uses, so npm here is a delivery mechanism rather than a runtime. And native installs auto-update themselves in the background, which an IT team may want to control rather than allow. There are settings to pin a minimum version or switch the auto-updater off. If you are deploying across a fleet rather than setting up one machine, the mechanics of enterprise Windows deployment and update management are their own subject, with their own decisions about packaging and channels.

Whichever method you use, verify the result the same way. Run claude --version to confirm the binary is on your path, then run claude doctor, which checks the installation and configuration and reports what is wrong in plain terms. On a corporate machine, claude doctor is also the fastest way to see whether the problem you are about to chase is the install or the network. If claude doctor is happy and Claude still cannot connect, you have a network problem, and the next three sections are the map.

Proxies and the outbound allowlist

A corporate proxy is the first thing to configure, and Claude Code makes it straightforward because it reads the standard proxy variables. Set HTTPS_PROXY to your proxy address, set HTTP_PROXY if HTTPS is unavailable, and use NO_PROXY to list hosts that should bypass the proxy. If the proxy needs basic authentication, the username and password go in the proxy URL itself, though it is better to keep those in an environment variable than hardcoded in a script. One limitation is worth knowing up front: Claude Code does not support SOCKS proxies, only HTTP and HTTPS ones, and for proxies that demand NTLM or Kerberos the documented path is to put an LLM gateway in front instead. Proxy aside, the network has to actually permit the destinations. Claude Code needs a specific short list of outbound domains, and if your firewall blocks any of them, a perfectly configured proxy still will not save the connection. The proxy says how to leave. The allowlist says where you are allowed to go.

That outbound list is short and worth pasting straight into a firewall rule. The ones you cannot do without are api.anthropic.com, which carries the actual Claude API traffic, claude.ai and platform.claude.com for account authentication, and downloads.claude.ai for the installer and the background updater. A few more earn their place depending on what you use: raw.githubusercontent.com for the release-notes feed, and bridge.claudeusercontent.com if anyone runs the Claude in Chrome extension. Anthropic publishes the full table and keeps it current, so check it against the live page rather than trusting a copy that may have aged. And if your organization routes Claude through Amazon Bedrock or Google Vertex AI instead of Anthropic’s API directly, the model traffic goes to that provider, and the allowlist changes to match.

One practical wrinkle: these variables have to persist. Exporting HTTPS_PROXY in a terminal session sets it for that session only, and the next terminal knows nothing about it. For a setting that survives, you have two durable homes. One is your shell profile, the .zshrc or .bashrc that runs when a shell starts. The other, and the one Anthropic points to, is the env block in Claude Code’s own settings.json, where the proxy and certificate variables can live as configuration rather than as shell state. The settings.json route has a real advantage on a managed fleet: it is a file IT can template and ship, so every machine gets the same network configuration without anyone typing an export command by hand.

TLS inspection, the silent blocker

TLS inspection is the blocker that costs people the most time, because it fails quietly and the error blames the wrong thing. Here is what happens. A corporate security appliance intercepts the HTTPS connection, decrypts it to inspect the contents, then re-encrypts it with a certificate signed by the company’s own internal authority. Claude Code, expecting Anthropic’s certificate, sees an unfamiliar one and refuses the connection with an SSL error. The install was fine. The proxy was fine. The certificate is the problem. The fix is to make Claude Code trust the corporate authority. By default it already trusts your operating system’s certificate store, so if IT has installed the corporate root certificate system-wide, inspection proxies like Zscaler and CrowdStrike Falcon work with no extra step at all. When that is not enough, point NODE_EXTRA_CA_CERTS at the corporate CA certificate file, and Claude Code will trust it. That single variable resolves most corporate SSL failures.

Two more controls exist for the harder cases, both documented in the environment variables reference. CLAUDE_CODE_CERT_STORE decides which certificate sources Claude Code trusts at all; its default, bundled,system, means both Claude Code’s own bundled Mozilla certificates and the operating system store, and you can narrow it to one or the other. And for environments that require client certificates, mutual TLS, Claude Code reads CLAUDE_CODE_CLIENT_CERT and CLAUDE_CODE_CLIENT_KEY. Most teams never touch those two. The one variable that matters for the common case is NODE_EXTRA_CA_CERTS, and getting the corporate CA file from your IT department is usually the entire task.

Two cautions when you apply the fix. The certificate file NODE_EXTRA_CA_CERTS points at has to be a PEM file, the readable text format that begins with a BEGIN CERTIFICATE line, not a binary .cer or .pfx bundle; if IT hands you the wrong format, convert it before pointing the variable at it. And after you set the variable, restart Claude Code fully, because the trust configuration is read at startup, and a half-restarted session keeps failing with the same SSL error and convinces you the fix did not work. Set the variable and restart fully, then run claude doctor once more to confirm the connection now succeeds. If you are rolling Claude Code out across a corporate fleet and the certificate layer is fighting you, my door is open.

What Claude Code needs to run

Step back and the requirements are a short, checkable list. Claude Code needs a supported operating system, a recent macOS, Windows 10 or later, or a mainstream Linux. It needs an account that includes Claude Code, a Pro, Max, Team, Enterprise, or Console plan, since the free Claude.ai tier does not include it. It needs a working shell, and on Windows, Git for Windows for the best experience. And it needs the network: the proxy configured, the certificate trusted, the outbound domains allowlisted. That is the whole dependency set. The reason a corporate install feels hard is not that the list is long. It is that the last item, the network, is the one a developer cannot fix alone. Every one of those network details lives with IT, not with the developer, which means a smooth corporate setup is really a short, specific conversation with the right person, not a fight with the installer.

So the practical move is to front-load that conversation. Before you install anything, go to IT with three questions, and they are short ones. What is the HTTPS proxy address? Can you be given the corporate root CA certificate as a file? And will the small list of Anthropic domains be allowlisted? Get those three answers and the corporate install collapses back into the one-minute install it is on a home machine. Claude Code is a modern command-line tool like any other, and the ones that earn a place in a daily workflow are the ones that were set up properly once and then forgotten about. Do the network part first, with IT, and you never think about it again. Skip it, and you lose the afternoon this guide was written to save.