Tested new TUI & CLI configuration setup for GHE in 0.24.3-beta.3:
Related PR:

• TUI feat(tui): configure Copilot GitHub Enterprise auth #1512
• Provider: feat(providers): support GitHub Enterprise Copilot auth #1509

CLI

netclaw provider add copilot-ghe github-copilot --auth oauth-device --github-host https://my-ghe.ghe.com --github-api-base https://api.myghe.
ghe.com

Device Oath flow functions & saves ok & reports healthy.

Update model + daemon stop / start & then:

Chat test:

You: hello are you there? │ │ [error] Unexpected LLM provider error (ClientResultException): Service request failed. │ │Status: 400 (Bad Request)

With the initial implementation on : #1491

Note: Not debug/checked myself why yet, just adding an issue here as a reminder that tested GHE 0.24.3-beta.3

Netclaw self diag

Netclaw: Found the trace

~/.netclaw/logs/sessions/signalr_a77aa89b05e64a46aa1cdc68e86f3678/session.log

Key details:

05:19:13 User: hello
05:19:13 GET https://api.my-ghe.ghe.com/copilot_internal/v2/token 
05:19:13 token response: 200
05:19:14 LLM provider unreachable — no fallback configured
System.ClientModel.ClientResultException: Service request failed.
Status: 400 (Bad Request)

Then Netclaw surfaced:

Unexpected LLM provider error (ClientResultException): Service request failed.
Status: 400 (Bad Request)
correlationId=2be6fa9b-f5ef-4158-93d4-2c48d72493f9

I also found repeated background/session distillation failures in:
~/.netclaw/logs/sessions/signalr_a80dc0b673a34c83a878c31ff524ccef/session.log

Same root symptom:

ClientResultException: Service request failed.
Status: 400 (Bad Request) 

Important clue: the GHE Copilot token exchange succeeds with HTTP 200, so auth/token retrieval looks OK. The actual OpenAI-compatible chat/completions request is getting HTTP 400.

Current daemon is healthy again and switched back to:

model: gpt-5.5
provider: my-private-openai

netclaw doctor only showed unrelated warnings; no provider-specific diagnostic beyond the session trace.

One limitation: the logs do not include the response body from the 400, only Status: 400 (Bad Request). To get the real server message, we probably need to add/enable richer logging around ClientResultException / OpenAI pipeline response content for non-secret error bodies.