コンテンツにスキップ

GitHub Copilotがターミナル出力を見失うときの対処法：run_in_terminal後の回復手順を決めておく

GitHub Copilot 完全ガイド

Copilotに修正と検証まで任せた直後に、「見れませんでした」で止まることがある。 面倒なのはテストの失敗そのものではない。失敗ログが会話に戻らず、次の一手が空回りする点である。

対象 / ポイント

対象: VS CodeのGitHub Copilot Agent / Chatで、pytestやnpm testの出力をAIが拾えず、 「見れませんでした」「Command produced no output」となる場面で詰まっている開発者。

ポイント:

  • いちばん効くのは、出力を見失ったあとの手順を先に書いておくことである。
  • 第一回復策はget_terminal_last_commandである1。
  • 長いログには.copilot/terminal-output.txtへの退避も用意しておく。

Copilotが自分でpytest -qやnpm testを実行した直後に結果を見失う。 この症状がいちばん厄介だが、手動で実行したログをCopilotに読ませる場面でも、 根本の詰まりどころは変わらない。Copilotが出力を取り直す手順を持っていないことである。

この記事では、Copilotがrun_in_terminalで実行した検証を見失うケースを中心に、 手動実行のログにも応用できる回復手順を整理する。

この記事でわかること

  • なぜget_terminal_last_commandを最初に使うべきなのか
  • 長いログを.copilot/terminal-output.txtへ逃がす場面
  • .github/copilot-instructions.mdとAGENTS.mdのどちらに書くべきか

結論

結論は単純である。「見失ったあとに何をするか」をカスタム指示へ先に書いておく のがいちばん効く。

.github/copilot-instructions.mdかAGENTS.mdに、次のルールを書いておく。

## Terminal verification recovery

When you run tests, builds, linters, migrations, or other verification commands
yourself via terminal tools:

1. Do not trust the initial `run_in_terminal` output alone.
2. If the output is empty, partial, inconsistent, or missing, immediately use
   `get_terminal_last_command`.
3. If the command is verbose, streaming, or `get_terminal_last_command` is still
   unclear, rerun the same command with stdout/stderr written to
   `.copilot/terminal-output.txt`.
4. Append the exit code to the same file and inspect that file before concluding.
5. Only if both recovery paths fail, ask the user to attach or paste the
   relevant log section.

要するに、Copilotが検証を実行したあとに結果を見失ったら、 まずget_terminal_last_commandで取り直す。それでも足りなければ、 ログをファイルへ逃がして再実行する。この順番を先に決めておくのである。

なぜ最初に get_terminal_last_command なのか

ここは推測ではなく一次情報で押さえられる。VS Code issue #253265 は、 run_in_terminalとget_terminal_outputが空を返すのに、ユーザーには出力が 見えている不具合としてverified付きで扱われている1。

同じ issue の Workaround Available には、 get_terminal_last_commandは正しく動き、stdout / stderr、実行時刻、 作業ディレクトリ、実行コマンドを取得できると書かれている1。 つまり、最初の回復策はすでに示されている。

整理すると、回復順は次の表になる。

段階Copilotがやること目的
1run_in_terminalで検証を実行通常の検証
2出力が空、部分的、不整合ならget_terminal_last_commandを使う同じterminal系統で取り直す
3それでも怪しい、またはログが長いなら.copilot/terminal-output.txtへ退避して再実行するterminal buffer依存を外す
4それでも失敗したときだけユーザーに添付や貼り付けを頼む最後のfallback

重要なのは、ユーザー再実行や手動添付を最初の解決策にしないことである。 先に試すべきなのは、Copilot側の回復手順である。

GitHub Community Discussion #161238 でも、 .github/copilot-instructions.mdにget_terminal_last_commandのfallbackを 書いて改善したという報告がある5。一方で、それでも足りないという返信も続く。 だからこそ、第二回復策まで用意しておく価値がある。

長いログにはファイル退避で再実行する

