[BUG] Claude Cowork — "Self-signed certificate detected" on macOS with no proxy

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/20194
2. https://github.com/anthropics/claude-code/issues/24260
3. https://github.com/anthropics/claude-code/issues/21652

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

what now guys, am consistently facing this issue - wasting time that max was subscribed for

same

@saadinxs @mateenmotavaf @chrisjarviscan Try installing this extension in VSCode. I guess that's the fastest way to fix this.

<img width="974" height="482" alt="Image" src="https://github.com/user-attachments/assets/b6e21ce4-098f-4cd7-a71d-e2d66bdf5e14" />

Then hit Settings

<img width="683" height="536" alt="Image" src="https://github.com/user-attachments/assets/09d0740b-6f6b-46fc-a550-3e3541210a6e" />

Set it up like this

<img width="515" height="237" alt="Image" src="https://github.com/user-attachments/assets/ad10e24c-c4b0-43ea-94a0-3d724ba4b1df" />

And it solved my issue with certs

@saadinxs @mateenmotavaf @chrisjarviscan Try installing this extension in VSCode. I guess that's the fastest way to fix this. <img alt="Image" width="974" height="482" src="https://private-user-images.githubusercontent.com/49472529/549668092-b6e21ce4-098f-4cd7-a71d-e2d66bdf5e14.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzEwMTkzNTQsIm5iZiI6MTc3MTAxOTA1NCwicGF0aCI6Ii80OTQ3MjUyOS81NDk2NjgwOTItYjZlMjFjZTQtMDk4Zi00Y2Q3LWE3MWQtZTJkNjZiZGY1ZTE0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAyMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMjEzVDIxNDQxNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTZlYWU1NmJmMDJkNDEyZmNhNDdlYjFlYTVlYmY2ODM4ZDY4ZmNlNTgwYzZhYTk4Y2RmODUzYzE5MjA1ZmU1NDYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.Q0_J2SDuYOGcOX65DKm8Jok1aFxuxxwNqBSPW-LXB88"> Then hit Settings <img alt="Image" width="683" height="536" src="https://private-user-images.githubusercontent.com/49472529/549668259-09d0740b-6f6b-46fc-a550-3e3541210a6e.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzEwMTkzNTQsIm5iZiI6MTc3MTAxOTA1NCwicGF0aCI6Ii80OTQ3MjUyOS81NDk2NjgyNTktMDlkMDc0MGItNmY2Yi00NmZjLWE1NTAtM2UzNTQxMjEwYTZlLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAyMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMjEzVDIxNDQxNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTYzNzU2Y2QxMTZiNTgxOWUyMjllOTViODFiNTY4M2Q0ZjZiNjA3NDVhNWZlNGIxOTZkYTA0YWY4MjVjY2EwNjcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.WU64SUViFUTGCX6ij6arZ-MEPQIfl7M0DVSByPj8shI"> Set it up like this <img alt="Image" width="515" height="237" src="https://private-user-images.githubusercontent.com/49472529/549668317-ad10e24c-c4b0-43ea-94a0-3d724ba4b1df.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzEwMTkzNTQsIm5iZiI6MTc3MTAxOTA1NCwicGF0aCI6Ii80OTQ3MjUyOS81NDk2NjgzMTctYWQxMGUyNGMtYzRiMC00M2VhLTk0YTAtM2Q3MjRiYTRiMWRmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAyMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMjEzVDIxNDQxNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPThhMmNjNzZlMzVkOWQyZDY0ZjJhODRmMmE4Njc5ZDM3NGZhN2M5MDk3ZTI1ZTRkMWZkMTdkNmM2NGM1ZjRjZDUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.43702ZvqyY4IbVrv-OvYS13ZtjJVn9ZwFTg4odNc2FA"> And it solved my issue with certs

thanks! they updated the app and it seems to be working again, if it crashes will come back to this

You could file this as a comment on #24470 with the specific log line:

Root cause found: coworkd generates an ephemeral MITM proxy CA but fails to install it because wc is missing from the VM image:
[proxy] failed to install CA to trust store: update-ca-certificates failed: exit status 127:
/usr/sbin/update-ca-certificates: 167: wc: not found
The Claude Code process inside the VM then rejects the proxy's self-signed cert. This affects all users, not just those on corporate networks.

This is entirely on Anthropic to fix — they need to include coreutils (or at least wc) in the VM image. Found a workaround, posting below.

Workaround:

