OpenCode 1.15.11 Fixes the Runtime Edges That Make Agents Feel Haunted

OpenCode 1.15.11 is not trying to win the screenshot war. It is doing something more useful: sanding down the runtime edges that make coding agents feel haunted after the happy path breaks.

The release is a pile of fixes that only looks small if you have never operated agent tooling for real work: provider header timeouts, push updates for experimental background agents, stable identity for remote-backed projects, clean disconnection for dynamic MCP servers, Google tool-call fixes, session-resume repairs, reasoning-summary rendering, shell timeout visibility, plugin dispose hooks, and Codex plugin session-header fixes. That is not miscellany. That is the surface area of a modern coding agent.

The industry still talks about agents as if the core question is whether they can edit code. That question is stale. The harder question is whether the session survives retries, aborted streams, flaky providers, removed tools, remote projects, plugin churn, and UI state transitions without corrupting the developer’s understanding of what happened. OpenCode’s release notes read like maintainers paying down bugs that active users actually hit. That is usually where trust is built.

The bug that explains the whole release

The most revealing fix is PR #26178, which excludes orphaned interrupted tools from run-loop continuation. The failure mode is wonderfully unpleasant. A session could retain an interrupted tool_use, the run loop could treat it as still relevant, and the next Claude request could end with malformed history. The provider then rejected it with HTTP 400: “This model does not support assistant message prefill.” Once persisted, retries replayed the same broken state.

Users do not describe that as “conversation-history invariant violation after interrupted tool accounting.” They say the agent got stuck. Maybe they blame Claude. Maybe they blame OpenCode. Maybe they delete the session and learn not to trust long runs. Runtime reliability lives exactly in that translation gap between a crisp internal bug and the user’s vague sense that the tool is unreliable.

This is why agent products need more than good prompt engineering. They need careful state machines. Tool calls are not chat messages with extra JSON. They are transactional edges in a long-running workflow. If the runtime cannot distinguish completed, interrupted, orphaned, resumed, and invalid tool states, it will eventually produce histories that no model provider wants and no human can debug.

OpenCode’s shell timeout visibility points at the same principle. The shell tool now advertises its configured timeout to the model. That sounds minor until you watch an agent plan a command sequence under false assumptions. If the model thinks it has unlimited time, it may choose broad scans, slow tests, or blocking operations. If the timeout is visible, the plan can adapt. Runtime constraints should be part of the agent’s working context, not hidden host trivia.

MCP lifecycle is a permission boundary

Dynamically added MCP servers now disconnect cleanly when removed. This is another fix that should be treated as security-adjacent, not just housekeeping. Adding a server is only half of lifecycle management. Removing one has to mean the capability is gone. A connector that remains alive after the UI or config says it was removed is a permission bug wearing an implementation detail costume.

As MCP becomes the shared integration layer across coding agents, lifecycle correctness needs to be boring: connect, authorize, call, disconnect, revoke, audit. Most teams are currently excited about the first three verbs and under-invested in the last three. That is backwards. The long-term risk in MCP is not that agents cannot find enough tools. It is that every vendor and internal platform team ships a server, and nobody can tell which ones are active, authorized, stale, or still reachable from old sessions.

OpenCode’s clean-disconnect fix is therefore part of a bigger industry pattern. The next wave of agent governance will look a lot like service governance: inventory, ownership, scopes, credentials, telemetry, revocation, and incident response. If that sounds heavy for a CLI, that is because the CLI has stopped being “just a CLI.” It is now a local control plane for code-changing automation.

Background-agent push updates fit this maturity arc too. Polling is easy to ship, but it creates latency, unnecessary load, and awkward freshness semantics. Push-based updates for experimental background agents make the system feel less like a black box. More importantly, they create a path toward proper cancellation, progress reporting, policy intervention, and audit trails. You cannot govern background work you cannot observe.

Provider churn is not an edge case

Several fixes are about providers and model configuration because multi-provider support is a permanent tax. OpenCode adds provider headerTimeout config, with a 10-second default for OpenAI setups. It fixes DigitalOcean inference authentication after the /v2/gen-ai/models/api_keys endpoint began returning 410, switching to direct OAuth access tokens with genai:read and inference:query scopes. It repairs Google tool-call behavior. It allows custom model configs to specify only modalities.input or modalities.output, avoiding startup crashes for common LM Studio image-input setups.

The lesson is not “providers are messy,” though they are. The lesson is that coding agents are compatibility layers over moving systems. Model APIs change, auth endpoints move, local model servers expose partial modality metadata, and provider-specific reasoning summaries need their own rendering. The best tools will not eliminate this churn. They will make it explicit, configurable, and recoverable.

For teams adopting OpenCode or any open agent runtime, this is the procurement question hiding under the developer-tool choice: how does the tool fail when an upstream changes behavior? Does it expose timeouts? Does it isolate provider errors? Does it preserve session integrity? Can a plugin clean itself up? Can a remote-backed project keep stable identity? Can you reproduce the failure from logs without asking the model what it thinks happened?

The TUI and desktop polish belongs in the same bucket, even if it feels less serious. Configurable prompt dimensions via tui.json, including an automatic width based on terminal size, are ergonomics. Full-color shell inheritance and reasoning-summary rendering are ergonomics. But developer trust is partly made of ergonomics. A tool that mangles terminal behavior, hides progress, or renders important model output awkwardly gets treated like a toy no matter how powerful the backend is.

The action item for practitioners is not complicated. If you use OpenCode with remote projects or background agents, upgrade and test the exact workflows that used to make you nervous. Interrupt a tool call and resume the session. Add and remove an MCP server and verify it really disconnects. Set provider header timeouts deliberately. Check shell timeout assumptions on long-running commands. If you run local multimodal models, simplify modality config after the optional-field fix. If you build plugins, implement dispose behavior instead of leaking state across sessions.

OpenCode 1.15.11 is not glamorous, and that is the point. Agent runtimes become trustworthy when interruptions, remotes, MCP servers, providers, plugins, and terminal state become boring. The tools that win this category will not be the ones that produce the boldest demo diff. They will be the ones that make a half-failed session understandable enough that a senior engineer does not reach for rm -rf and a fresh checkout.

Sources: OpenCode v1.15.11 release, PR #26178, PR #28255, PR #29268, PR #28897