GitHub Copilot Authentication Failure on macOS Across Multiple Editors

まず copilot.vim で :Copilot setup を使って失敗を再現し、動作しているコンピューターとレスポンス処理を比較します。issue にはソースファイルやテストが記載されていないため、報告された E-32603 と content-type のないレスポンスの周辺にある認証フローを追跡します。macOS でのローカルなレスポンス変更が原因なのか、上流の認証変更が原因なのかを特定し、再現可能な修正または診断を文書化できれば完了です。

GitHub Copilot Authentication Failure on macOS Across Multiple Editors

Summary

GitHub Copilot authentication fails on one specific macOS machine across multiple editors/applications despite:

• clean network tests
• no proxy configured
• valid GitHub TLS certificates
• firewall/security tools disabled
• hotspot testing
• successful operation on another computer on the same network

The issue appears local to this Mac.

---

Environment

Hardware / OS

• macOS
• Apple Silicon MacBook Pro (M4 Max)

Editors / Clients Affected

• Neovim + copilot.vim
• Zed

Versions

copilot.vim

copilot.vim 1.59.0
GitHub Copilot Language Server 1.485.0

Node

Initially tested with:

Node.js 24

Also tested with latest LTS Node.

---

Symptoms

Neovim / copilot.vim

Authentication fails during:

:Copilot setup 

Observed errors:

E-32603
Response content-type is missing (status=200)

and:

HTTP 200 response does not appear to originate from GitHub

---

Zed

• Unable to log into GitHub Copilot at all
• Inline predictions cannot initialize because auth never completes

---

Important Observation

A different computer on the SAME network can authenticate and use GitHub Copilot successfully.

This strongly suggests the issue is local to this specific Mac.

---

Network / TLS Diagnostics

Proxy Checks

env | grep -i proxy
git config --global --get http.proxy
git config --global --get https.proxy
npm config get proxy
npm config get https-proxy

Results:

No proxy configured
npm proxy values = null

---

System Proxy

scutil --proxy
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

Results:

Enabled: No 

---

TLS / Connectivity Tests

GitHub API

curl -Iv https://api.github.com 

Results:

• Valid TLS
• Correct GitHub certificate
• HTTP/2 200
• content-type: application/json

Issuer:

Sectigo Public Server Authentication CA DV E36 

---

GitHub Device Login Endpoint

curl -Iv https://github.com/login/device/code 

Results:

• Valid TLS
• GitHub headers present
• HTTP/2 404 (expected for HEAD request)

---

Copilot API

curl -Iv https://api.githubcopilot.com 

Results:

• Valid TLS
• Correct GitHub Copilot certificate
• HTTP/2 404
• GitHub backend headers present

---

Remediation Attempts

Disabled Security Tools

• Firewall disabled
• Little Snitch disabled

No change.

---

Network Isolation

• Tested via hotspot

No change.

---

Cache Removal

Removed:

~/.cache/github-copilot
~/.cache/copilot.vim
~/.npm/_npx
~/Library/Application Support/Zed
~/Library/Caches/Zed
~/Library/Logs/Zed

No change.

---

Reinstalled copilot.vim

Original install was tarball-based.

Replaced with clean git clone:

git clone --depth=1 https://github.com/github/copilot.vim.git \
  ~/.config/nvim/pack/github/start/copilot.vim

No change.

---

Node Version Changes

Tested:

• Node 26
• Latest LTS

No change.

---

GitHub Auth Cleanup

• Revoked OAuth applications
• Cleared GitHub/Copilot-related Keychain entries
• Re-authenticated

No change.

---

Additional Notes

The error pattern appears similar to recent upstream reports involving:

Response content-type is missing (status=200) 

and Copilot auth parsing failures.

Potentially related upstream issues:

• github/copilot.vim issue #281
• similar reports involving copilot-language-server auth responses

---

Request

Looking for guidance on:

1. why this specific Mac receives/parses malformed auth responses
2. whether a recent Copilot auth backend change could trigger this behavior
3. additional macOS-level diagnostics for response mutation/auth parsing failures