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.github.com/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.github.com/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 · ◷