get_terminal_last_commandは第一回復策として有効だが、万能ではない。 長いログ、流れ続ける出力、WSLやSSH越しの環境では、 terminal bufferだけに頼ると再び取りこぼすことがある。

そこで第二回復策として、Copilot自身にログ退避つきで再実行させる。

bash / zsh

mkdir -p .copilot
set -o pipefail
pytest -q 2>&1 | tee .copilot/terminal-output.txt
printf '\nEXIT_CODE=%s\n' "$?" >> .copilot/terminal-output.txt

PowerShell

New-Item -ItemType Directory -Force .copilot | Out-Null
pytest -q 2>&1 | Tee-Object .copilot/terminal-output.txt
"EXIT_CODE=$LASTEXITCODE" | Tee-Object -Append .copilot/terminal-output.txt

.copilot/はGit管理から外しておく方が扱いやすい。

.copilot/

この形には三つの利点がある。

  1. stdoutとstderrを一つのファイルにまとめられる
  2. exit codeまで同じファイルへ残せる
  3. Copilotがterminal bufferを見失っても参照先が固定される

どこに書くべきか

VS Code docs では、.github/copilot-instructions.mdもAGENTS.mdも always-on instructionsとして扱われる2。ただし、複数の instruction files が ある場合は結合してchat contextへ渡され、順序は保証されない2。

この挙動を前提にすると、書き分けは次の方が扱いやすい。

  • Copilot固有の挙動に寄せるなら.github/copilot-instructions.md
  • 複数エージェントで共有したいならAGENTS.md
  • 両方使うなら、同じ内容を重複させず役割を分ける

今回のterminal recoveryはかなりCopilot寄りである。 そのため、基本は.github/copilot-instructions.mdへ置く方が自然である。 すでにAGENTS.mdに運用ルールを集約しているなら、そこへ寄せてもよい。

手動で実行したログにも同じ考え方が使える

ここまではCopilot実行ケースを中心に書いてきたが、 ユーザーが手でpytestやbuildを実行し、その結果をCopilotに解析させたい場面でも、 考え方はほぼ同じである。

違いは出発点だけである。

  • Copilot実行ケースではrun_in_terminalの直後にget_terminal_last_commandを使う
  • 手動実行ケースでは、既存のterminal outputを読み直させるか、 必要なら.copilot/terminal-output.txtへ切り出して読ませる

きっかけが違っても、回復順はほぼ同じである。

ユーザーが介入するのは最後のfallbackだけ

この記事は、ユーザーの手動実行を否定するものではない。 ただ、AIが自力で回復できるなら、その順番を先に決めておいた方が運用は安定する。

ユーザーがやるのは最後だけでよい。

  • Copilotがget_terminal_last_commandでも回復できない
  • Copilotがログ退避で再実行しても、そのファイルをうまく参照できない
  • そのときだけ.copilot/terminal-output.txtを#参照かドラッグ＆ドロップでChatへ渡す3

VS Codeはfile contextを#メンション、ドラッグ＆ドロップ、 Add Context > Files & Foldersで追加できる3。これは便利である。 ただし、基本ルートではなく最終手段として扱う方がよい。

先に整えるべき環境

カスタム指示だけで全部が片付くわけではない。terminal integrationが弱い環境のままだと、 回復手順そのものの発火率が落ちるためである。

1. 対応shellを使う

VS Code docs は、agentがcmdとshを既定shellとして避ける理由を明記している。 shell integrationを使えず、agentから見たterminalの可視性が低く、 結果として slow and flaky experience になるためである4。

  • macOS / Linux: bashまたはzsh
  • Windows: PowerShell

必要なら次の settings で agent 用 terminal profile を明示する4。

  • chat.tools.terminal.terminalProfile.windows
  • chat.tools.terminal.terminalProfile.osx
  • chat.tools.terminal.terminalProfile.linux

2. Powerlevel10k を使っているなら更新する

GitHub Community Discussion #161238 では、 2025年10月17日 にTyriarが回答し、 再現要因の一つとして old versions of powerlevel10k を挙げている5。

