How to properly configure Headroom with GitHub Copilot CLI on GitHub Enterprise (GHE)?

[flojud]

Hi everyone,

I am trying to set up Headroom for the GitHub Copilot CLI (gh copilot) within a GitHub Enterprise (GHE) environment (using a custom enterprise host instead of the public github.com).

However, I am running into authentication and routing issues depending on the approach. What I've tried:

Attempt 1: Using headroom wrap

When running:

headroom wrap copilot -i "Test 123 ..."

The CLI fails immediately with a BYOK (Bring Your Own Key) error, prompting me for a model:

Note: Copilot BYOK requires a model. Pass --model <name> or set COPILOT_MODEL / COPILOT_PROVIDER_MODEL_ID.

If I explicitly provide a model argument or env variable, Headroom routes the request to our internal endpoint but fails with an HTTP 401:

Authentication failed with provider at [http://127.0.0.1:8787/p/](http://127.0.0.1:8787/p/)... (HTTP 401). Check your COPILOT_PROVIDER_API_KEY.
(Note: As GHE users, we don't have a static OpenAI/Anthropic API key; we use our GHE AI credits).

Attempt 2: Using manual HTTPS_PROXY and headroom proxy

I tried starting the proxy standalone with my GITHUB_TOKEN pointing to our GHE API URL:

export GITHUB_TOKEN=$(gh auth token --hostname my-company.ghe.com)
export OPENAI_TARGET_API_URL="https://my-company.ghe.com/api/v3"

headroom proxy --port 8787 --no-telemetry --insecure

And then routing copilot through it via environment variables:

export HTTP_PROXY="http://127.0.0.1:8787"
export HTTPS_PROXY="http://127.0.0.1:8787"
copilot -i "Test 123 ..."

This results in a network fetch error:

Authentication token found but could not be validated
Failed to fetch OAuth user login: network fetch failed: request failed: error sending request for...

My Question:
Has anyone successfully wired up gh copilot via Headroom in a GitHub Enterprise environment?
What is the correct way to pass the GHE OAuth token/PAT and route the endpoints through Headroom without it defaulting to a BYOK third-party provider setup?

Any guide, environment variable checklist, or config snippet would be highly appreciated!

Thanks in advance!

[richardchen874-sys]

I think the issue here is that two different routing modes are being mixed together.

headroom wrap copilot seems to push the request into a BYOK-style provider path, which expects a provider model and a provider API key. That is why it starts asking for COPILOT_MODEL / COPILOT_PROVIDER_MODEL_ID, and then fails with COPILOT_PROVIDER_API_KEY.

But for GitHub Enterprise Copilot, you probably do not want Headroom to behave like an OpenAI/Anthropic BYOK proxy. You want it to preserve the GitHub Enterprise authentication flow and only proxy the Copilot/GitHub traffic correctly.

A few things I would separate while debugging:

• GHE auth token vs third-party provider API key
• GitHub API endpoint vs model provider endpoint
• gh auth token --hostname ... vs normal GITHUB_TOKEN
• whether gh copilot actually honors HTTP_PROXY / HTTPS_PROXY
• whether the proxy is rewriting requests meant for GHE into provider-style routes
• whether the OAuth validation call is being sent to the GHE host or accidentally to the wrong upstream
• whether the proxy supports GitHub Enterprise Copilot endpoints specifically, not only public github.com Copilot traffic

The key clue is the OAuth validation failure:

Authentication token found but could not be validated

That sounds like the token itself may be valid, but the request path, hostname, or upstream target is not what gh copilot expects in a GHE setup.

The first thing I would check is the proxy logs for the OAuth validation request:

• incoming host
• outgoing host
• path
• Authorization header presence, not the value
• whether the request goes to my-company.ghe.com/api/v3 or somewhere else

If that request is being routed through the BYOK/provider path, then the model settings will not fix it. The proxy needs a separate GitHub Enterprise Copilot mode or a config option that keeps GHE auth and Copilot routing separate from third-party provider routing.

[highoncomputers]

Headroom's wrap copilot command targets the public github.com Copilot BYOK flow, which uses a third-party API key. GitHub Enterprise (GHE) Copilot uses GHE's own AI credits and OAuth-based auth, so wrap copilot won't work directly.

The core problem: GHE Copilot authenticates via OAuth tokens to your GHE instance, not via an independent API key. Headroom's wrap intercepts the request and tries to forward it to a configured provider (OpenAI/Anthropic/OpenRouter) using a provider API key. But GHE Copilot doesn't have a provider API key — it uses GHE's built-in AI endpoint.

Working approach — Use headroom proxy in OpenAI mode:

export GITHUB_TOKEN=$(gh auth token --hostname my-company.ghe.com)
headroom proxy --port 8787 --backend openai --no-telemetry

Then configure Copilot to talk to Headroom by setting Copilot's provider to OpenAI and pointing it at the proxy:

gh copilot config set model_provider openai
gh copilot config set openai_base_url http://127.0.0.1:8787/v1

What this does: GHE Copilot sends requests to the Headroom proxy (OpenAI-compatible endpoint). Headroom then forwards them to your configured --backend (in this case OpenAI, but you could also use --backend openrouter if you want to route through a different provider).

Important caveats:

• You still need a valid upstream API key for the backend Headroom forwards to (Headroom itself is a proxy, not a model provider)
• GHE Copilot's model availability depends on your GHE subscription — you may need to set COPILOT_PROVIDER_MODEL_ID=gpt-4o or similar
• The --insecure flag you tried lets Headroom accept self-signed certs but doesn't fix the auth mismatch

Simplest recommendation: If you just want caching/metrics on GHE Copilot traffic, the headroom proxy approach above works. But if you don't need Headroom's features specifically, GHE Copilot works fine on its own — the auth complexity of routing it through Headroom may not be worth the benefit.

[richardchen874-sys]

Good breakdown. I think the key distinction is exactly this: Headroom can proxy an OpenAI-compatible backend, but that does not automatically mean it can preserve the native GHE Copilot OAuth flow.

So for this setup there are really two different goals:

1. keep using GHE Copilot credits/auth directly
2. use Headroom as a provider-routing layer with an OpenAI-compatible backend

Those two paths may look similar from the CLI side, but the auth model is very different. If the goal is routing to another backend, then an upstream API key/model config is expected. If the goal is only metrics/caching for native GHE Copilot traffic, then the proxy needs to preserve GHE OAuth and endpoint routing much more carefully.

I’ve been looking at multi-model API/provider routing recently, and this kind of auth boundary is usually where these integrations get tricky.

[gethari]

So doing this may not work when using Copilot from vscode with Claude models right ?

[richardchen874-sys]

So doing this may not work when using Copilot from vscode with Claude models right ?

Yes, that’s my understanding too.

If you are using the native Copilot flow inside VS Code and selecting Claude models through GitHub/Copilot, then this may not behave like a normal OpenAI-compatible provider setup. Copilot is usually handling its own auth, model selection, and routing behind the scenes, so a local proxy cannot always replace or observe that path cleanly.

Where Headroom is more likely to work is when the client lets you explicitly set a custom base URL, API key, and model name — for example routing requests into an OpenAI-compatible backend.

So I think it depends on your goal:

• if you want to keep native VS Code Copilot + Claude behavior, proxying may be limited
• if you want to route a Copilot-like workflow through another backend/provider, then a custom OpenAI-compatible path is more realistic

Are you mainly trying to observe/cache the native Copilot Claude traffic, or are you trying to replace the backend with another provider while keeping the VS Code workflow?

[gethari]

I want to be able to use headroom natively from vscode prompts, I do not want to repeatedly change models from CLI/vise-versa. I guess this flow does not work now, so headroom is useless for me, even if I wanted to use the CLI the model is limited right

[richardchen874-sys]

I want to be able to use headroom natively from vscode prompts, I do not want to repeatedly change models from CLI/vise-versa. I guess this flow does not work now, so headroom is useless for me, even if I wanted to use the CLI the model is limited right

That makes sense — your use case is clearer now.

You are not just looking for a CLI workaround. You want Headroom to sit inside the normal VS Code prompt/Copilot workflow, so you don’t have to keep switching models or moving between CLI and VS Code. If the model routing only works from CLI, then it does not really solve your day-to-day workflow problem.

So I think the practical feature gap here is:

• native VS Code prompt/Copilot integration
• model/provider routing without leaving the IDE
• no repeated CLI-side model switching
• clear support for which models/providers are actually available in that path

If Headroom cannot hook into the native VS Code Copilot/Claude flow today, then yes, the current flow may be limited for your case. But I would still separate that from the broader idea: the need is not “CLI proxy works or not,” it is “can Headroom become a routing/control layer directly inside the IDE workflow?”

That might be a very useful feature request for the maintainers. Would your ideal setup be something like selecting a Headroom-managed provider/model directly from VS Code, while keeping the same prompt experience?