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

`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.` and `copilot-api.` (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'`.

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.

Written by the indexing model from the issue text.