Github copilot gives error "authorisation header is badly formatted" when using from docker sbx

[pkimtani]

Based on the slack message I posted here
I am hitting an issue with the copilot authentication.

Instead of using the --sandbox from docker-agent, I am approaching this other way around, and running my sbx with docker-agent.

Reason: I couldn't find any documentation about how to pass --template or --kit or both to --sandbox from docker-agent context, but using sbx with docker-agent was quite straightforward and easy to setup + I can reuse it between docker-agent and copilot quite flexibly. 😅

Now, when I try to make any calls to my copilot model, I hit error: "..... Authorization header is badly formatted".

To get it to work, I have to setup GITHUB_COPILOT=gho_xxxxxxx in a my.env file and passed it as runtime using --env-from-file , but it kind of beats the purpose of using sbx because I would like the sbx to not store any secrets, instead be proxy-managed.

I tried to explicity set GITHUB_TOKEN as part of my proxyManagedconfig in the kit, but then I get error: credential for service "github" defined in both docker-agent and my-project-sandbox. And it makes total sense.

This works out of the box with copilot agent in sbx.

Any tips or advice on how I can solve this?

[pkimtani]

Interesting, out of the blue GITHUB_TOKEN=proxy-managed started to work 🤔
Now I am confused if this is a sbx issue after all because sbx copilot CLI started giving me error "Authorization header is badly formatted´ and I had to remove and recreate the sandbox.
Is there any way I can grab some logs or dig deep?

Sorry, I am still quite new to docker sbx and docker-agents 😅

[pkimtani]

I'll mark this as closed for now. I will try to dig more and see if I can grab any logs about it. I'm a bit sus about the zscaler proxy that my project is using. Some users in my project have reported issues with using copilot on zscaler.
Thanks anyways!

[pkimtani]

Ok this error has started to appear again. I did some config changes to find the problem but failed to pin-point.

Setting GITHUB_TOKEN as proxy-managed env gives error: ERROR: request failed: 400 Bad Request: kit_artifacts: compose: compose: credential for service "github" defined in both "docker-agent" and "my-project-sbx".

Wondering if it would make it easier if docker-agent could support CoPilot provider without GITHUB_TOKEN env, like similar to how claude oAuth works or just utilise the secrets from sbx secret ...?

[yunus25jmi1]

The most-supported hypothesis is that the sandbox's proxy-managed github
credential injects the real token for api.github.com but not
api.githubcopilot.com, so docker-agent sends the un-substituted sentinel to
the Copilot API and GitHub rejects it as "badly formatted".

This is not yet confirmed. It could explain the primary failure and the
real-token workaround (a real token via --env-from-file involves no sentinel).
The Copilot CLI behavior and the flip-on-recreation reports are plausibly
related but remain unverified.

To settle it, we need the effective composed kit for an affected sandbox.
Two open questions for maintainers:

• What is the supported command to inspect an active sandbox's effective
  composed kit (not a static kit reference)?
• Which source repository owns the template layer that declares the github
  credential service?

From that kit dump, the things to confirm (please share destinations only —
never token values):

1. Which service owns GITHUB_TOKEN.
2. That credential's source.
3. Whether api.githubcopilot.com is among its inject destinations.
4. Whether service composition permits extending an existing credential's
   inject rules (redeclaring github fails with a duplicate-service error, so
   widening the existing one is likely the only viable path).

If api.githubcopilot.com is absent, the likely fix is a one-line
inject-domain addition in the template layer that owns the github service:

inject:
  - domain: api.githubcopilot.com
    header: Authorization
    format: "Bearer %s"

with exact-host matching (no wildcard subdomains), preserving existing
github.com / api.github.com injection and Git HTTPS auth, and keeping a
single authoritative github service. Old sandboxes may need recreation to pick
up the new rule.

If the domain is present, this hypothesis is wrong and the investigation
should move to proxy lifecycle / recreation state and the reporter's network
environment before any template change.

Note on topology: docker-agent's own --sandbox launch path runs on the host
and refuses to nest inside an existing sandbox, so a change there would not
address this setup (docker-agent running inside a user-created sandbox). The
likely fix belongs to the credential-owning template layer, pending the kit
dump.

Out of scope for this bug: Copilot token exchange (GitHub token -> session
token) and OAuth device flow -- both are separate enhancements.

---

cc @pkimtani — you're the only person who can capture the kit dump above; the two "share destinations only, never token values" checks are the unblock here.

cc @dgageot / @docker/ai-agent-team — for routing to the sandbox/template owners and the supported command to inspect an active sandbox's effective composed kit (labels already cover it: area/gateway, area/providers, area/security).

[Sayt-0]

@pkimtani @yunus25jmi1 this will be updated in the next release of sbx. The fix has just been merged

[yunus25jmi1]

Thanks @Sayt-0. Could you link the merged sbx PR and the target release/version so @pkimtani can confirm once it's out? Happy to help verify.

[Sayt-0]

The sbx source repository is private so the PR cannot be linked publicly; the fix will land in the next release after v0.37.0 (https://github.com/docker/sbx-releases/releases), and existing sandboxes need to be recreated after upgrading to pick it up.