Shell completions are reinstalled on every launch, including headless `--server` sessions where `copilot` is not on PATH

[douglaswth]

Describe the bug

The CLI installs shell completions on every startup, in every mode — including headless --server / stdio sessions launched by an editor extension, where the copilot binary is not on the user's PATH and never will be.

changelog.json for 1.0.41 says:

Shell completions (bash, zsh, fish) are automatically installed on first run and updated after copilot update

Two things don't match that description:

1. It runs on every launch, not on first run. All 8 log files in ~/.copilot/logs/ on this machine — spanning 2026-08-21 to 2026-08-28 — contain exactly one such line each:

2026-08-28T20:14:54.444Z [INFO] Starting CLI in server mode (stdio)
2026-08-28T20:14:54.445Z [INFO] Starting CLI in stdio mode (Rust JSON-RPC engine)
2026-08-28T20:14:54.463Z [INFO] CLI server ready (stdio mode, Rust JSON-RPC engine)
2026-08-28T20:14:54.448Z [INFO] Server started, waiting for requests
2026-08-28T20:14:54.463Z [INFO] Shell completions: installed bash completions to $HOME/.local/share/bash-completion/completions/copilot

The file is rewritten unconditionally each time — no first-run marker, no comparison against existing content.

2. It fires for a copilot that isn't on PATH. The CLI that wrote the file is the copy bundled inside VS Code:

$HOME/.vscode-server/bin/<commit>/node_modules/@github/copilot-linux-x64/   (1.0.81-0)
$HOME/.vscode-server/bin/<commit>/extensions/copilot/node_modules/@github/copilot   (1.0.73)

I have never installed the CLI myself. command -v copilot is empty in my login shell. The installed bash completion is therefore dead weight — it registers complete -F _copilot copilot for a command the shell cannot run.

Looking at app.js in the platform package, the only guard on the installer is a dev-build check:

function ag(){ return process.env.COPILOT_CLI_VERSION || "1.0.81-0" }
// bO="0.0.1"
function BOn(t){
  if (ag()===bO && !process.env.COPILOT_CLI_VERSION) return {dispose:()=>{}};
  let e = cOi(t);
  return {dispose: async()=>await e};
}

bO is the 0.0.1 placeholder version, so this only skips for unversioned local builds. In any released build the installer always runs. It is registered in the shared startup path next to the auto-updater and before the --server/--headless argument validation:

Ge.add(hxt(ke,k,t.autoUpdate,be,Le,re),"autoUpdate"), Ge.add(BOn(()=>k_),"shellCompletions")

so interactive TUI, --server and --headless are all treated identically. I could not find any flag, env var, or config key that disables it.

Affected version

1.0.81-0 (bundled in VS Code; behavior introduced in 1.0.41). Also present in the 1.0.73 copy shipped in the copilot extension.

Steps to reproduce the behavior

1. On Linux, ensure copilot is not on PATH and ~/.local/share/bash-completion/completions/ exists and is writable.
2. Open VS Code with the GitHub Copilot Chat extension and start a Copilot session, so the extension launches its bundled CLI in stdio server mode. (Equivalently: run any released copilot build with --server.)
3. ls -l ~/.local/share/bash-completion/completions/copilot — the file now exists.
4. Repeat step 2; the file's mtime advances every time, and each run logs another Shell completions: installed ... line in ~/.copilot/logs/.

Expected behavior

Any one of these would resolve it:

• Skip the install when the running executable is not resolvable as copilot on the user's PATH — the completion is unusable in that case.
• Skip the install in non-interactive modes (--server, --headless, stdio), which no human is typing into.
• Honor the changelog's own wording and install on first run only, rather than rewriting on every launch.
• Provide an opt-out (a config key or COPILOT_NO_SHELL_COMPLETIONS=1), so users who manage their dotfiles in version control can decline.

Additional context

The practical annoyance is that a version-controlled home directory shows an untracked 71 KB file appearing on its own, written by a process the user did not start, for a command the user cannot run.

The CLI command reference still documents completions as something the user installs manually (copilot completion SHELL piped to a file), with no mention of automatic installation — worth aligning once the behavior is settled.