OpenCode 1.17.4 Ships the Boring MCP Fixes Teams Actually Need

OpenCode 1.17.4 is the kind of release that looks small until you have actually tried to run a coding agent against a messy repo with real tools, real credentials, and a model provider that does not quite behave like the last one.

The changelog is not trying to win a demo day. It adds cwd support for local MCP servers, connector-based authentication flows and stored provider credentials, v2 API endpoints for sessions/questions/location, raw file reads with correct content types for API and SDK clients, MCP server log notifications in OpenCode logs, visible content-filter errors, Gemini schema compatibility fixes, MCP header preservation, huge-repo snapshot speedups, and MCP catalog timeout fixes. In other words: the boring pieces that decide whether an open-source coding agent becomes team infrastructure or remains a weekend tool with a Discord following.

That is why this release matters. OpenCode’s wedge is not “free Claude Code clone.” That undersells the interesting part. The more durable pitch is configurable, inspectable agent infrastructure: a coding-agent harness you can operate, debug, extend, and route across providers. But that promise only works if MCP auth, schema compatibility, repository snapshots, refusal surfaces, and tool logging are boring enough to trust.

MCP cwd support is small until your repo is not

The headline operational fix is PR #30676, which adds optional cwd support to local MCP server configuration. Relative paths resolve against the workspace directory. Absolute paths pass through. Omitting the field preserves existing behavior. The PR added tests for omitted, relative, and absolute cwd cases.

That sounds like plumbing, because it is. But it is important plumbing. Local MCP servers are often not single global binaries that behave identically from any directory. They may wrap a docs server in a subfolder, a generated client under tools/, an internal search index, a test runner, a schema compiler, or a bespoke repo assistant that assumes relative paths. Without a stable working directory, teams end up hardcoding absolute paths into per-developer config. That is how an integration becomes unshareable the moment a second engineer clones the repo.

OpenCode’s MCP docs now describe local MCP config with type: "local", command, optional cwd, environment, enabled, and timeout. Remote MCP supports URL, headers, OAuth config, and timeout. The docs also include a useful warning that MCP servers add to context and tool catalogs can quickly consume context, with GitHub MCP called out as token-heavy. That warning should be printed on the box of every agent platform. Tool discovery is not free; it is prompt budget, latency, and a larger attack surface with a nicer name.

The MCP fixes are really distributed-systems fixes

MCP is marketed as the universal connector layer for agents. In practice, it is a distributed systems boundary with auth, headers, schema normalization, timeouts, context pressure, logging, and failure modes. OpenCode 1.17.4 lands on several of those seams.

MCP header preservation matters because remote servers often depend on configured headers for OAuth, API keys, tenancy, tracing, or debugging. If auth or diagnostic requests drop those headers, the integration becomes intermittent in the exact place where determinism matters most. Catalog timeout fixes matter for the same reason. If prompts, resources, and tools are discovered under different timeout behavior, startup can vary by server and network path. “The agent hung while loading tools” is not an LLM problem. It is a connector lifecycle problem.

Surfacing MCP server log notifications in OpenCode logs is another good sign. Agent harnesses need local observability. When a tool call fails, developers should not have to guess whether the model selected the wrong arguments, the MCP server rejected auth, the schema was normalized incorrectly, or a catalog request timed out. Logs do not make a system enterprise-ready by themselves, but missing logs make it impossible.

Provider portability dies in schema details

PR #31877 fixes Gemini multi-type schema incompatibility with some tools and MCPs, especially through GitHub Copilot. The release note says compatible tools keep working instead of being rejected by Gemini schema handling. This is exactly the kind of issue open-source harnesses have to absorb if they want model routing to be more than a dropdown.

The whole point of OpenCode is that users can route work across providers and setups instead of accepting a single vendor’s stack. But providers do not agree perfectly on tool schemas, streaming chunks, refusal semantics, structured output, or content filtering. If one provider accepts a schema and another rejects it, the application-level promise of portability breaks. Worse, users may blame the agent rather than the provider impedance mismatch, because from their seat “the tool worked yesterday” is the only observable fact.

OpenCode 1.17.4 also fixes content-filtered model responses that previously produced no visible output and left the session idle. PR #31745 adds a ContentFilterError to the assistant error union and publishes session.error when the finish reason is content-filter with no existing error. That is not a glamorous feature, but it is essential UX. A refusal or filter event should be visible, typed, and recoverable. Silent idle states train users to distrust the harness.

The huge-repo snapshot fix is the enterprise tell

The most revealing fix is PR #31798, which addresses snapshot creation in huge repositories. On a Chromium checkout of roughly 500,000 files and 69 GB, the old first git add --all path did not finish within 90 seconds. The fix seeds the snapshot repo from the source repo’s object database and index so add becomes a stat-only diff where possible.

This is the difference between a tool that looks magical on a small sample repo and one that survives contact with platform teams. Agents need safe snapshot, diff, and revert semantics. But if those semantics require re-hashing the world on a massive checkout, the developer experience collapses before the model does anything useful. Reusing Git’s object database and index is the correct systems move: keep the safety model, remove the unnecessary cold-start pain.

Teams evaluating OpenCode should make this part of the test plan. Do not just run it on a tidy demo repo. Try a monorepo. Try a generated-code directory. Try a checkout with many ignored files and a slow filesystem. Measure snapshot time, tool discovery time, first-token latency, and revert behavior. Agents are often sold through the happy path; infrastructure buyers should test the haunted path.

The community signal is adoption with caveats

A June 5 Ask HN thread asking about AI development stacks had 168 points via Algolia and repeatedly mentioned OpenCode in real workflows. One commenter described “OpenCode + their Go subscription” as a batteries-included setup. Another said they use OpenCode with architect/developer/reviewer agents and different models for writing versus review. A third described OpenCode plus a web UI, Opus, plugins, indexing MCPs, and a separate dev-plans repo.

The thread was not pure applause. One user called OpenCode good enough for basic work despite “many shortcomings and constant bugs.” Another objected to unexpected external requests when trying local usage. That is the right practitioner picture: curiosity, adoption, and trust-boundary questions arriving together. Open-source coding agents win on inspectability only if users can actually see what talks to what, when, and why.

The practical takeaway: if you are adopting OpenCode, build an evaluation checklist around the things this release just touched. Configure local MCP servers with relative cwd values and test on another machine. Verify remote MCP headers survive auth and debug paths. Force content-filter cases and make sure the UI surfaces errors. Switch providers with the same tool schema. Run against a huge repo and measure snapshot behavior. Check logs before you need them.

OpenCode 1.17.4 is not a fireworks release. Good. The coding-agent category has enough fireworks. What teams need now is boring operational correctness: paths that resolve, headers that stick, schemas that survive providers, snapshots that do not stall, and errors that show up instead of becoming vibes. This release moves in that direction.

Sources: OpenCode v1.17.4 release, OpenCode MCP docs, OpenCode agents docs, PR #30676, PR #31745, PR #31877, PR #31798, Ask HN discussion