AIコーディングCLIのバージョン確認・更新・ログイン確認コマンドまとめ
Linux系環境で複数のAIコーディング支援CLIを使っていると、困るのは「どのツールが何版で、ログイン済みで、どのモデル設定で動いているのか」が分からなくなることです。
結論から言うと、まず見るべき場所は4つです。バージョン、更新方法、ログイン状態、デフォルトモデル設定を切り分けて確認します。npmで入れたCLIの更新時に EACCES: permission denied が出る場合は、CLI本体の不具合ではなく、npmのグローバルインストール先に対するLinux側の権限問題である可能性が高いです。
この記事では、個別ツール名に依存しすぎない形で、AIコーディングCLIを管理するときの基本コマンドと、npm install -g で権限エラーが出たときの見方を整理します。
- 対象環境: Linux系環境、Raspberry Piなどの小型Linux端末、個人開発環境
- 対象ツール: npmでグローバルインストールしたCLIツール全般
- 主な論点: バージョン確認、更新、ログイン確認、モデル設定確認、EACCES対策
AIコーディングCLIの管理で確認すべき4項目
複数のCLIツールを同じ環境で使う場合、トラブル時に見る項目を固定しておくと切り分けが早くなります。
確認したいのは、主に次の4つです。
- バージョン: 実行されているCLIが何版か
- 更新方法: npm更新か、ツール専用コマンドか
- ログイン状態: 認証済みか、別アカウントになっていないか
- デフォルトモデル: 設定ファイルや環境変数で何が指定されているか
特にAIコーディング支援CLIでは、ログイン状態やモデル指定が動作結果に直結します。同じコマンドを打っているつもりでも、別のパスにある古いCLIを実行していたり、環境変数でモデルが上書きされていたりすると、挙動が変わります。
ここがポイント: CLIの不調に見える現象でも、実際には「古いバージョンを実行している」「未ログイン」「npmの権限不足」「モデル設定の見落とし」が原因のことがあります。
バージョン確認は -V と --version を押さえる
まずは、実行しているCLIのバージョンを確認します。多くのCLIでは、次のどちらかが使われます。
command-name -V
command-name --version
command-name は、実際に使っているCLIコマンド名に置き換えます。
両方に対応しているツールもありますが、片方だけの場合もあります。バージョン表示が出ない場合は、ヘルプを確認します。
command-name --help
実行パスも確認する
バージョンだけでなく、どの実行ファイルが呼ばれているかも確認します。
which command-name
which コマンド名 で、シェルが実行するCLIコマンドのパスを確認できます。npmのグローバルインストール先、Node.jsのバージョンマネージャー、OS標準パッケージなどが混在している環境では、この確認が重要です。
たとえば、想定と違う場所のCLIが呼ばれている場合、更新したつもりのパッケージとは別の古い実行ファイルを使っている可能性があります。
npmで最新版にアップデートする基本コマンド
npmでグローバルインストールしたCLIツールは、一般に次の形式で更新できます。
npm install -g package-name@latest
package-name はnpm上のパッケージ名に置き換えます。CLIコマンド名とnpmパッケージ名が一致しない場合もあるため、そこは各ツールの公式ドキュメントで確認します。
npm上の最新版を確認する
更新前に、npmレジストリ上の最新版を確認するには次のコマンドを使います。
npm view package-name version
現在グローバルに入っているバージョンは、次で確認できます。
npm list -g package-name --depth=0
更新前後でこの2つを見比べると、実際に更新されたかを確認しやすくなります。
ツール専用の更新コマンドがある場合
CLIツールによっては、npmではなくツール側に更新コマンドが用意されている場合があります。
たとえば、次のような形です。
command-name update
command-name upgrade
ただし、更新コマンドの有無や名前はツールごとに異なります。npmで入れたものをnpmで更新するのか、ツール専用コマンドを使うのかは、公式ドキュメントで確認するのが安全です。
ログイン状態は専用コマンドで確認する
AIコーディングCLIは、APIキー、OAuth、ブラウザ認証など、ツールごとに認証方式が異なります。そのため、ログイン確認コマンドも統一されていません。
よくある確認の形は次のようなものです。
command-name auth status
command-name login status
command-name whoami
実際のコマンド名は、利用しているCLIのヘルプや公式ドキュメントで確認します。
テキスト形式とJSON形式の違い
ログイン状態の表示には、人間が読むためのテキスト形式と、スクリプトで扱いやすいJSON形式が用意されている場合があります。
command-name auth status
command-name auth status --json
JSON形式がある場合、CIや定期確認スクリプトでは便利です。一方、手元で軽く確認するだけなら通常のテキスト表示で十分です。
認証情報を扱うコマンドの出力には、アカウント名やメールアドレス、トークンに近い情報が含まれることがあります。ブログ、Issue、チャットへ貼る前に、個人情報や秘密情報が含まれていないか確認します。
デフォルトモデルは設定ファイルと環境変数を確認する
AI CLIでは、モデル指定が動作や料金、応答品質に影響します。ただし、デフォルトモデルの確認は単一コマンドだけで完結しない場合があります。
主に見る場所は次の3つです。
- ユーザー設定ファイル
- 環境変数
- コマンド実行時の一時指定
設定ファイルを見る
CLIツールによって、設定ファイルの場所は異なります。一般には、ホームディレクトリ配下の設定ディレクトリや、ツール専用ディレクトリに保存されます。
例としては、次のような場所が候補になります。
ls ~/.config
ls ~
設定ファイルにデフォルトモデルが明示されていない場合でも、モデルが使われていないという意味ではありません。ツール側の標準設定が使われる可能性があります。
環境変数で上書きされていないか見る
環境変数でモデルや設定ファイルの場所が上書きされるCLIもあります。まずは、関係しそうな環境変数を確認します。
env | grep -i model
env | grep -i api
APIキーやトークンが表示される可能性があるため、出力を共有するときは必ず伏せます。
実行時だけモデルを指定する
一時的にモデルを切り替えたい場合、CLIによってはコマンド実行時のオプションで指定できます。
command-name --model model-name
この形式はツールごとに異なります。モデル名や指定方法はバージョンで変わる可能性があるため、実際に使う前に対象CLIの公式情報で確認します。
npmのEACCESエラーは何を意味するのか
npm install -g package-name@latest を実行したときに、次のようなエラーが出ることがあります。
EACCES: permission denied
errno -13 や code EACCES は、権限不足を示す代表的なエラーです。Linux環境では、通常ユーザーがシステム領域へ書き込めないために発生します。
npmのグローバルインストール先が、環境によっては次のような場所になることがあります。
/usr/local/lib/node_modules
この配下はシステム領域として扱われることがあり、通常ユーザーには書き込み権限がない場合があります。その状態でグローバルパッケージを更新しようとすると、npmがファイルやディレクトリを作成、削除、リネームできずに失敗します。
permission denied, rename が出る理由
エラーメッセージに syscall rename が含まれる場合、npmが既存のパッケージディレクトリを一時ディレクトリへリネームしようとして失敗している可能性があります。
更新時には、単に新しいファイルを追加するだけではありません。既存のパッケージを退避したり、置き換えたりする処理が発生します。その途中で、対象ディレクトリの所有者や権限が通常ユーザーに合っていないと、permission denied になります。
この場合、原因として考えやすいのは次のような状態です。
- npmのグローバル保存先が
/usr/local配下などのシステム領域になっている - 過去に
sudo npm install -g ...で入れたパッケージを通常ユーザーで更新しようとしている - Node.js/npmの導入方法により、グローバルパッケージの保存先がroot権限前提になっている
つまり、AI CLI本体のバグというより、npmのグローバルパッケージ管理とLinuxのファイル権限の問題として切り分けるのが自然です。
/usr/local/lib/node_modules に書き込めないと更新に失敗する
npmのグローバルインストール先は、次のコマンドで確認できます。
npm config get prefix
この結果が /usr/local のようなシステム領域を指している場合、グローバルパッケージはその配下に置かれます。典型的には、次のような場所です。
/usr/local/lib/node_modules
通常ユーザーに書き込み権限がない場合、npm install -g は失敗します。
更新対象のCLIがどこから実行されているかも確認します。
which command-name
出力されたパスが /usr/local/bin 配下のシンボリックリンクで、実体が /usr/local/lib/node_modules 側にある場合、npmのグローバル保存先と関係している可能性があります。
すぐ直すならsudo、長く使うならnpm prefix変更
対処法は大きく3つあります。
| 対処法 | 向いているケース | 注意点 |
|---|---|---|
sudo npm install -g ... | 個人端末で、すぐに更新したい場合 | 管理者権限での実行になるため、対象パッケージ名を確認してから実行する |
| npm prefixをユーザー配下に変更 | 今後もnpmグローバルCLIをよく使う場合 | PATH設定と再インストールが必要になる |
| 所有者変更 | 既存環境を維持したい場合 | 影響範囲を誤るとシステム管理上の問題が出る可能性がある |
短期的には sudo で更新できる場合があります。ただし、共有サーバー、業務環境、管理ポリシーのある環境では、勝手にsudoを使うべきではありません。
個人利用のLinux端末で、今後もnpm製CLIを複数管理するなら、npmのグローバル保存先をユーザー配下へ移すほうが扱いやすい可能性が高いです。
対処法1: sudoで更新する
最短で更新したい場合は、管理者権限でnpmのグローバル更新を実行します。
sudo npm install -g package-name@latest
実行前に、少なくとも次を確認します。
npm view package-name version
npm list -g package-name --depth=0
which command-name
sudo を付けると、通常ユーザーでは書き込めない領域にも変更を加えられます。便利ですが、間違ったパッケージ名を指定したり、信頼できないパッケージを入れたりすると影響が大きくなります。
個人端末の一時対応としては使える場面がありますが、長期運用では毎回sudoが必要になる状態そのものを見直したほうがよいです。
対処法2: npmのグローバル保存先をユーザー配下に変更する方法
長く使うなら、npmのグローバルインストール先をユーザー配下へ変更する方法があります。これにより、以後 sudo なしでグローバルパッケージを更新できる可能性が高くなります。
一例として、ユーザーのホームディレクトリ配下にnpm用ディレクトリを作ります。
mkdir -p ~/.npm-global
npmのprefixを変更します。
npm config set prefix ~/.npm-global
シェル設定にPATHを追加します。bashを使っている場合の例です。
export PATH="$HOME/.npm-global/bin:$PATH"
この設定は、利用しているシェルに応じて ~/.bashrc、~/.profile、~/.zshrc などへ反映します。設定後、シェルを開き直すか、設定ファイルを読み込みます。
source ~/.bashrc
その後、CLIツールを入れ直します。
npm install -g package-name@latest
確認します。
npm config get prefix
which command-name
command-name --version
この方法では、npmグローバルパッケージの保存先がユーザー配下になります。Raspberry Piなどの個人Linux端末で、複数のCLIツールを手元管理したい場合に向いています。
対処法3: 所有者変更で直す方法は慎重に扱う
既存の /usr/local 配下の所有者を変更して対応する方法もあります。ただし、影響範囲を誤ると、他のNode.jsパッケージやシステム管理に影響する可能性があります。
特に、次のような操作は安易に実行しないほうが安全です。
sudo chown -R ... /usr/local
/usr/local 全体を一括で変更すると、npm以外のファイルにも影響します。どうしても所有者変更で対応する場合は、対象ディレクトリを絞り、現在の所有者、権限、インストール経路を確認してから実行します。
共有環境や業務環境では、管理者に確認するのが前提です。
更新後に確認すべきコマンド一覧
更新後は、インストールできたかだけでなく、実際に使うCLIが新しいものを向いているか確認します。
npmとパッケージの確認
npm config get prefix
npm list -g package-name --depth=0
npm view package-name version
CLI本体の確認
which command-name
command-name -V
command-name --version
ログイン状態の確認
command-name auth status
command-name whoami
ログイン確認コマンドはツールによって異なります。上の例で動かない場合は、次で確認します。
command-name --help
設定ファイルと環境変数の確認
env | grep -i model
env | grep -i api
設定ファイルの場所はCLIごとに異なるため、公式ドキュメントで確認します。デフォルトモデルが設定ファイルに明示されていない場合でも、ツール側の標準モデルが使われる可能性があります。
CLIツール本体の不具合と環境側の問題を切り分ける
npm install -g の更新で EACCES が出る場合、まず見るべきなのはCLIツール本体ではなく、npmとLinuxの権限です。
切り分けの順番は、次のようにすると迷いにくくなります。
npm config get prefixでグローバル保存先を確認するwhich command-nameで実行パスを確認するnpm list -g package-name --depth=0で現在のインストール状態を見るnpm view package-name versionでnpm上の最新版を見るEACCES、errno -13、syscall renameが出ているかログを確認する- 短期対応なら
sudo npm install -g ...、長期対応ならnpm prefix変更を検討する
npmキャッシュ破損やインストール途中の残骸など、他の要因が絡む可能性もゼロではありません。ただ、/usr/local/lib/node_modules 配下への書き込みやリネームで失敗しているなら、権限問題を第一候補として見ます。
まとめ
AIコーディングCLIを複数使う環境では、ツールごとの細かい違いより先に、共通の確認手順を持っておくと管理しやすくなります。
特に重要なのは次の点です。
- バージョン確認は
-V、--version、whichを組み合わせる - npm更新は
npm install -g package-name@latestが基本形 - 最新版確認には
npm view package-name versionを使う - グローバル導入済み確認には
npm list -g package-name --depth=0を使う - ログイン状態とモデル設定はCLIごとに確認方法が異なる
EACCES: permission deniedは、npmのグローバル保存先とLinux権限の問題である可能性が高い- すぐ直すなら
sudo、長く使うならnpm prefixをユーザー配下に変更する方法を検討する
次に同じ環境でCLI更新に失敗したら、まず npm config get prefix と which command-name を見る。ここでシステム領域を指しているかどうかが、最初の判断材料になります。
コメント