mise等のランタイムバージョン管理ツールは、標準コマンドをshim（薄いラッパー実行ファイル）としてPATH上に配置し、呼び出し時に対象バージョンの実体バイナリへ委譲する。このshim自体が、起動のたびに自身の設定ファイル（ホームディレクトリ配下の設定）を読みに行く実装になっていることがある。

誤解しやすい条件

• CLIツールの「ホームディレクトリ配下への書き込み」機能（初期設定ファイル生成等）をテスト・サンドボックス環境で検証したいとき、実ホームディレクトリを汚さないためにHOME環境変数を一時ディレクトリへ差し替えて実行する手法はよく使われる。
• ところが、標準コマンドがバージョン管理シム経由で解決されている場合、シム自身が新しいHOMEを基準に自分の設定ファイルを探しに行き、その設定が「信頼されていない」「存在しない」等の理由でエラーを返し、コマンド全体が実行されない（対象コマンドの標準出力・エラーが一切出ないまま失敗する）ことがある。この失敗はテスト対象のロジックとは無関係で、原因の特定に時間がかかりやすい。

判断基準

• サンドボックス・テストで環境変数（特にHOMEのようなツール自身の設定探索に使われる変数）を差し替えて外部コマンドを実行する場合、そのコマンドがバージョン管理ツールのシム経由で解決されていないかを先に確認する（PATH上の全候補を列挙し、シムらしきパスが混じっていないかを見る）。
• シム経由だと分かった場合は、シムを迂回して実体バイナリのパスを直接指定して呼び出す。これによりシム自身の設定読み込みロジックを回避しつつ、対象コマンド自体は正しいバージョンで実行できる。

検証

同じコマンドをシム経由（PATH解決）と実体バイナリ直接指定の両方で実行し、後者でのみ想定どおりの標準出力が得られるかを比較する。シム経由で出力が一切出ない・原因不明のエラーで即座に終了する場合はこのパターンを疑う。

関連

シムのパス自体が環境変数で変わる話（配置場所の特定）とは別軸で、こちらはシムが正常にPATH解決されている前提でも、HOME差し替えによりシム自身の内部ロジックが壊れる話。