GitHub Copilot Loses Terminal Output: Define the Recovery Path After run_in_terminal¶

Q: Is get_terminal_last_command enough on its own?

Sometimes it is enough, and sometimes it is not. Community reports are mixed, so in practice it is safer to pair it with a file-based fallback.

Q: Should I write this in .github/copilot-instructions.md or AGENTS.md?

Use .github/copilot-instructions.md if the rule is mainly about Copilot behavior. Use AGENTS.md if you want the rule shared across multiple agents.

Q: When should I switch to the file-based fallback?

Use the file-based fallback when output is long, streaming, remote, or still unclear after get_terminal_last_command.

GitHub Copilot Complete Guide

The most frustrating failure mode is not a failed test. It is the moment after a test runs, the terminal clearly has output, and Copilot replies as if nothing useful came back.

For / Key Points

For: Developers using GitHub Copilot Agent / Chat in VS Code who see terminal-related failures such as "Command produced no output" or "I couldn't read the output."

Key Points:

The most reliable fix is to define the recovery path before the failure happens.
get_terminal_last_command should be the first recovery step¹.
For long or streaming output, prepare a file-based log fallback.

When Copilot edits code and immediately runs pytest -q or npm test, it can lose track of the output right after execution. A similar problem appears when you run the command yourself and ask Copilot to interpret the result. The core issue is the same: Copilot needs a reliable way to recover terminal output.

This article focuses on the case where Copilot runs verification commands via run_in_terminal, but the same recovery order also works for manually executed logs.

What You'll Learn¶

Why get_terminal_last_command should come first
When to switch to a file-based log fallback
Where to place the rule: .github/copilot-instructions.md or AGENTS.md

Conclusion¶

The most effective fix is simple: decide what Copilot should do after it loses terminal output, and write that down as always-on instructions.

Put a rule like this in .github/copilot-instructions.md or 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.

That is the whole strategy. First, recover with get_terminal_last_command. If that still is not enough, rerun with a durable log file.

Why Start with `get_terminal_last_command`¶

This part is grounded in primary sources. VS Code issue #253265 is marked verified and describes the exact failure mode where run_in_terminal and get_terminal_output return empty output even though the user can see output in the terminal¹.

The same issue explicitly lists get_terminal_last_command as a workaround and states that it captures stdout / stderr, the execution timestamp, the working directory, and the full command text¹.

That leads to a practical recovery order:

Step	What Copilot should do	Why
1	Run verification with `run_in_terminal`	Normal path
2	If output is empty, partial, or inconsistent, call `get_terminal_last_command`	Recover in the same terminal layer
3	If output is still unclear, rerun with `.copilot/terminal-output.txt`	Stop depending on the terminal buffer
4	Only then ask the user to attach or paste logs	Final fallback

The GitHub Community discussion #161238 points in the same direction. Some users report that adding a get_terminal_last_command fallback to custom instructions helped, while others still needed more than that⁵.

Use a File-Based Fallback for Long Logs¶

get_terminal_last_command is the right first move, but it is not enough for every environment. Long logs, streaming output, WSL, SSH, and remote setups can still be unstable.

In those cases, let Copilot rerun the command with a file-based log.

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

It also helps to keep .copilot/ out of version control:

.copilot/

This fallback matters because it gives Copilot a stable source of truth even if the terminal buffer becomes unreliable.

Where to Put the Rule¶

According to the VS Code docs, both .github/copilot-instructions.md and AGENTS.md are treated as always-on instructions². The same docs also state that when multiple instruction files exist, VS Code combines them into chat context and does not guarantee a specific order².

That makes the split straightforward:

Use .github/copilot-instructions.md for Copilot-specific behavior
Use AGENTS.md for rules shared across multiple coding agents
If you use both, do not duplicate the same instruction in both files

For terminal recovery, .github/copilot-instructions.md is usually the more natural home because the behavior is tightly coupled to Copilot's terminal tools.

The Same Logic Works for Manually Run Logs¶

This article centers on Copilot-run verification commands, but the same logic also works when you run the command yourself.

The only difference is the starting point:

If Copilot ran the command, recover with get_terminal_last_command
If you ran the command, either let Copilot re-read the output or cut the relevant part into .copilot/terminal-output.txt

The trigger changes. The recovery order does not.

User Intervention Should Be the Last Fallback¶

This is not an argument against manual execution. It is an argument for keeping manual intervention as the last step instead of the first one.

Ask the user to help only when:

get_terminal_last_command still does not recover enough detail
The rerun with .copilot/terminal-output.txt still is not usable
You need the user to attach or drag the file into chat as context³

VS Code supports #-mentions, drag and drop, and Add Context > Files & Folders for file context³. That is useful. It just should not be the first move.

Fix the Environment Before You Blame the Model¶

Custom instructions help, but the environment still matters.

1. Use a Supported Shell¶

The VS Code docs explain why the agent avoids cmd and sh as default shells: shell integration is not supported well enough, so the agent has limited visibility into terminal state and the experience becomes slow and flaky⁴.

macOS / Linux: bash or zsh
Windows: PowerShell

If needed, configure the terminal profile explicitly with:

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

2. Update Powerlevel10k if You Use It¶

In GitHub Community discussion #161238, Tyriar's October 17, 2025 answer points to old versions of powerlevel10k as one possible contributor⁵. That is not a universal fix, but it is worth checking.

3. Keep VS Code / Copilot Current¶

As of April 2026, terminal tooling is still actively changing.

VS Code 1.115 added chat.tools.terminal.backgroundNotifications⁶
VS Code 1.116 expanded foreground terminal support for send_to_terminal and get_terminal_output⁷

That is another reason to keep a recovery rule in place rather than assuming the problem has disappeared.

FAQ¶

Q1. Is `get_terminal_last_command` enough on its own?¶

Sometimes, yes. Sometimes, no. The community reports are mixed⁵. In practice, it is safer to pair it with a file-based fallback.

Q2. Why not ask the user to rerun the command first?¶

Because that turns a recoverable agent failure into a recurring workflow break. It is better to let Copilot try recovery first and ask for help only at the end.

Q3. Should I write this in `.github/copilot-instructions.md` or `AGENTS.md`?¶

Use .github/copilot-instructions.md if the rule is mainly about Copilot's behavior. Use AGENTS.md if you want the rule shared across multiple agents.

Q4. When should I switch to the file-based fallback?¶

Use it when output is long, streaming, remote, or still unclear after get_terminal_last_command.

Summary¶

The key decision is not who ran pytest. The key decision is what Copilot should do next when terminal output becomes unreliable.

Start with get_terminal_last_command. If that is not enough, rerun with a durable log file. Once that order is written into always-on instructions, the agent stops getting stuck on the same class of failure.