[BUG] 2.1.19x native CLI: OAuth login fails CERT_HAS_EXPIRED on claude.com / platform.claude.com (no proxy) — bundled Bun 1.4.0 regression vs 1.3.14

Open 💬 3 comments Opened Jun 27, 2026 by aguynamedryan

Preflight Checklist

  • [x] I searched existing issues. This is the no-proxy, OAuth-login, Linux variant of #71554 / #71581 (both closed without a shipped fix — still reproduces on current latest 2.1.195) and #71663 (open, but that one is via a CASB on the API path).
  • [x] Single bug report.
  • [x] Using the latest version (2.1.195).

What's Wrong?

On a clean, direct connection (no proxy, no VPN, no TLS inspection), claude auth login fails with:

Login failed: certificate has expired
SSL certificate error (CERT_HAS_EXPIRED).

Only OAuth login / token-refresh breaks — normal API calls keep working. The failing hosts are claude.com and platform.claude.com (/v1/oauth/token), which serve Let's Encrypt certs. api.anthropic.com (Google Trust Services cert) is unaffected, which is why everyday API traffic is fine and only login/refresh fails.

The certs are not expired and system trust is fine. The bug is in the bundled runtime (Bun 1.4.0), demonstrated on one machine, same network, same certs:

| Client | claude.com / platform.claude.com |
|---|---|
| curl / openssl / system Node 24 | ✅ HTTP 200, Verify return code: 0 (ok) |
| standalone Bun 1.3.14 (public release) | ✅ HTTP 200 |
| Claude Code bundled Bun 1.4.0 | ❌ CERT_HAS_EXPIRED |

Version boundary

grep -a 'Bun/' <native-version-binary> across builds:

2.1.169 / 2.1.175 / 2.1.177                          -> Bun 1.3.14  (login works)
2.1.181(stable) / 186 / 187 / 190 / 191 / 193 / 195  -> Bun 1.4.0   (CERT_HAS_EXPIRED)

Notes:

  • stable (2.1.181) is also Bun 1.4.0, so claude install stable does not help.
  • latest (2.1.195) is still Bun 1.4.0; the CHANGELOG for 2.1.193 -> 2.1.195 has no cert/TLS/OAuth/Bun entry.
  • Public Bun 1.3.14 is unaffected, so this is specific to the bundled runtime and cannot be fixed from Bun upstream — it needs Anthropic to roll the bundled Bun.

Workarounds that do NOT work

It's a cert-verification regression, not a missing trust anchor, so these are all ineffective: NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt, NODE_USE_SYSTEM_CA=1 (and BUN_CA_BUNDLE, per #71581).

What works

Downgrade to 2.1.177 (last build on Bun 1.3.14) + disable the auto-updater. (#71663 independently reports 2.1.170 works and 2.1.190+ fails.)

Steps to Reproduce

  1. Linux native install (Ubuntu 24.04), Max subscription, direct connection (no proxy/VPN/TLS-inspection).
  2. Let the OAuth access token expire (or claude auth logout), then claude auth login.
  3. Browser half completes; the CLI then fails with Login failed: certificate has expired.

Cert chains (all valid; the system bundle verifies them, return code 0)

claude.com          <- Let's Encrypt E7  <- ISRG Root X1                (notAfter ~Aug 2026 / Mar 2027)
platform.claude.com <- Let's Encrypt YE1 <- ISRG Root YE <- X2 <- X1    (2026-2032)
api.anthropic.com   <- Google Trust Services WE1 <- GTS Root R4         (works on bundled Bun)

Environment

  • Claude Code 2.1.195 (native install), bundled Bun 1.4.0
  • Linux (Ubuntu 24.04), x86-64
  • claude.ai Max subscription, OAuth auth — no proxy / VPN / TLS inspection

Related

  • #71554 (closed) — exact OAuth-login match (Windows), closed as completed without a fix; still reproduces on 2.1.195.
  • #71581 (closed dup) — Windows native, CERT_HAS_EXPIRED on platform.claude.com, clean connection.
  • #71663 (open) — same 2.1.190+ boundary, via a CASB on the API path.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