OpenCode 1.17.7 Makes MCP Workspace Roots and ACP Shell Approval Less Ambiguous

OpenCode 1.17.7 is not the kind of release that wins a launch thread. Good. Launch threads are often where agent infrastructure goes to cosplay as product. This patch is more useful: it tightens the boundary between the workspace, the MCP server, the editor-side approval UI, the plugin environment, and the human who has to decide whether an agent should run a shell command.

That sounds like plumbing because it is. But plumbing is exactly where coding agents fail once they move from a solo developer’s terminal into a team’s actual toolchain. The release shipped on June 14 with 19 commits and 170 changed files between v1.17.6 and v1.17.7. The headline items are compact: MCP servers can receive the current workspace as a client root, ACP shell tool calls show the command and working directory immediately, plugin-provided shell environment variables now apply to PTY sessions, and plugin client requests reuse the active server instead of assuming the default local port.

None of that writes a better React component by itself. All of it makes the agent less likely to lie about what it is doing.

Roots are a security boundary, not decoration

The most important change is MCP roots support. PR #32230 advertises the MCP client roots capability and answers roots/list by returning the current OpenCode instance directory as a file:// URI. The implementation deliberately omits listChanged because OpenCode’s roots are fixed for each instance-scoped MCP client. That restraint matters.

The MCP 2025-06-18 roots specification describes roots as filesystem boundaries exposed by the client to servers. Servers can request roots/list; clients that support the feature declare the capability; and the spec explicitly says clients should only expose roots with appropriate permissions while servers should respect those boundaries. In plain English: the server should know which workspace it is allowed to reason about instead of guessing from process state, configuration drift, or whatever path the model happened to mention in a tool call.

This is one of those protocol features that looks minor until you have a real setup. An MCP server might index a repo, read docs, search generated code, call internal scripts, or hydrate context from files. Without a declared root, every server invents its own answer to “where am I?” Some infer the current working directory. Some require config. Some ask the user. Some do the worst possible thing: accept path hints from the model as if they were trustworthy. Roots give the client a first-class way to say: this is the workspace boundary.

The subtle point is that OpenCode is following its own lesson from 1.17.6, which fixed MCP capability honesty. It is not advertising dynamic root-change notifications just because the spec contains that shape. It is saying: this client can answer roots for this instance; it will not promise a change stream it does not need. That is protocol hygiene. Agent clients should not pad their capability object like a resume.

Approval UX has to show the command, not the vibe

The ACP shell approval fix is the human-facing half of the release. PR #32304 fixes a failure mode where ACP clients such as Zed showed the bash tool description but not the actual command. After the change, the tool-call title becomes the command, and rawInput plus locations carry the command and resolved working directory while preserving kind: "execute" for native Run Command UI.

This is not polish. It is safety. A shell approval prompt that says something like “run tests” is not an approval prompt; it is an optimistic summary. The user needs the command and the working directory before approving anything meaningful. npm test in the project root is one thing. npm test -- --updateSnapshot in a generated fixture directory is another. A migration command in a local sandbox is one thing. The same command pointed at a production-like environment is not.

Agent products keep trying to make approvals feel less scary by compressing details into friendly labels. That is backwards. Approvals are where details matter most. If the model is about to execute code, mutate files, invoke package managers, or touch a directory that is not the one the user thinks is active, the UI has one job: show the exact operation before the user grants authority.

For teams evaluating OpenCode through Zed or another ACP client, this should become a basic acceptance test. Trigger a shell tool call. Confirm the UI shows the command, the resolved working directory, and the execution kind before approval. If it does not, you do not have a human-in-the-loop gate. You have a decorative speed bump.

Plugin environments cannot fork reality

PR #32296 adds a server-owned PTY environment seam and applies plugin shell environment values during canonical PTY creation while preserving caller, plugin, and forced terminal environment precedence. That is a mouthful, but the bug class is easy to understand: plugin behavior should not change depending on whether the agent launches a command through one shell path or a PTY path.

Plugins commonly need environment variables for endpoints, feature flags, credentials, model routing, local tool configuration, and integration-specific behavior. If those values apply to non-interactive commands but disappear in PTY sessions, the same plugin becomes nondeterministic. It works in a documented path, fails in an interactive path, and leaves the user debugging a phantom provider issue when the real bug is environment propagation.

This is exactly the kind of operational seam that separates an agent with a plugin list from an agent with a plugin ecosystem. Ecosystems require boring consistency. If a plugin declares shell environment values, the runtime needs to apply them predictably and preserve sane precedence rules. Otherwise the model starts compensating for runtime weirdness, which is how agents become superstitious.

The fourth release-note item points in the same direction: plugin client requests now reuse the active server instead of assuming the default local port. That matters for multi-instance or non-default server setups. A coding agent that has desktop apps, terminal sessions, IDE extensions, plugins, and local servers cannot assume the universe listens on the developer’s favorite default port. Reusing the active server is the kind of small control-plane fix that prevents state from splitting across surfaces.

OpenCode is competing on inspectable contracts

OpenCode’s broader position is still clear: it wants to be the open-source coding-agent alternative with provider choice, terminal/desktop/IDE surfaces, MCP support, and enough inspectability that practitioners can reason about what is happening. The docs describe it as an open-source AI coding agent available as terminal interface, desktop app, or IDE extension, installable through scripts, npm, Homebrew, Windows package managers, Docker, or binaries. The MCP docs support local servers with command, cwd, environment, enabled state, and timeout, and remote servers with URL, headers, OAuth, enabled state, and timeout. They also warn that MCP tools add to context and can push sessions over context limits, with GitHub MCP called out as token-heavy.

That warning is useful because MCP is not magic glue. It is a distributed systems boundary with context pressure, auth, latency, schema negotiation, filesystem scope, and failure-mode questions. OpenCode 1.17.7 improves three of those boundary questions: what workspace is exposed, what shell command is being approved, and which environment the plugin actually receives.

The integration/catalog refactor in PR #32272 also hints at where this is going. The release notes mention plugin client behavior, but the PR goes deeper: model availability is being refactored around integrations and credential state rather than provider environment state. Verification listed a repository-wide pre-push typecheck with 23 of 23 tasks passing, 36 focused core tests, 8 TUI data tests, and package typechecks across core, server, SDK, TUI, and CLI. That is not glamorous, but it is the right abstraction. In a real agent runtime, model availability depends on credentials, integration state, connection method, and refresh events — not just whether ANTHROPIC_API_KEY exists in a shell.

The practical upgrade advice is simple. If you run OpenCode seriously, upgrade and test the boundaries rather than asking whether the model “feels smarter.” Configure a local MCP server and verify it receives the expected workspace root. Trigger an ACP shell approval and inspect command/cwd visibility. Use a plugin that injects environment variables and run through a PTY path. Change provider credentials and confirm model availability refreshes without stale catalog state. These are boring tests. Boring tests are how agent infrastructure earns trust.

OpenCode 1.17.7 is a clear-contract release. The open-source coding-agent wedge is not only “bring your own model” or “avoid vendor lock-in.” It is the ability to inspect and reason about the protocol seams where MCP servers, ACP clients, plugins, shells, providers, and humans meet. That is where the product either becomes infrastructure or stays a clever terminal trick.

Sources: OpenCode v1.17.7 release, OpenCode docs, OpenCode MCP docs, MCP roots specification