✴️
Copilot CLI の reasoning effort xhighが使えない時に試した手順メモ

2026/04/20に公開
※メモです
GitHub Copilot CLI の旧バージョンで挙動を検証したい場面では、単に VERSION="v1.0.24" を付けて再インストールするだけでは不十分なことがあります。インストール直後は目的のバージョンでも、その後の更新や起動経路の違いによって、想定より新しい版が起動してしまう場合があるからです。そこで本記事では、GitHub Copilot CLI を 1.0.24 に再インストールし、自動更新を抑止しつつ、起動時に版を検査して 1.0.24 だけを確実に使うところまでを、再現しやすい手順としてまとめます。この記事の手順は、少なくとも筆者の環境では 1.0.24 で期待どおりに動作しました。

 前提対象環境は macOS と zsh を想定しています。Copilot CLI はユーザー権限で ~/.local/bin/copilot に配置し、設定ファイルは ~/.copilot/config.json を利用します。既存設定を壊したくないため、作業前に設定ファイルを退避し、更新キャッシュを削除してから再インストールします。こうしておくと、「本当に 1.0.24 を入れ直したのか」「後から何かに上書きされたのではないか」を切り分けやすくなります。

 まずやること最初に、現在の設定を退避し、Copilot CLI の更新キャッシュを消してから 1.0.24 を再インストールします。ここでは、既存の copilot バイナリを削除したうえで、VERSION="v1.0.24" を付けてインストーラスクリプトを実行します。最後に、絶対パスで --version を実行して、狙ったバージョンが入っていることをその場で確認します。
set -euo pipefail

# 1) 設定退避
TS="$(date +%Y%m%d-%H%M%S)"
mkdir -p "$HOME/.copilot-backup/$TS"
[ -f "$HOME/.copilot/config.json" ] && cp "$HOME/.copilot/config.json" "$HOME/.copilot-backup/$TS/config.json"

# 2) 更新キャッシュを削除
rm -rf "$HOME/Library/Caches/copilot"

# 3) 既存 binary を削除
rm -f "$HOME/.local/bin/copilot"

# 4) v1.0.24 を再インストール
curl -fsSL https://gh.io/copilot-install | VERSION="v1.0.24" PREFIX="$HOME/.local" bash

# 5) シェルのコマンドキャッシュを破棄し、確認
hash -r 2>/dev/null || true
command -v copilot
COPILOT_AUTO_UPDATE=false "$HOME/.local/bin/copilot" --version
ここで GitHub Copilot CLI 1.0.24. と表示されれば、再インストール自体は成功しています。ただし、この時点ではまだ「今後も 1.0.24 のまま起動される」とは限りません。次に、自動更新を止め、起動時に版を検査するラッパー関数を用意します。

 設定ファイルで自動更新を止めるCopilot CLI の設定キーは、環境やバージョンによって camelCase と snake_case が混在することがあります。そのため、更新停止については autoUpdate と auto_update の両方を入れておく方が無難です。加えて、推論強度に関する設定も将来の挙動差分に備えて両系統をそろえておくと、検証時の再現性が上がります。
既存の config.json を使っている場合は、次のような内容にしておくと扱いやすいです。
{
  "model": "gpt-5.4",
  "effortLevel": "xhigh",
  "reasoning_effort": "xhigh",
  "banner": "never",
  "autoUpdate": false,
  "auto_update": false,
  ...
}
この設定だけでも更新が抑止される可能性はありますが、検証目的で確実性を上げたいなら、起動時にも環境変数で更新停止を明示した方が安全です。そこで、次のラッパー関数を使います。

 1.0.24 専用の起動関数を作るここでは copilot124 という関数を作ります。この関数は、まず ~/.local/bin/copilot を直接参照し、その --version 出力からバージョン番号だけを抜き出します。版が 1.0.24 でなければ起動を拒否し、合っていれば COPILOT_AUTO_UPDATE=false を付けて実行します。これにより、想定外の更新や別バージョンへのすり替わりにすぐ気づけます。
cat >> "$HOME/.zshrc" <<'EOF'

export COPILOT_AUTO_UPDATE=false

copilot124() {
  local bin="$HOME/.local/bin/copilot"
  local ver

  if [ ! -x "$bin" ]; then
    echo "copilot binary not found at $bin" >&2
    return 1
  fi

  ver="$("$bin" --version 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"

  if [ "$ver" != "1.0.24" ]; then
    echo "Refusing to start: expected 1.0.24, got ${ver:-unknown}" >&2
    echo "Reinstall with the pinned installer before continuing." >&2
    return 1
  fi

  COPILOT_AUTO_UPDATE=false "$bin" "$@"
}
EOF

exec zsh -l

# 動作確認
type copilot124
copilot124 --version
この構成の利点は、copilot コマンドの通常起動に依存しないことです。絶対パスのバイナリを直接叩くため、PATH 上の別の copilot を誤って踏む可能性を減らせます。さらに、版が一致しないときは即座に止まるので、「いつのまにか新しい版を使っていた」という事故も防げます。

 普段の使い方以後は、通常の copilot ではなく copilot124 を使います。たとえば、プロジェクトディレクトリでそのまま次のように起動します。
cd ~/path/to/project
copilot124
もし引数を付けて使いたい場合も、そのまま透過的に渡せます。たとえば、バージョン確認だけなら次で十分です。
copilot124 --version
この運用にしておけば、1.0.24 を使う理由が「検証の再現性」である場合でも、毎回の確認コストを小さく保てます。版固定、更新停止、起動前検査の三段構えになっているため、検証環境としてはかなり安定します。

 うまくいかないときの確認ポイントこの手順で動かない場合は、まず ~/.local/bin/copilot --version を直接実行して、本当に 1.0.24 が入っているかを確認します。ここが 1.0.24 でなければ、再インストールの前後で上書きが起きています。次に command -v copilot や which -a copilot を見て、PATH 上に別の copilot がいないかを確認します。最後に ~/.copilot/config.json で autoUpdate と auto_update がどちらも false になっているかを見ます。
また、--version の出力は複数行になることがあります。そのため、ラッパー関数の版判定では、単純な全文比較ではなく、正規表現で x.y.z を抜き出すようにしています。ここを雑に書くと、見た目は 1.0.24 でも比較に失敗し、誤って起動拒否になることがあります。

 まとめCopilot CLI を 1.0.24 に固定して使いたい場合は、特定版の再インストール、自動更新の抑止、起動時の版チェックの三つをそろえると安定します。単に旧バージョンを入れるだけでは、後続の更新や起動経路の違いで再現性が崩れやすいからです。逆に、この三点を押さえておけば、特定バージョンでしか起きない不具合の検証や、UI 差分の切り分けがかなりやりやすくなります。旧バージョン検証を継続するなら、通常の copilot ではなく、専用ラッパー経由の起動を日常運用にするのが安全です。
前提

まずやること

設定ファイルで自動更新を止める

1.0.24 専用の起動関数を作る

普段の使い方

うまくいかないときの確認ポイント

まとめ

Discussion
