Output is part of the interface
Build tools are optimized for humans watching a terminal. Progress redraws, repeated warnings, and long logs work poorly when every line becomes context for a language model. A failed copy command can also trigger several extra calls just to discover which directory was missing.
mish sits between the command and its caller. It categorizes the command, chooses an output strategy, and returns exit status, timing, and useful context. The processing uses heuristics rather than another language model.
Different commands need different treatment
Build and test output goes through terminal parsing, progress removal, deduplication, and truncation that retains the head and tail. Inspection commands can pass through verbatim, while selected commands such as git status receive structured parsing.
On failure, mish can inspect paths, permissions, and nearby files before returning. In MCP mode, five tools cover command execution, background processes, process interaction, named terminal sessions, and help. Watch patterns let an agent ask for the output relevant to what it is monitoring.
Keep the detail recoverable
Condensing a log always involves choosing what to omit. The design needs a way back to the details: output spools, process tails, and interactive sessions let the caller inspect further when the first response is insufficient.
The same core serves a standalone command-line proxy and an MCP server. That keeps the useful part—the command classification, output processing, and diagnostics—available without requiring a particular agent harness.