Copilot CLI (newer versions) does not run on Windows 11 – exits immediately

[VujaNS]

Describe the bug

I’m unable to run newer versions of GitHub Copilot CLI on Windows. The CLI installs successfully, but running any copilot command results in no output and immediate exit.

• Newer Copilot CLI versions 0.0.368 exit immediately with no output and no error
• Only version 0.0.367 works on this machine

Question

Are there any additional diagnostics/logging I can enable to help identify why newer versions exit silently?

Thanks in advance for any guidance.

Affected version

0.0.368 and any newer version

Steps to reproduce the behavior

1. Installed Copilot CLI using:

   winget install GitHub.Copilot

2. Restarted PowerShell.

3. Tried running:

   copilot --version
   copilot --banner
   copilot

   → No output at all

4. Tried launching copilot.exe directly:

   • PowerShell window opens briefly and closes immediately.

5. Downloaded and tested copilot.exe v0.0.367:

   • This version works correctly.

6. Troubleshooting already attempted:
   • Cleared npm cache
   • Allowed Copilot CLI through firewall (public + private)
   • Verified Node, npm, and PowerShell versions
   • Reinstalled Copilot CLI multiple times

Expected behavior

copilot commands should run normally and display output (version, banner, interactive prompt, etc.).

Additional context

OS: Windows 11
Node.js: 24.13.0
npm: 11.6.2
PowerShell: 7
Subscription: Copilot Pro

I don't have any logs because it exited immediately with no output and no logs generated.

[knilecrack]

I have same issue, it's not starting whether I install it using npm or winget... no error visible..Where can I find logs?

[vasicvuk]

Having the same issue

[knilecrack]

hmm I was able to fix this are you guys using fnm or something for managing node versions? and it looks like it needs node >= 24

After I found where npm-loader.js is I got it to display this message:

Critical Failure loading Copilot JS engine: Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'
    at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:195:11)
    at defaultLoadSync (node:internal/modules/esm/load:142:3)
    at #loadAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:790:12)
    at #loadSync (node:internal/modules/esm/loader:810:49)
    at ModuleLoader.load (node:internal/modules/esm/loader:775:26)
    at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:520:31)
    at #getOrCreateModuleJobAfterResolve (node:internal/modules/esm/loader:571:36)
    at afterResolve (node:internal/modules/esm/loader:619:52)
    at ModuleLoader.getOrCreateModuleJob (node:internal/modules/esm/loader:625:12)
    at onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:644:32) {
  code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
}

then some AI suggested I do this to npm-loader.js:

#!/usr/bin/env node
import { spawnSync } from "node:child_process";
import { fileURLToPath, pathToFileURL } from "node:url";
import { dirname, join } from "node:path";

async function run() {
  const currentDir = dirname(fileURLToPath(import.meta.url));

  // 1. Try the native binary first (The original behavior)
  try {
    const binPath = fileURLToPath(import.meta.resolve(`@github/copilot-${process.platform}-${process.arch}`));
    const result = spawnSync(binPath, process.argv.slice(2), { stdio: "inherit" });
    if (result.status === 0) process.exit(0);
    // If it returns a non-zero status (like your Exit Code 1), we continue to JS fallback
  } catch (e) {
    // Native binary failed/missing, ignore and move to JS
  }

  // 2. JS Fallback (The fix that works for you)
  try {
    const entryPoint = join(currentDir, "index.js");
    const entryPointURL = pathToFileURL(entryPoint).href;
    await import(entryPointURL);
  } catch (err) {
    console.error("GitHub Copilot CLI failed to load:", err);
    process.exit(1);
  }
}

run();

[nicholasdehnen]

I ran into this issue today using version 0.0.415. Got absolutely no output even with --log-level debug, so I ended up attaching a debugger using copilot --node-options="--inspect-brk", and I think I found the reason for the silent error/exit.

Whenever copilot runs into an uncaught exception (in my case the API returning HTTP 401):

1. The SEA module loader logs the error via console.write(), followed by process.exit(1).
2. console.error has been monkey patched in Uro (index.js:3577:2630) to use a Ie, an instance of logger XAt (index.js:165:8690).
3. Ie.logToLevel() calls this.logWriter.writeLog(...), which appends to an async write queue and returns a queue.flush() promise. This promise is stored in Ie.writePromise.
4. The promise in Ie.writePromise is never awaited, so the log message gets lost when process.exit(1) fires.

The result is a silent exit with error level 1 and no log file 🙃

Curiously, when setting COPILOT_AGENT_DEBUG=1, a log file is created at %USERPROFILE%\.copilot\logs\process-*.log, but it only contains messages that were written early enough to compete with the exit. I assume the --log-level flag has no effect because the logger is instantiated at module load time, before CLI arg parsing runs. A fix would be to properly catch exceptions, handle rejections, and/or await Ie.flush before exiting. One way to reproduce this issue is authorizing copilot-cli via copilot login and revoking access in the settings immediately afterwards, or modifying the config file to have invalid syntax.

For anyone else having this issue, try the following script:

const fs = require('fs');

const serialize = (a) => {
  if (a instanceof Error) return `${a.name}: ${a.message}\n${a.stack}`;
  if (typeof a === 'object' && a !== null) return JSON.stringify(a, Object.getOwnPropertyNames(a), 2);
  return String(a);
};

const log = (...args) => fs.writeSync(2, args.map(serialize).join(' ') + '\n');

