Echo error when running command-line commands

[flyingrobots]

Reported from live use.

Typing commands produces echo error. Observed with the y command.

Needed to act on this

• The exact rendered error text, and whether an error code accompanies it
• Which commands reproduce it and which do not — y is the confirmed one; the set matters for diagnosis
• Whether it reproduces on a clean start with no file open, and with a file open

Suspicion

A command path submitting an intent the Echo host refuses, with the refusal surfaced raw as "echo error" rather than routed into the typed notification stack with a stated reason. If so there are two defects: the failing command, and the fact that an obstruction reaches the user as an unexplained string.

Acceptance

• The command works, or refuses with a reason a user can act on
• No user-visible error reads as a bare echo error

[flyingrobots]

Traced the render path. The wording in the report is almost certainly literal, and it identifies the mechanism.

pushRuntimeIssueToast (src/ui/feedback.ts:134) formats every runtime issue as:

title:   issue.level === "warning" ? "Runtime warning" : "Runtime error",
message: `${issue.source}: ${issue.message}`,

So an issue carrying source: "echo" renders as Runtime error / echo: <message> — which reads exactly as "it just says echo error". This is the raw-obstruction-reaching-the-user path I suspected when filing, now confirmed as a real code path rather than a guess.

What I ruled out

Yank is not the source. y is implemented entirely locally — yankTextRange (editor-editing-core.ts:66), yankCurrentLine (editor-editing-helpers.ts:245), applyYankRange (vim-command-executor.ts:281). All three operate on EditorState and never call the production text session, so a yank cannot itself produce an Echo obstruction.

That means the toast was raised by something else in flight at the time — a bounded window observation, a source-highlight refresh, or a command that does cross the Echo boundary.

What would pin it exactly

The message half — everything after echo: in the toast. That string is the obstruction's own text and identifies the failing operation unambiguously. A screenshot of the toast is ideal.

Also useful: whether it appears with no file open, and whether y alone triggers it or only yy.

Two defects here regardless of which operation it is

1. Whatever is refusing.
2. An Echo obstruction reaching the user as source: message with no actionable framing. Even once the first is fixed, an unexplained echo: ... toast is a poor failure mode for a refusal the application is supposed to understand.

No code change until the message text narrows it — I would rather not guess at a fix for an operation I have not identified.