📝 Written ● Beginner Updated 2026-05-13

How do I explain terminal errors with AI in LingCode?

TL;DR: Select the error text in LingCode's terminal pane, right-click, and pick Explain with AI. A floating popup shows the explanation — out-of-band from your main chat, so it doesn't pollute your conversation context.

Right-click the cryptic error in your terminal, pick "Explain with AI," read the popup. The explanation stays out of your main chat — it's a glance, not a conversation, and the chat panel keeps its focus on whatever you were actually doing.

Half of working in a terminal is reading errors. Most errors are well-named once you've seen them — EADDRINUSE, command not found, permission denied — but the long tail is brutal. A linker error that mentions seven Mach-O symbols. A Gradle stack trace with twenty wrapped exceptions. A Swift compiler error that points at the wrong line. The pattern is always the same: a wall of text, a small actual signal, and a few minutes of squinting before you've found it.

The instinct, once you have an AI chat panel handy, is to copy the error there and ask "what does this mean." That works, but it has a cost. Your chat is in the middle of a task. The error you're pasting is unrelated. Now the model is balancing "the thing the user is actually working on" with "explain this unrelated linker error," and even when it does both, the conversation has grown a tangent that pollutes the context for the rest of your session.

The terminal-error explainer is the surgical alternative. The explanation arrives in a floating popup right next to the error, sourced from the same agent that would have answered in chat, but the chat doesn't know it happened. You get the explanation, you decide what to do, you dismiss the popup, and your main conversation continues where it left off. Two minutes saved, zero pollution.

What you'll learn

The right-click → Explain workflow
What the popup includes (and what it deliberately doesn't)
When the popup is the right tool, and when chat is
Selecting just the relevant lines for a better explanation
Following up: from popup to action

Step 1: Trigger an explanation

Select, right-click, Explain

In the terminal pane, select the error text — either highlight the relevant lines, or just put your cursor on the line and right-click. The context menu shows Explain with AI near the top.

Click it. A floating popup appears anchored to the selection, with a small spinner, then the explanation streams in.

Step 2: What the popup contains

One concept; three sentences

The explanation is short on purpose:

What the error means — translated into plain English from whatever stack-trace or vendor-specific phrasing was in the original.
The most likely cause — what condition in your code or environment usually produces this error.
The first thing to try — one concrete next step. Not a treatise; just "check X."

The popup is deliberately not a debugging session. It gives you the orientation you needed to read the error, and then it gets out of the way. If the first thing to try doesn't work, you escalate to chat — which is where the real diagnosis belongs.

The popup is read-only. You can't type follow-up questions in it. That's intentional — if you need a conversation, you need chat. The popup is for "what is this," not "help me fix this."

Step 3: Select wisely for a better explanation

More text isn't always better

The agent does best with a tight selection of the actual error, not the whole 200-line log. Best practice:

Select the line with the error message itself, plus the 2–4 lines of context above it (often where the cause shows up).
Avoid selecting the entire build log — it pads the context with output that isn't useful.
Avoid selecting just the error number (error: 1024) — strip out everything but the code and the explanation loses signal.

If the explanation is too vague, retry with a wider selection. If it's tangential to your problem, retry with a narrower one.

Step 4: When the popup is the right tool

Quick lookups, not debugging

Right tool for the popup:

You've seen this error before but forgot what causes it.
The error is from a tool you don't use often (linker, GPG, dtrace).
You want a "what is this" before deciding whether to invest more time.
The error is unrelated to your current chat task and you don't want to derail it.

Wrong tool for the popup:

The error is in code you're actively writing — chat is better, because the agent already has the file context.
You want a full diagnosis with proposed code changes — chat is better, because the popup deliberately doesn't propose edits.
This is the third error in a sequence and you want continuity — chat is better, because you want history.

Step 5: From popup to action

Three ways forward

After reading the popup, you have three reasonable next moves:

Try the suggestion immediately. If "check that the file exists" is the suggestion and you can run ls, just do it. Dismiss the popup, run the command, move on.
Open chat to dig deeper. If the explanation pointed at a real but non-trivial cause, escalate. The popup told you what kind of problem you have; chat is where you actually solve it.
Dismiss and ignore. Sometimes the error doesn't matter — a warning, a non-fatal log line, something benign. The explanation confirms that, and you can move on.

Step 6: Privacy and selection scope

What gets sent

The popup sends exactly the text you selected to the configured AI provider. No surrounding file content. No environment variables. No history of previous popups. Just the selection.

If your terminal output happens to contain secrets — a one-off command that printed an API key, say — be mindful of what you select. The same care you'd take when copy-pasting into any chat applies here.

The explanation doesn't replace reading the error. The popup is a translator, not an oracle. For errors where understanding the exact phrasing matters (security advisories, license violations, regulatory warnings), read the original carefully — the agent's paraphrase is a hint, not the source of truth.