let _consoleError = log;
Object.defineProperty(console, 'error', {
  get: () => _consoleError,
  set: (fn) => { _consoleError = (...args) => { log(...args); try { fn(...args); } catch(_) {} }; },
  configurable: false
});

Save as hook.js, then run copilot with arguments (adjust file path if needed):

copilot --node-options="--require ./hook.js"

The hook intercepts the monkey-patch that swallows the console.error message and writes any error directly to stderr. Hopefully that error will be helpful in fixing whatever issue you have.

[knilecrack]

tl;dr: No output due to broken logging; in my case running copilot login and authorizing copilot CLI once again fixed the underlying issue.

If that doesn't fix the issue..

I tried just it just now, and it did not work for me
Whenever there is an update I have to do this:
where.exe copilot
cd to_first_found_path
then I go to ..\@github\ folder for example:

C:\Users\my_user\AppData\Local\fnm_multishells\25864_1772052678683\node_modules@github\copilot

and replace npm-loader.js with above mentioned solution

[nicholasdehnen]

tl;dr: No output due to broken logging; in my case running copilot login and authorizing copilot CLI once again fixed the underlying issue.
If that doesn't fix the issue..

I tried just it just now, and it did not work for me Whenever there is an update I have to do this: where.exe copilot cd to_first_found_path then I go to @github folder for example:

C:\Users\my_user\AppData\Local\fnm_multishells\25864_1772052678683\node_modules@github\copilot

and replace npm-loader.js with above mentioned solution

Good point, I realized later on that there's a variety of errors which can lead to a silent exit/crash, see for example #1250 and #1271, so my provided solution wasn't universal - I updated my original comment. Did you try launching it with the hook.js script attached? Maybe that way you can see what the actual error on your system is. I saw ERR_UNSUPPORTED_ESM_URL_SCHEME a lot during debugging, but it never caused any crashes for me.

Note that your approach doesn't work for winget installations, in which case you only have a single copilot.exe:

C:\Users\User>where copilot
C:\Users\User\AppData\Local\Microsoft\WinGet\Packages\GitHub.Copilot_Microsoft.Winget.Source_8wekyb3d8bbwe\copilot.exe

C:\Users\User>dir /s C:\Users\User\AppData\Local\Microsoft\WinGet\Packages\GitHub.Copilot_Microsoft.Winget.Source_8wekyb3d8bbwe\
 Volume in drive C has no label.
 Volume Serial Number is 362F-5AFC

 Directory of C:\Users\User\AppData\Local\Microsoft\WinGet\Packages\GitHub.Copilot_Microsoft.Winget.Source_8wekyb3d8bbwe

2026-02-23  10:45 PM    <DIR>          .
2026-02-23  08:27 PM    <DIR>          ..
2026-02-21  12:21 AM       110,542,296 copilot.exe
               1 File(s)    110,542,296 bytes

     Total Files Listed:
               1 File(s)    110,542,296 bytes
               2 Dir(s)  803,385,966,592 bytes free

[knilecrack]

I get this error when running with hook:
Failed to load package index: C:\Users\User\.copilot\pkg\win32-x64\0.0.420\index.js Error: X509 to PEM conversion Error: X509 to PEM conversion at cacheSystemCACertificates (node:tls:138:41) at Module.getCACertificates (node:tls:193:14) at Efo (file:///C:/Users/User/.copilot/pkg/win32-x64/0.0.420/index.js:165:10584) at Nyn (file:///C:/Users/User/.copilot/pkg/win32-x64/0.0.420/index.js:165:9917) at Wyn (file:///C:/Users/User/.copilot/pkg/win32-x64/0.0.420/index.js:3739:3023) at file:///C:/Users/User/.copilot/pkg/win32-x64/0.0.420/index.js:4578:1892

If copilot is installed using winget - my solution would require to edit npm-loader in $HOME.copilot\pkg\win32-x64\0.0.420 (or whatever is the version) then you would need to use custom npm-loader and run it with node npm-loader.js which is...ugly

[ReFlo]

I had a similar issue: Seems like copilot don't like it if you have in your https_proxy settings two links. The fix i had was changing from:

http://localhost:/;http://127.0.0.1:

to:

http://localhost:/

[zhfrn-zzz]

I am experiencing the same issue. When I execute the Copilot command in PowerShell/Terminal, it doesn't output anything. However, I found a workaround that might be worth trying.

Root Cause
The Copilot CLI hardcodes the execution to use pwsh.exe. However, Windows 11 by default only comes with PowerShell 5.1 (powershell.exe) and does not include PowerShell 7+ (pwsh.exe).

Solutions

Method 1: Install PowerShell 7 (I use this method)

You can easily install PowerShell version 7 using winget:

PowerShell
winget install Microsoft.PowerShell

Method 2: Patch the index.js file

Alternatively, you can patch the Copilot file directly by replacing all instances of pwsh.exe with powershell.exe. There are 6 places that need to be replaced.

Open this file:
%USERPROFILE%.copilot\pkg\universal{version}\index.js

Find & Replace all:
pwsh.exe → powershell.exe
The CLI runs perfectly after being patched, there seems to be no functional dependency on PowerShell 6+.

Note: This patch needs to be reapplied after every update (e.g., after running winget upgrade GitHub.Copilot).

Method 3: WSL

The last resort you can use when there are no other options is to use Copilot within WSL. You can install it with

npm install -g @github/copilot.

[Nezzquikk]

still doesnt work for me, if I enter claude in powershell 7, cmd, git bash or elsewhere it doesnt do anything, no output. Installed with all ways already but no results. Even cleared AppData folders of .copilot but it won't let me start it