CopilotClient fails with "No GitHub OAuth token or Copilot HMAC key provided" on Linux only, with a valid gitHubToken set

Start with the SDK source that sets COPILOT_SDK_AUTH_TOKEN and passes --auth-token-env, then reproduce the failure with the Linux native runtime in the node:22-slim environment. Inspect the runtime.node credential and authentication path, including the mentioned keyring/D-Bus behavior. Done means identifying the Linux-specific cause and documenting or testing a supported fix for models.list() and session calls.

CopilotClient (Node.js SDK, @github/copilot-sdk v1.0.13) fails every model-inference call (models.list(), and any session chat/sendAndWait) with:

Plain text

Execution failed: InvalidArg, No GitHub OAuth token or Copilot HMAC key provided

or, for models.list() specifically:

Plain text

Request models.list failed with message: Not authenticated. Please authenticate first.

...even though a valid gitHubToken is explicitly passed to the CopilotClient constructor. The exact same application code, same GitHub account, same token works correctly when run locally on Windows, and fails 100% of the time on Linux (Kubernetes/EKS). No BYOK or sub-agent/task tool is involved — this is the top-level session's very first call.

Environment

• SDK: @github/copilot-sdk v1.0.13 (latest at time of filing), native runtime (stdio transport, not in-process/FFI)

• Failing environment: Kubernetes (EKS) pod, node:22-slim (Debian) base image, Node 22

• Working environment: local Windows 11, same Node version, same code

• GitHub host tested: both github.com (default) and a GitHub Enterprise Cloud with Data Residency tenant (*.ghe.com) — identical error on both, so it is host-independent

Client construction (simplified)

TypeScript

const client = new CopilotClient({
  mode: 'empty',
  gitHubToken: accessToken, // valid gho_ OAuth App token, confirmed non-empty at this point
  logLevel: 'debug',
});
await client.start();
const models = await client.models.list(); // fails here, ~15-30ms after session start

What we've ruled out

• Token type: reproduced identically with both a ghu_ (GitHub App user-to-server) token and a gho_ (OAuth App) token.

• useLoggedInUser: confirmed via SDK source it already defaults to false whenever gitHubToken is set.

• Ambient/cached credentials: no OS credential manager entries involved on Linux; removing all cached Windows Credential Manager entries didn't change Windows (still works).

• Env var pollution: added diagnostics dumping every GH_*/GITHUB_*/COPILOT_* key present in process.env — nothing unexpected present.

• Network/firewall: confirmed the pod can reach both api.<host> and copilot-api.<host> (real HTTP responses, not connection errors).

• GH_HOST/GH_TOKEN/GH_ENTERPRISE_TOKEN: removed all three entirely (falling back to the default github.com host with only the explicit gitHubToken) — identical error, ruling out host-scoped env vars as the cause.

• InProcessRuntimeConnection: not applicable/not in use; confirmed via docs it doesn't honor per-client gitHubToken anyway, so not a viable workaround.

• Missing libsecret/D-Bus Secret Service: confirmed absent from the node:22-slim container (ldconfig -p/dpkg -l show nothing). Extracted strings from the Linux runtime.node binary show a keyring_core + D-Bus Secret Service credential backend, but also a "...continuing without credential" string suggesting graceful degradation is intended — inconclusive, but worth noting as a possible contributing factor since we already set COPILOT_DISABLE_KEYTAR=1 via mode: 'empty'.

Confirmed facts

• Diagnostic logging confirms the token reaches CopilotClient non-empty and correctly shaped at construction time.

• Per SDK source, this sets COPILOT_SDK_AUTH_TOKEN in the runtime env and passes --auth-token-env COPILOT_SDK_AUTH_TOKEN to the spawned CLI process — confirmed happening correctly at the JS layer on both platforms.

• Failure happens within ~15-30ms of session start, immediately followed by session error/shutdown — before any model call actually executes.

Possibly related

This may share a root cause with #559 / #557 ("Built-in task tool fails with 'No GitHub OAuth token' in BYOK/Azure AI Foundry deployments"), where a community deobfuscation traced the same exact error string to a CopilotApiClient/sweagent-capi construction path that gets created without either credential under certain conditions. Our case differs (no BYOK, no sub-agent involved, fails on the very first top-level call) but the error text and general "client constructed without a resolved credential" shape look related.

Ask

• Is gitHubToken/--auth-token-env a tested/supported path on the Linux native runtime specifically?

• Any known Linux-only regression or required container dependency (e.g. libsecret/D-Bus) for this auth path?

• Any way to get more diagnostic output from the native runtime for this failure — it's nearly silent on stderr even with logLevel: 'debug'.