opencode v1.15.9 Ships the Review and Error Surfaces Agent CLIs Usually Forget

opencode v1.15.9 is the kind of release that makes a coding agent less impressive in screenshots and more useful in a real repository. The headline features are not a new personality, a benchmark claim, or a magic “build my app” button. They are a default diff viewer, clearer PTY and MCP errors, OAuth details that administrators can actually reason about, and continuation metadata that survives across turns.

That is exactly the work open agent CLIs need. The open-source side of the coding-agent market often wins on flexibility: more providers, faster integrations, fewer platform assumptions, less lock-in. But flexibility without reviewability and failure surfaces turns into entropy. When an agent can edit files, run shell commands, call MCP servers, switch models, and resume long sessions, “something went wrong” is not an acceptable error message. It is an admission that the runtime has not caught up with the autonomy it exposes.

Version 1.15.9, published May 22 at 21:18 UTC, follows opencode v1.15.6’s initial TUI diff viewer and v1.15.7’s safer session API errors. The pattern is clear: opencode is investing in the parts of agentic coding that happen after the model says it is done.

Default diff review is the trust feature

The redesigned diff viewer is now enabled by default and includes a file tree plus a refreshed layout. That sounds like product polish. It is actually a trust boundary.

Coding agents earn credibility at review time, not generation time. A generated patch is only useful if a human can quickly see what changed, where the blast radius is, and whether the agent’s explanation matches the actual diff. If reviewing an agent’s work requires leaving the tool, running separate git commands, opening another UI, and reconstructing intent from terminal scrollback, users will either under-review or stop using the workflow for serious code. Both outcomes are bad.

A built-in file-tree diff viewer changes the default path. The agent edits; the developer reviews in the same surface; the diff becomes the unit of trust. This matters especially for long-running sessions where the agent may touch five files for a reason that made sense thirty tool calls ago. The review surface has to answer the basic questions fast: which files changed, which changes are mechanical, which changes alter behavior, and which changes look like the model got lost.

There is a broader product lesson here. Agent tools keep competing on generation speed, but the bottleneck for professional use is often review bandwidth. The better tool is not always the one that writes the most code. It is the one that makes the generated code easiest to reject, trim, or merge with confidence.

Specific errors beat haunted automation

The release also improves HTTP and API error surfaces across missing PTY sessions, project-not-found cases, PTY error bodies, missing MCP servers, busy sessions, invalid or unavailable default models, skill invocation failures, and installation upgrade failures. This is the part of the changelog most users will skim. They should not.

Agent CLIs are becoming runtimes. Runtimes need distinct failure modes. A missing PTY session is not the same problem as a busy session. An unavailable default model is not the same problem as a failed skill. An MCP server not found is not the same problem as a project lookup failure. Collapsing those states into generic messages wastes developer time and makes users blame the model for what is actually orchestration plumbing.

This matters even more for wrappers and integrations. Editors, dashboards, remote controllers, CI harnesses, and internal developer platforms increasingly sit on top of agent APIs. Those systems cannot recover intelligently from vague failures. They need to know whether to retry, ask the user to reconnect a terminal, refresh project state, fall back to another model, or open an auth flow. Better error bodies are not merely nicer logs; they are the contract that lets the ecosystem build safely above the CLI.

opencode’s v1.15.7 work on safer session API errors with log reference IDs and v1.15.9’s broader error specificity point in the right direction. The open-agent ecosystem should copy this aggressively. A coding agent that cannot explain its own runtime failures is not ready to be a platform dependency.

MCP OAuth is where convenience meets governance

MCP OAuth configuration now supports callback ports and includes configured scopes in client metadata. That is a small line with large practical implications. MCP is the layer where coding agents reach beyond the repo into external systems: issue trackers, cloud providers, docs, observability tools, databases, and internal APIs. Authentication details are not setup trivia. They define what the agent can touch.

Callback port control matters in real enterprise and local-development environments where loopback ports may be reserved, proxied, blocked, or audited. Scope metadata matters because security review without explicit scopes becomes theater. If an MCP integration can authenticate but nobody can easily see what permissions it requested, the organization has not gained an agent tool. It has gained a credential-shaped blind spot.

This is also why opencode’s Vertex Anthropic endpoint fix is more than provider maintenance. The release now uses working us and eu continental multi-region .rep.googleapis.com endpoints for Vertex Anthropic setups. For teams with regional constraints, provider routing is part of compliance and reliability. An agent that silently fails or routes incorrectly across regions is not just annoying; it may be unusable in the environments most likely to pay for governed tooling.

The release’s preservation of native reasoning continuation metadata across turns deserves attention too. Long-running agent work is not a pile of isolated completions. It is a chain of decisions, partial plans, tool calls, errors, and recoveries. If continuation metadata is dropped, the next turn may still produce text, but the session loses part of the operational thread. That is how agents become mysteriously inconsistent: not because the model suddenly got worse, but because the runtime forgot what kind of reasoning path it was on.

Practitioners should treat v1.15.9 as a smoke-test release. Run it on a branch with a non-trivial diff and decide whether the default viewer supports your actual review habits. Exercise the HTTP API failure cases your wrappers depend on. Test MCP OAuth with explicit scopes and non-default callback ports. If you run Vertex Anthropic, verify the us and eu paths. Resume a reasoning-heavy session and check whether the agent’s next step still reflects the previous plan rather than merely the latest prompt.

opencode is not making the loudest promise in the agent market here. It is doing something more durable: making review, errors, auth, and continuation less fragile. That is what open coding agents need if they want to be trusted with more than toy refactors.

Sources: opencode v1.15.9 release notes, opencode v1.15.7, opencode v1.15.6, opencode repository