Repository navigation
**Title:** GitHub Copilot App BYOK fails with OpenAI-compatible endpoint whil... #2903
Description
Title: GitHub Copilot App BYOK fails with OpenAI-compatible endpoint while VS Code works
I'm using an OpenAI-compatible BYOK endpoint from OpenCode Go.
The same endpoint, API key, and model work normally when configured in VS Code, but fail when configured in the GitHub Copilot App.
The Copilot App returns HTTP 400 errors such as:
Failed to deserialize the JSON body into the target type:
messages[1]: unknown variant `image_url`, expected `text`
and:
invalid_request_error:
Extra inputs are not permitted,
field: `messages[2].refusal`,
value: None
Steps to reproduce:
- Configure the OpenCode Go OpenAI-compatible endpoint in VS Code.
- Use the model normally — requests succeed.
- Configure the same endpoint, API key, and model in GitHub Copilot App using BYOK.
- Send a request.
- GitHub Copilot App returns HTTP 400.
Expected behavior:
The same OpenAI-compatible endpoint should work in GitHub Copilot App as it does in VS Code.
Actual behavior:
Requests from GitHub Copilot App contain fields/message formats that the endpoint rejects, while VS Code requests succeed.
I'm not sure whether this is caused by the Copilot App request payload or an incompatibility in the endpoint, but the issue is reproducible specifically with GitHub Copilot App.
| Field | Value |
|---|---|
| App version | 1.1.10 |
| OS | Windows 10.0.26300 |
| Theme | GitHub |
| Path | /chat |
| Tenure | Week 9 |
Activity
Cokedog320 commentedon Aug 19, 2026
Additional analysis from investigating the failure — this report actually contains two distinct compatibility errors with different implications:
Error 1: messages[1]: unknown variant 'image_url', expected 'text'
This is a Rust serde enum error, meaning the OpenCode Go backend models message content as an enum that only accepts a ext variant. It rejects image_url (multimodal image content blocks). This is a narrower schema than standard OpenAI — the Copilot App is sending standard OpenAI multimodal format here.
Error 2: messages[2].refusal, value: None
efusal is a field the OpenAI SDK attaches to assistant messages by default (value None). Standard OpenAI-compatible endpoints accept it. The OpenCode backend rejects it because its schema doesn't allow extra fields.
Common thread: Both errors point to the OpenCode Go backend having a message schema stricter than standard OpenAI — it accepts neither the image_url content variant nor the
efusal field. VS Code likely works because its requests either don't include image content blocks or construct messages differently.
Suggested way to narrow this down: Try a text-only conversation with no images/screenshots. If the image_url error disappears and only
efusal remains, that isolates the two issues. It would also help confirm whether the Copilot App is sending image content blocks where the endpoint doesn't support them.
For reference, the
efusal issue is exactly what OpenAI-compatible clients normally guard against by whitelisting message fields before sending — see e.g. the sanitization in the wenyi project's _openai_compatible.py, which strips
efusal and other non-standard fields before forwarding.
Triumph1701 commentedon Aug 20, 2026
Your latest split points to two separate compatibility layers: the content blocks (image_url) and the non-standard refusal field. I’d capture the exact JSON emitted by the Copilot App and compare it with the working VS Code request, then normalize each block and strip unsupported fields before forwarding; otherwise a generic 400 hides which layer failed. Disclosure: I'm building Your Model, a multi-model OpenAI-compatible API for developers. If you're comparing a second endpoint on the same workload, happy to add some test credits.
Cokedog320 commentedon Aug 21, 2026
Thanks for the detailed suggestion! I’ll try to capture the exact JSON emitted by the Copilot App and compare it with the working VS Code request to see where the difference is coming from.
And thanks for the offer of test credits as well — really appreciate it!
Triumph1701 commentedon Aug 22, 2026
The VS Code/Copilot difference points to request-shape normalization rather than auth or the model itself. A useful compatibility matrix would test text-only, image_url, refusal:null, tool calls, streaming, and unknown-field handling; return an explicit unsupported-feature error instead of forwarding a schema the endpoint rejects. Full disclosure: I’m building Your Model, an OpenAI-compatible multi-provider API; if a second endpoint would help reproduce the matrix, I’m happy to provide test credits.
github-actions commentedon Oct 22, 2026
This issue has been marked as stale because it has had no activity for 60 days. It will be closed in 7 days unless there is new activity. If this still affects you, please comment with the latest app version, whether the problem is still reproducible, and any updated details.
github-actions commentedon Oct 30, 2026
This issue has been automatically closed after 7 additional days without activity since being marked stale. If this still affects you, please provide updated details and ask a maintainer to reopen it.