# Quit Claude Desktop first, then:
docker run --rm -it --privileged \
  -v "$HOME/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img":/rootfs.img \
  ubuntu:22.04 bash -c '
    mkdir /mnt/vm && 
    mount -o loop,offset=105906176 /rootfs.img /mnt/vm && 
    cp /usr/bin/wc /mnt/vm/usr/bin/wc && 
    chmod 755 /mnt/vm/usr/bin/wc && 
    umount /mnt/vm && 
    echo "Done! wc installed."'

Experiencing Similar Issue: Claude Code Cloud + Google Docs API

Environment: Claude Code on the web (Cloud)
Error: ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
Context: Calls to googleapis.com (domain explicitly whitelisted in "Limited"/Trusted network mode)

The Problem

Same pattern as described here: when using Python libraries that enforce strict SSL certificate validation (e.g., google-api-python-client, requests, urllib3), requests fail at the TLS handshake stage.

Key observations:

• ✅ Domain whitelisting works fine (traffic reaches Anthropic's proxy)
• ✅ Network access is not blocked (proxy allows *.googleapis.com)
• ❌ SSL certificate validation fails (proxy cert is not trusted by Python's certifi bundle)
• ✅ Same operation works perfectly on local Claude Code (desktop/CLI)

Confirms Bun Runtime Issue

This strongly confirms the root cause is the Bun native runtime (v2.1.17+) not using the system certificate chain properly. The Bun binary likely has a hardcoded or incomplete certificate bundle that doesn't trust Anthropic's proxy certificates.

Attempted Workarounds (All Failed)

# None of these worked in Claude Code Cloud:
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt
export NODE_OPTIONS="--use-openssl-ca"
export PYTHONHTTPSVERIFY=0  # ⚠️ Dangerous, but even this doesn't help

Affected Libraries

Any Python library that validates SSL certificates:

• google-api-python-client (confirmed)
• requests
• httpx
• urllib3

Why This is Critical

Google Docs API, AWS SDK, Azure SDK, and other cloud APIs all rely on proper SSL validation. The current Bun runtime breaks all of them in Claude Code Cloud, limiting functionality to basic network calls only.

Proposed Solution

Same as in #20194: Anthropic should either:

1. Inject proxy CA certificate into the Bun environment at runtime
2. Fix Bun runtime to respect NODE_EXTRA_CA_CERTS and system certificate chains
3. Switch back to Node.js for Cloud environments (keep Bun for desktop/CLI if preferred)

This is blocking production use of Claude Code Cloud for any integration with external APIs.

---

Thanks for tracking this. Looking forward to a fix in the next release.

Same issue here. Using Claude Desktop app (Code tab) behind ZScaler corporate proxy. Terminal Claude Code works fine with NODE_EXTRA_CA_CERTS, but the desktop app's Code tab ignores it. Only NODE_TLS_REJECT_UNAUTHORIZED=0 makes it work, which is not ideal for security. Please support NODE_EXTRA_CA_CERTS in the Bun runtime for the desktop app.

Same issue here. Using Claude Desktop app (Code tab) behind ZScaler corporate proxy. Terminal Claude Code works fine with NODE_EXTRA_CA_CERTS, but the desktop app's Code tab ignores it. Only NODE_TLS_REJECT_UNAUTHORIZED=0 makes it work, which is not ideal for security. Please support NODE_EXTRA_CA_CERTS in the Bun runtime for the desktop app.

Users at our company are also experiencing the same issue.

Unfortunately, I don't think this is something that can be fixed in this repository, it needs to be fixed in the Claude Desktop App itself which is not open source. Based on my testing, below is a summary of the root cause of the issue in case it is helpful to the team at Anthropic that works on the Desktop App. I'm also happy to share my findings more directly with them if there is a more appropriate place to do so.

Root cause identified via source analysis:

The Electron app explicitly constructs the claude-code subprocess environment in mft() starting with {...process.env}. However, empirical testing shows NODE_EXTRA_CA_CERTS does not propagate to the subprocess even when correctly set via launchctl setenv and confirmed present in the Electron process environment via ps ewww. This is likely because mft() executes in a sandboxed renderer process where process.env is a reduced set. The env block in settings.json also fails because it is applied after Node.js TLS initializes. The minimal code fix would be to explicitly forward NODE_EXTRA_CA_CERTS in ske() or mft() by reading it from the main process environment via IPC.

Hey folks, self signed certificates are supported in Cowork if they are in your systems root CA trust store. For people using zscaler this _should_ be the case. Basically when we start Coworks environment we copy the trusted CA certificates from your host (macOS or Windows) into the environment and add them to the trust store.

If you have your CA cert installed and trusted in Keychain on macOS and this issue is still happening, please make sure you've sent feedback and tag me below. I'll take a look. My current instinct is this is working as intended unless there's an issue with our CA trust copying logic.

As for the issue @morenoceler noted, yeah we've seen that in logs too but coreutils is in the VM image and we're not sure how it disappeared for some users 😓 Reinstalling the VM image seems to fix it and we're tracking it to make sure it's not an ongoing issue (it seems to be going away)

I'm getting this with GLobalProtect VPN on. Unable to connect to API: Self-signed certificate detected. Check your proxy or corporate SSL certificates.
The certificate is in the system store and is trusted

@pandeytanmay Can you confirm your Claude Desktop version and that you've sent feedback with logs? (Include this github issue url in your feedback so I can find it easier)

For what it's worth, I'm running Claude Desktop Version 1.0.1768 (67d013) on Windows and have the exact same experience on my corporate laptop with GlobalProtect VPN on. Within the Code tab within Claude desktop, I just get the API connection error related to SSL. The certificates are in the system store. The Claude Code CLI and the Claude Code for VSCode extension work with the NODE_EXTRA_CA_CERTS environment variable, but this is not picked up by Claude Desktop. Incidentally, if I turn the VPN off, it works, but that is not ideal.

NODE_EXTRA_CA_CERTS is not the way to configure this for desktop applications, ensure your CA is installed as a trust root on your machine. Claude Desktop and Cowork both use the trust roots on your machine including custom ones so if you install a custom CA and trust it properly in windows it should Just Work

NODE_EXTRA_CA_CERTS is not the way to configure this for desktop applications, ensure your CA is installed as a trust root on your machine. Claude Desktop and Cowork both use the trust roots on your machine including custom ones so if you install a custom CA and trust it properly in windows it should Just Work

Thanks @MarshallOfSound. Agreed that Claude Desktop should respect the trust roots as that is typically the behavior for GUI applications. I can't comment on our Windows users setup but I am on Mac and can confirm the custom cert is trusted in the MacOS keychain.

To be clear, my issue was Claude Code specifically was not working in Claude Desktop, Cowork and Chat worked fine. However, if I understand how Claude Code is implemented, it is just calling the claude-code executable and essentially rendering a "view" that it runs in. I could be wrong there, but there is definitely something different and it isn't respecting the trusted certs in the MacOS keychain.

NODE_EXTRA_CA_CERTS is not the way to configure this for desktop applications, ensure your CA is installed as a trust root on your machine. Claude Desktop and Cowork both use the trust roots on your machine including custom ones so if you install a custom CA and trust it properly in windows it should Just Work

I ended up setting this environment variable: SSL_CERT_FILE
When that is pointing to an exported trusted root certificate, it works. But without it it doesn't. I tried with Claude Desktop Version 1.1.4498 (24f768)

To be clear, my issue was Claude Code specifically was not working in Claude Desktop, Cowork and Chat worked fine.

Oh I see, I'll check in with folks tomorrow and see what the state is with Claude Code for Desktop. Definitely want to support custom CAs _somehow_ there

@MarshallOfSound same issue with setting up explicit proxy using the env variable HTTPS_PROXY or the arg --proxy-pac-url, both don't propagate from the Claude desktop app to Cowork environment. Happy to open another issue if you feel it's too distinct from this issue - but it feels to me it's the same root cause.

> To be clear, my issue was Claude Code specifically was not working in Claude Desktop, Cowork and Chat worked fine. Oh I see, I'll check in with folks tomorrow and see what the state is with Claude Code for Desktop. Definitely want to support custom CAs _somehow_ there

On MacOS, providing SSL_CERT_FILE was a suitable fix though difficult to deploy without affecting other applications. Our test suite includes MCPs, and WebFetch/WebSearch.

Claude Code in Claude Desktop on Windows is not fixed by supplying the SSL_CERT_FILE environment variable.

If anyone finds a resolution for Claude Code in Claude Desktop on Windows, please give me a mention! Greatly appreciated.

Unfortunately, setting SSL_CERT_FILE to my employer's cert bundle does not fix the Claude Code through the Claude Desktop app on MacOS when SSL interception is enforced. Cowork and Chat work fine however.

I'm on version Claude 1.1.7714 (3bd6f6) 2026-03-19T14:50:53.000Z

Setting the NODE_EXTRA_CA_CERTS plus SSL_CERT_FILE got my Claude Code in Claude Desktop for Windows working after fully closing Claude from the notification area, for the CLI just NODE_EXTRA_CA_CERTS was needed

likely a Claude Desktop version issue over 48 hrs: on macOS, claude code in vs code suddenly had the issue indicated in this thread. put in export NODE_TLS_REJECT_UNAUTHORIZED=0, CC worked. about 12 hours later, updated claude desktop. 12 hrs later, CC stoped working. unset that env, now working again ...throughout, claude desktop was working. bet claude desktop messed up with claude code.

it was working fine for me yesterday, after I updated new version.

Hey @MarshallOfSound and everyone else, I had this exact same issue in a corporate environment today, and our security guy found a really solid workaround

This part is universally required:

• Open Keychain Access
• Find your root CA, there should only be one, maybe two
• Select them all, export as a PEM file, and save them somewhere like $HOME/.certs/root.pem

This part is just for Claude via terminal:

• Open your shell rc file (~/.zshrc, ~/.bash_profile, or the like)
• Set these three properties based on where you saved your root.pem file

export NODE_EXTRA_CA_CERTS="$HOME/.certs/root.pem"
export SSL_CERT_FILE="$HOME/.certs/root.pem"
export NODE_OPTIONS="--use-openssl-ca"

• Claude Code from the Terminal (or as a vscode plugin) should work now ✨

This part is just for Claude Desktop:

• Create a launchctl plist file for Claude at ~/Library/LaunchAgents/com.claude.env.plist
• Then, add the following content to set runtime properties Claude Desktop reads on startup

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.claude.env</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>-c</string>
    <string>
      launchctl setenv NODE_EXTRA_CA_CERTS /Users/YOUR_USERNAME/.certs/your-cert.pem;
      launchctl setenv SSL_CERT_FILE /Users/YOUR_USERNAME/.certs/your-cert.pem;
      launchctl setenv NODE_OPTIONS --use-openssl-ca
    </string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

• Run launchctl load ~/Library/LaunchAgents/com.claude.env.plist in a terminal to load the file you just made
• Close Claude and make sure the program fully shuts down, killall claude in the terminal should do the trick if it's being stubborn
• Claude desktop should work now ✨

Basically, we figured out that the Bun runtime isolates some network stuff so it can't see these certs, this workaround should be all you need if you're still having this issue

@asyncjake 's fix for Claude Code on Desktop also works for Windows, here's how!

This Powershell script exports all root certificates to a single pem file. Make sure to correct your outDir Variable to some path where you want to store your certificates. Note that this is referenced for future certifacte usages, so if you fundamentally update your certificates, you might have to repeat the export. So this is only a temporary solution until a more permanent comes along!

$outDir = "C:\Daten\certificates"
$outFile = "$outDir\ca-bundle.pem"

New-Item -ItemType Directory -Force -Path $outDir | Out-Null

$out = @()
Get-ChildItem Cert:\LocalMachine\Root | ForEach-Object {
    $out += "# $($_.Subject)"
    $out += "-----BEGIN CERTIFICATE-----"
    $out += [System.Convert]::ToBase64String($_.RawData, 'InsertLineBreaks')
    $out += "-----END CERTIFICATE-----"
    $out += ""
}

$out | Out-File -FilePath $outFile -Encoding ascii

Then, execute these commands, also mind the correct path for your machine:

[System.Environment]::SetEnvironmentVariable("NODE_EXTRA_CA_CERTS", "C:\Daten\certificates\ca-bundle.pem", "User")
[System.Environment]::SetEnvironmentVariable("SSL_CERT_FILE", "C:\Daten\certificates\ca-bundle.pem", "User")
[System.Environment]::SetEnvironmentVariable("NODE_OPTIONS", "--use-openssl-ca", "User")

Afterwards, force kill Claude like so:

taskkill /IM claude.exe /F

After the restart, Claude code worked fine!

This started affecting our Windows 11/AMD64 users this week. They were unable to access a remote MCP due to node complaining about the cert. MacOs users and Windows 2025, Windows 11/Arm64 were not affected. Uninstalling and reinstalling claude from the downloads available yesterday did not fix the issue. The version reported for all windows users was the same: Version 1.6608.2 (ebf1a1). Env vars seemed to be ignored, so ultimately, I fixed our affected users by downloading node and running a local proxy terminated on their machine. Looking forward to this being fixed. I have a lengthy report prepared by claude which I will omit because I think most of it is captured above.

<img width="778" height="105" alt="Image" src="https://github.com/user-attachments/assets/4220bda2-ee4d-4ae6-87dc-ce55e3cb0287" />

API Error: Unable to connect to API: Self-signed certificate detected. Check your proxy or corporate SSL certificates

Relogin doesn't help.

My solution for Claude Code: https://github.com/anthropics/claude-code/issues/74369#issuecomment-4889223409.
Not sure if it can fix Claude Cowork for others because I don't use it yet.