ただし、discussion全体を読むと更新だけで全部解決したとは言い切れない。 get_terminal_last_commandのfallbackが効いた人もいれば、 効かなかった人もいる。補助的な是正策として見るのが妥当である。

3. VS Code / Copilot は最新へ寄せる

2026年4月時点でも terminal tools の改善は続いている。 2026年4月8日 の VS Code 1.115 では chat.tools.terminal.backgroundNotifications が追加され、 background terminal の完了や入力待ちをagentが受け取りやすくなった6。

2026年4月15日 の VS Code 1.116 では、 send_to_terminal と get_terminal_output が foreground terminal でも動くように なっている7。terminal handling はまだ動いている領域だと見た方がよい。

一次情報で確認できること

2026年4月20日時点で、実務判断に直結する一次情報は三つに絞れる。

1. verified済みの不具合に回復策が書かれている

VS Code issue #253265 は、 run_in_terminal / get_terminal_output が空でも、ユーザーには出力が見えている 不具合としてverified付きで扱われている1。しかも本文に、 get_terminal_last_commandは動くという workaround が書かれている。

2. instructions は workspace 全体に自動適用できる

VS Code docs は、.github/copilot-instructions.mdをworkspace全体へ自動適用すると 明記している。AGENTS.mdも同じ always-on instructions の層にある2。 つまり、Copilotの検証フローそのものを project policy として固定できる。

3. terminal 系は改善中だが完了ではない

VS Code 1.115 と 1.116 の release notes を見ると、 background notifications や foreground terminal support など、 terminal tools の改善がまだ続いている67。 現時点で「もう回復策は不要」とまでは言いにくい。

FAQ

Q1. get_terminal_last_command だけで十分か

十分な環境もあるが、十分でない環境もある。 community discussion でも、効いた報告と効かなかった報告が混在している5。 そのため実務では、get_terminal_last_command単独ではなく、 file fallback まで instructions に含める方が堅い。

Q2. まずユーザーに再実行してもらえばよいのではないか

それを最初の手にすると、AIが毎回そこで止まりやすくなる。 先に Copilot 側の回復手順を固定し、最後だけユーザーに助けてもらう方が、 会話も検証ループも安定する。

Q3. .github/copilot-instructions.md と AGENTS.md のどちらに書くべきか

Copilot固有の挙動へ寄せるなら.github/copilot-instructions.mdが自然である。 複数エージェントで共有したいならAGENTS.mdでもよい。 両方を使う場合は、同じ内容を重複させず役割を分ける方が安全である2。

Q4. どんなときにファイル退避へ切り替えるべきか

ログが長いとき、出力が流れ続けるとき、WSL / SSH / remote でぶれやすいとき、 get_terminal_last_commandでも判断がつかないときである。 この条件を最初から instructions に書いておくと迷いにくい。

まとめ

この問題で先に決めるべきなのは、誰がpytestを打つかではない。 Copilotがterminal outputを見失ったときに、どの順番で取り直すかである。

実務上は、get_terminal_last_commandを第一回復策にし、 必要なら.copilot/terminal-output.txtへ逃がして再実行する。 その順番を .github/copilot-instructions.md か AGENTS.md に書いておけば、 「見れませんでした」で止まる回数はかなり減る。

terminal周りの不安定さは、モデルの賢さよりもツール境界の設計に近い問題である。 だからこそ、回復手順を先に決めておく方が効く。

関連記事

  1. Agent/Chat extension cannot see terminal command output, but shows normally in terminal #253265 | microsoft/vscode ↩↩↩↩

  2. Use custom instructions in VS Code | Visual Studio Code Docs ↩↩↩↩

  3. Manage context for AI | Visual Studio Code Docs ↩↩

  4. Use tools with agents | Visual Studio Code Docs ↩↩

  5. Copilot does not detect terminal command has completed or is not getting terminal output #161238 | GitHub Community ↩↩↩

  6. Visual Studio Code 1.115 Release Notes | Visual Studio Code ↩↩

  7. Visual Studio Code 1.116 Release Notes | Visual Studio Code ↩↩