Github Copilot is not connecting | Friends of the Crustacean 🦞🤝 | Page 1

fervent notch Apr 17, 2026, 4:27 PM

#


🦞 OpenClaw 2026.4.15 (041266a) — More integrations than your therapist's intake form.

│
◇  GitHub Copilot ─────────────────────────────────────────────╮
│                                                              │
│  This will open a GitHub device login to authorize Copilot.  │
│  Requires an active GitHub Copilot subscription.             │
│                                                              │
├──────────────────────────────────────────────────────────────╯
┌  GitHub Copilot login
│
◐  Requesting device code from GitHub...│
◇  GitHub Copilot ───────────────────────────────────────╮
│                                                        │
│  GitHub Copilot login failed: TypeError: fetch failed  │
│                                                        │```

lapis perchBOT Apr 17, 2026, 4:27 PM

#

dull starBOT Apr 17, 2026, 4:30 PM

#

I'll check the TLS preflight helper too, since TypeError: fetch failed during device login is usually a network/TLS issue rather than a Copilot-specific auth issue.

#

That one is failing before Copilot auth even starts.

OpenClaw is trying to POST to GitHub’s device-login endpoint, and TypeError: fetch failed usually means one of these on the VM:

outbound HTTPS/DNS issue
proxy env missing/wrong
CA/TLS cert problem

Can you paste these 3 outputs?

openclaw status
curl -i -X POST https://github.com/login/device/code \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'client_id=Iv1.b507a08c87ecfe98&scope=read:user'
node -e "fetch('https://github.com/login/device/code',{method:'POST',headers:{Accept:'application/json','Content-Type':'application/x-www-form-urlencoded'},body:new URLSearchParams({client_id:'Iv1.b507a08c87ecfe98',scope:'read:user'})}).then(async r=>console.log('status=',r.status,'body=',(await r.text()).slice(0,200))).catch(e=>{console.error('message=',e.message); console.error('cause.code=',e.cause?.code); console.error('cause.message=',e.cause?.message)})"

#

Quick read on results:

curl fails too: network/DNS/firewall on the VM
curl works, Node fetch fails: usually TLS certs or proxy config
if you’re behind a proxy, make sure HTTPS_PROXY / HTTP_PROXY are set before running OpenClaw

if it looks like certs, on Ubuntu try:

sudo apt update && sudo apt install --reinstall ca-certificates

Copilot docs: https://docs.openclaw.ai/providers/github-copilot
General triage: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken

Paste those outputs and I’ll narrow it down.

fervent notch Apr 17, 2026, 4:31 PM

#

{"device_code":"9329ce31bfcb3d18cc812f72f01748d43393a616","user_code":"D922-5F53","verification_uri":"https://github.com/login/device","expires_in":899,"interval":5}message= fetch failed
cause.code= UND_ERR_CONNECT_TIMEOUT
cause.message= Connect Timeout Error (attempted address: github.com:443, timeout: 10000ms)
auki@auki-Virtual-Machine:~$

dull starBOT Apr 17, 2026, 4:33 PM

#

I’ve got enough to narrow it down now. I’m checking the Node/Undici side, because curl succeeded but Node fetch timed out, which usually points at IPv6/family-selection or proxy behavior rather than GitHub itself.

#

Nice, that narrows it down a lot.

The JSON response means GitHub is reachable from the VM.
The UND_ERR_CONNECT_TIMEOUT means Node/Undici is what’s failing, not Copilot auth itself.

Most likely cause: broken IPv6 / address-family selection on the VM.

Try this exact command:

NODE_OPTIONS='--dns-result-order=ipv4first --no-network-family-autoselection' openclaw models auth login-github-copilot --yes

If that works, the root issue is the VM’s networking, not OpenClaw credentials.

Then the longer-term fix is one of:

keep those NODE_OPTIONS for the shell/service running OpenClaw

#

fix or disable broken IPv6 on the VM
if you’re behind a proxy, make sure HTTPS_PROXY / HTTP_PROXY are set for Node too

If it still fails, paste these and I’ll keep drilling in:

node -p "require('node:dns').getDefaultResultOrder?.()"
node -p "require('node:net').getDefaultAutoSelectFamily?.()"
getent ahosts github.com
env | grep -iE 'https?_proxy|no_proxy'

Copilot docs, for reference: https://docs.openclaw.ai/providers/github-copilot

fervent notch Apr 17, 2026, 4:35 PM

#

auki@auki-Virtual-Machine:~$ NODE_OPTIONS='--dns-result-order=ipv4first --no-network-family-autoselection' openclaw models auth login-github-copilot --yes

🦞 OpenClaw 2026.4.15 (041266a) — I'm the middleware between your ambition and your attention span.

│
◇ GitHub Copilot ─────────────────────────────────────────────╮
│ │
│ This will open a GitHub device login to authorize Copilot. │
│ Requires an active GitHub Copilot subscription. │
│ │
├──────────────────────────────────────────────────────────────╯
┌ GitHub Copilot login
│
◐ Requesting device code from GitHub...│
◇ GitHub Copilot ───────────────────────────────────────╮
│ │
│ GitHub Copilot login failed: TypeError: fetch failed │
│ │
├────────────────────────────────────────────────────────╯
◓ Requesting device code from GitHub...Config overwrite: /home/auki/.openclaw/openclaw.json (sha256 1b7bd5305eb4dac7966f48f361fa9c71b70e00fa8ea8c6bed6ffb158268db44d -> 12b39c50a609aba99411cc47be5a55c7b8ef303f1bad55dd6ace67249f08791a, backup=/home/auki/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
◇ Canceled
auki@auki-Virtual-Machine:~$ node -p "require('node:dns').getDefaultResultOrder?.()"
node -p "require('node:net').getDefaultAutoSelectFamily?.()"
getent ahosts github.com
env | grep -iE 'https?_proxy|no_proxy'
ipv4first
true
140.82.121.3 STREAM github.com
140.82.121.3 DGRAM
140.82.121.3 RAW
auki@auki-Virtual-Machine:~$

dull starBOT Apr 17, 2026, 4:37 PM

#

I want one more data point before I send them down the wrong rabbit hole. I’m checking whether this looks like Undici-only behavior versus a broader Node TLS/socket issue.

#

Interesting, getent ahosts github.com only shows IPv4, so this does not look like the usual broken-IPv6 case anymore.

At this point I think it’s one of these:

Node/Undici is broken on that VM/runtime
something is affecting Node HTTPS sockets while curl still works

Fastest workaround worth trying, if you already use GitHub CLI:

export GH_TOKEN="$(gh auth token)"
openclaw models status

Do not paste the token here.
OpenClaw can use GH_TOKEN / GITHUB_TOKEN for Copilot auth: https://docs.openclaw.ai/providers/github-copilot

If you want, paste these next and I can narrow it down further:

#

node --version
node -e "require('node:https').get('https://github.com/login/device',res=>{console.log('https',res.statusCode);res.resume()}).on('error',e=>console.error('https',e.code,e.message))"
node -e "fetch('https://github.com/login/device/code',{method:'POST',headers:{Accept:'application/json','Content-Type':'application/x-www-form-urlencoded'},body:new URLSearchParams({client_id:'Iv1.b507a08c87ecfe98',scope:'read:user'})}).then(r=>console.log('fetch',r.status)).catch(e=>{console.error('fetch',e.cause?.code,e.cause?.message)})"

One more thing: that Config overwrite ... Updated ... Canceled output after a failed login looks suspicious to me. If this keeps reproducing, it’s probably GitHub-issue-worthy because the device-login flow should not be that messy on failure.

fervent notch Apr 17, 2026, 4:38 PM

#

I have already setup github cli before but auki@auki-Virtual-Machine:~$ export GH_TOKEN="$(gh auth token)" openclaw models status no oauth token found for github.com

dull starBOT Apr 17, 2026, 4:39 PM

#

Yep, that error is coming from gh, not OpenClaw. It means GitHub CLI is not actually logged in on that VM right now, so the GH_TOKEN workaround won’t help unless you first do gh auth login.

At this point, the useful next check is whether this is Undici/fetch only or all Node HTTPS.

Please paste these:

node --version
node -e "require('node:https').get('https://github.com/login/device',res=>{console.log('https',res.statusCode);res.resume()}).on('error',e=>console.error('https',e.code,e.message))"
node -e "fetch('https://github.com/login/device/code',{method:'POST',headers:{Accept:'application/json','Content-Type':'application/x-www-form-urlencoded'},body:new URLSearchParams({client_id:'Iv1.b507a08c87ecfe98',scope:'read:user'})}).then(r=>console.log('fetch',r.status)).catch(e=>{console.error('fetch',e.cause?.code,e.cause?.message)})"

What I’m looking for:

https works, fetch fails = likely Node/Undici runtime issue
both fail = broader Node networking/TLS issue on the VM

If you want to try the GitHub CLI route too, this is the right sequence:

#

gh auth login
export GH_TOKEN="$(gh auth token)"
openclaw models status

But I’d still like the Node output, because the same Node networking path may still bite later.

fervent notch Apr 17, 2026, 4:41 PM

#

yes I set the token and then how to check

dull starBOT Apr 17, 2026, 4:42 PM

#

I'll verify the quickest supported check before I tell them the wrong command.

#

I just want to make sure I use the exact infer flag shape from docs before I answer.

#

Yep, easiest check is:

openclaw models status
openclaw models status --probe --probe-provider github-copilot
openclaw infer model run --provider github-copilot --prompt "Reply with exactly: smoke-ok" --json

What you want to see:

models status shows GitHub Copilot auth is present
the --probe comes back ok
the infer model run returns smoke-ok

Small tip: prefer the explicit env var name:

#

export COPILOT_GITHUB_TOKEN="..."

That has higher priority than GH_TOKEN.

If models status still doesn’t see it, you’re probably running into shell-env loading. In that case put it in:

~/.openclaw/.env

like:

COPILOT_GITHUB_TOKEN=...

#

Then run openclaw models status again. If you paste the models status output, I can tell you exactly what it’s seeing.

fervent notch Apr 17, 2026, 4:45 PM

#

┌───────────────────────────┬────────────────────────┬────────────────────────────────┐
│ Model │ Profile │ Status │
├───────────────────────────┼────────────────────────┼────────────────────────────────┤
│ github-copilot/gpt-5-mini │ env (api_key) │ timeout · 27.8s │
│ │ │ ↳ fetch failed

dull starBOT Apr 17, 2026, 4:46 PM

#

I’m going to verify the exact Copilot endpoints OpenClaw hits so I don’t send them to probe the wrong host.

#

Perfect, that actually tells us a lot.

env (api_key) means OpenClaw is seeing your token now. So auth wiring is fixed.
The remaining problem is the live network call to GitHub Copilot timing out.

Please test the exact hosts Copilot uses:

node --version
curl -I https://api.github.com
curl -I https://api.individual.githubcopilot.com
node -e "fetch('https://api.github.com',{headers:{'User-Agent':'openclaw-debug'}}).then(r=>console.log('api.github.com',r.status)).catch(e=>console.error('api.github.com',e.cause?.code,e.cause?.message))"
node -e "fetch('https://api.individual.githubcopilot.com').then(r=>console.log('api.individual.githubcopilot.com',r.status)).catch(e=>console.error('api.individual.githubcopilot.com',e.cause?.code,e.cause?.message))"

What the results mean:

curl works, Node fetch fails → Node/Undici problem on the VM

#

both fail on api.individual.githubcopilot.com → network/firewall/domain block to Copilot
api.github.com works but Copilot host fails → specifically the Copilot endpoint is blocked

If it turns out to be Node-only, my next move would be a clean supported Node install (22+), then reinstall OpenClaw. If you paste those 5 outputs, I can tell you which bucket you’re in.

fervent notch Apr 17, 2026, 4:47 PM

#

I am working on a host windows vm linux

#

"fetch('https://api.individual.githubcopilot.com').then(r=>console.log('api.individual.githubcopilot.com',r.status)).catch(e=>console.error('api.individual.githubcopilot.com',e.cause?.code,e.cause?.message))"
v22.22.2
HTTP/2 200
date: Fri, 17 Apr 2026 16:47:13 GMT
cache-control: public, max-age=60, s-maxage=60
vary: Accept,Accept-Encoding, Accept, X-Requested-With
x-github-api-version-selected: 2022-11-28
access-control-expose-headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'
server: github.com
content-type: application/json; charset=utf-8
x-github-media-type: github.v3; format=json
etag: W/"4f825cc84e1c733059d46e76e6df9db557ae5254f9625dfe8e1b09499c449438"
accept-ranges: bytes
x-ratelimit-limit: 60
x-ratelimit-remaining: 59
x-ratelimit-used: 1
x-ratelimit-resource: core
x-ratelimit-reset: 1776448036
content-length: 2396
x-github-request-id: 542B:2DA5D3:211DAD8:1E0F79C:69E26414

HTTP/2 404
content-type: text/plain; charset=utf-8
x-content-type-options: nosniff
date: Fri, 17 Apr 2026 16:47:28 GMT
content-length: 19
x-github-backend: Kubernetes
x-github-request-id: 51F1:A8358:15A916A:17AB2F7:69E26420

api.github.com UND_ERR_CONNECT_TIMEOUT Connect Timeout Error (attempted address: api.github.com:443, timeout: 10000ms)
api.individual.githubcopilot.com UND_ERR_CONNECT_TIMEOUT Connect Timeout Error (attempted address: api.individual.githubcopilot.com:443, timeout: 10000ms)
auki@auki-Virtual-Machine:~$

dull starBOT Apr 17, 2026, 4:49 PM

#

Yep, that’s the smoking gun.

curl can reach both hosts, but Node 22.22.2 fetch times out to both.
So this is not a Copilot token problem anymore, and not really an OpenClaw auth problem either. It’s a Node/Undici networking issue on that VM.

I’d stop debugging Copilot config now and do this instead:

Install a fresh Node (I’d try a clean Node 24, or reinstall Node 22 from a proper source like nvm / NodeSource, not a weird distro build).
Reinstall OpenClaw.
Re-run this first:

node -e "fetch('https://api.github.com',{headers:{'User-Agent':'openclaw-debug'}}).then(r=>console.log(r.status)).catch(e=>console.error(e.cause?.code,e.cause?.message))"

If that works, then run:

#

openclaw models status --probe --probe-provider github-copilot

So the short version is: your token is being detected, but Node itself cannot make the outbound fetch calls reliably on that VM.

If you want, I can give you the shortest clean reinstall path next.

fervent notch Apr 17, 2026, 6:13 PM

#

auki@auki-Virtual-Machine:~/.openclaw$ openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
21:12:13 [agent/embedded] embedded run agent end: runId=33e5cda4-de6e-486e-bd5c-3ed0d6eff112 isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
21:12:17 [agent/embedded] embedded run agent end: runId=33e5cda4-de6e-486e-bd5c-3ed0d6eff112 isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
21:12:22 [agent/embedded] embedded run agent end: runId=33e5cda4-de6e-486e-bd5c-3ed0d6eff112 isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
^C21:12:32 [agent/embedded] embedded run agent end: runId=33e5cda4-de6e-486e-bd5c-3ed0d6eff112 isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
21:12:32 [agent/embedded] embedded run failover decision: runId=33e5cda4-de6e-486e-bd5c-3ed0d6eff112 stage=assistant decision=surface_error reason=timeout from=copilot-proxy/gpt-5-mini profile=sha256:d3c3e7a4e267
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "copilot-proxy",
"model": "gpt-5-mini",
"attempts": [],
"outputs": [
{
"text": "LLM request failed: network connection error.",
"mediaUrl": null
}
]

dull starBOT Apr 17, 2026, 6:14 PM

#

Ah, this explains a lot.

That infer model run did not use the built-in github-copilot provider.
It used:

provider=copilot-proxy

So this specific error means your local Copilot Proxy bridge is not reachable, usually because the VS Code Copilot Proxy path is configured but the extension/proxy is not running.

If you want to test the native GitHub Copilot provider, run it explicitly:

openclaw infer model run --provider github-copilot --prompt "Reply with exactly: smoke-ok" --json

#

And check your current default with:

openclaw models status

What this means:

copilot-proxy = local VS Code bridge path
github-copilot = built-in GitHub/Copilot auth path

So right now you may have both configured, but your default model/provider is landing on copilot-proxy.

If you do not want the VS Code proxy path, switch your default to a github-copilot/... model instead of a copilot-proxy/... one.

Docs: https://docs.openclaw.ai/providers/github-copilot

Paste the output of the explicit --provider github-copilot run, that’s the one we actually care about here.

fervent notch Apr 17, 2026, 6:14 PM

#

I have set proxy and I wanna test it

dull starBOT Apr 17, 2026, 6:15 PM

#

Yep, if you want to test the proxy path specifically, run it explicitly against copilot-proxy:

openclaw models status --probe --probe-provider copilot-proxy
openclaw infer model run --provider copilot-proxy --prompt "Reply with exactly: proxy-ok" --json

What success looks like:

probe shows ok
infer returns proxy-ok

If it still fails, paste that output.
And if this is the VS Code Copilot Proxy path, make sure the VS Code extension / local proxy is actually running first.

fervent notch Apr 17, 2026, 6:15 PM

#

how to set local proxy and extension

dull starBOT Apr 17, 2026, 6:16 PM

#

I’m pulling the exact docs section for the local Copilot Proxy setup so I can give the right extension + config steps, not a guess.

#

I’m checking for the exact extension reference so I don’t hand-wave the VS Code side.

#

If you want the local VS Code proxy route, the setup is basically this:

In VS Code
- install/sign in to GitHub Copilot
- install a Copilot Proxy extension
- start the proxy, and note its local base URL
  it must include /v1
In OpenClaw
```
openclaw plugins enable copilot-proxy
```
If you’re running the gateway/service, restart it after enabling.
Configure the provider

#

   openclaw models auth login --provider copilot-proxy --set-default

It will ask for:

Copilot Proxy base URL → example shape: http://127.0.0.1:PORT/v1
Model IDs → comma-separated models exposed by that proxy

Test it

openclaw models status --probe --probe-provider copilot-proxy
openclaw infer model run --provider copilot-proxy --prompt "Reply with exactly: proxy-ok" --json

A couple of important notes from the docs:

bundled plugins are disabled by default
the proxy extension must be running in VS Code
the base URL must include /v1

#

Docs:

If you want, paste the local proxy URL you configured, just the host/port/path, no secrets, and I’ll sanity-check whether it matches what OpenClaw expects.

fervent notch Apr 17, 2026, 6:17 PM

#

auki@auki-Virtual-Machine:~/.openclaw$ openclaw infer model run --provider copilot-proxy --prompt "Reply with exactly: proxy-ok" --json
error: unknown option '--provider'
auki@auki-Virtual-Machine:~/.openclaw$

dull starBOT Apr 17, 2026, 6:18 PM

#

I gave them the wrong flag. I’m checking the actual infer model run option shape in source so I can correct it cleanly.

#

Yep, that one is on me, your CLI wants --model, not --provider.

Try this instead:

openclaw models list | rg copilot-proxy
openclaw infer model run --model copilot-proxy/gpt-5-mini --prompt "Reply with exactly: proxy-ok" --json

If gpt-5-mini is not the exact model name in your proxy config, use whatever openclaw models list shows for copilot-proxy/....

You can also probe it directly with:

openclaw models status --probe --probe-provider copilot-proxy

#Github Copilot is not connecting