OpenCode 2.0: one background service for terminal, web and desktop, plus background subagents. What it changes for security

OpenCode, the open-source coding agent built by Anomaly, has moved to version 2.0. Its biggest change is architectural. Instead of each client running its own agent, OpenCode 2.0 runs one shared background service per user, and the terminal, web and desktop apps all connect to it. Version 2.0 also adds background subagents and shell commands that run asynchronously. On Hacker News, where the release post had drawn 862 points and 377 comments by October 16 after it was shared on October 14, users raised a practical problem: sandboxes wrapped around the terminal app no longer contain the agent, because the agent now runs in the service.

This story is based on Anomaly's release post, OpenCode's V2 documentation and changelog, a GitHub issue, The New Stack's October 12 coverage and the Hacker News discussion, checked October 16, 2026.

The short version

• One service, many clients: "By default, OpenCode discovers or starts one shared background server for your user account," per the CLI docs. Terminal, web and desktop sessions are interchangeable.
• Background work: subagents can run in the background, even on a different model. Long shell commands run asynchronously, and Ctrl+B moves a running task to the background.
• Code Mode: agents write JavaScript that calls several MCP tools in one go. It's on by default for all MCP servers.
• Breaking changes: V1 plugins don't run in V2, the server API is "completely different," and permission action names changed.
• Security: shell commands run with your full user permissions. To sandbox OpenCode, run it with --standalone or sandbox the service itself.

What changed in OpenCode 2.0?

Anomaly's release post calls 2.0 "a major overhaul." The post carries no date; The New Stack covered the release on October 12, 2026, and reported that a public beta had run since July. OpenCode's changelog is now on the 2.0.x series, with v2.0.30 dated October 15.

The background service. The server now "automatically runs as a single background process on your machine," Anomaly says. Per the troubleshooting docs, it "owns sessions, plugins, permissions, and other application state." You can start a session in the terminal and continue it on the web or desktop. Scripts can reach the same service through the @opencode/client package or opencode api commands, which Anomaly pitches for scheduled tasks. opencode pair gives the web client a local URL with a username and password, and opencode pair --remote can expose the service to other machines.

Background subagents. "Subagents run with fresh context in foreground or background child sessions," the agents docs say. Anomaly's example is handing a code review to a subagent on a different model while you keep prompting the main agent. A subagent uses its own configured permissions.

Async shell. Long-running commands, such as builds or test suites, no longer block the main agent, which is notified when they finish. If a foreground command or subagent runs long, Ctrl+B sends it to the background.

Code Mode. The @opencode/codemode package is "a minimal JavaScript interpreter" that turns MCP servers and OpenAPI endpoints into functions an agent can call from one script. Anomaly says this saves model round trips and keeps tool definitions from bloating the context. For background on MCP, see our MCP explainer.

Breaking changes. Per the migration guide, V1 plugins must be ported. Integrations that call the old server API need rewriting. The permissions config is now a single ordered list, and bash is now shell, task is subagent, and write and patch are edit. To upgrade, Anomaly says to get on the latest 1.x and run opencode upgrade --major. The embeddable @opencode/sdk is "still in development."

Documentation lagged the release. A GitHub issue opened September 29, titled "v2 releases have no published release notes," noted that the v2.0.20 GitHub release said only "release: v2.0.20." The issue was still open on October 16. The opencode.ai changelog now has 2.0.x entries.

How does OpenCode 2.0's security model work?

OpenCode controls the agent with permissions, not a sandbox. The permissions docs explain the rules:

• Each action, such as read, edit, shell, webfetch, subagent or an MCP tool, can be set to allow, ask or deny. The last matching rule wins.
• The default policy allows everything except reads of .env files and access to directories outside the project, which ask first. If no rule matches, OpenCode asks.
• The docs warn that "shell runs with the host user's filesystem, process, and network authority," and that inferring directories from command text "is best effort."

Permission prompts decide whether the agent may run a command. They don't limit what the command can do once it runs. OpenCode's security policy is blunt about this: "OpenCode does not sandbox the agent," the permission system "is not designed to provide security isolation," and users who need isolation should run OpenCode "inside a Docker container or VM." The policy treats sandbox escapes as out of scope for vulnerability reports. OpenCode's GitHub security page lists one advisory since the 2.0 beta began, published September 24, 2026: a high-severity flaw in which a cross-site upgrade request to the OpenCode server could install arbitrary packages on npm-based installations. None had been published in October as of October 16. Our explainer on unattended agents covers why that distinction matters.

What did Hacker News users raise?

The 2.0 thread on Hacker News, posted October 14, includes several security complaints. These are user reports, and OpenCode's team hadn't visibly replied on sandboxing in the thread as of October 16:

• Sandboxes stopped working. One user wrote that "the sandbox that i use to wrap the TUI process quietly became useless," and said web fetches that should have been blocked went through. Wrapping the terminal app no longer covers the agent's tools, which run in the shared service. Another user answered: "You need to run it with --standalone to properly sandbox it." The CLI docs confirm that --standalone runs a private server, and opencode service set disabled true makes that the default.
• Plugin tools and permissions. A commenter said "tools added by plugins don't respect your permission config." OpenCode's changelog shows related fixes. Version 2.0.29 (October 14) added a helper so plugins can use configured permission rules and the approval prompt. Version 2.0.30 (October 15) includes MCP tool input in permission requests.
• Hot reloading. Another commenter argued that "an agent should not be able to modify plugins and have that immediately reloaded." The same user counted "at least 3 security regressions" in the initial V2 release.

The changelog also shows other hardening since launch. Version 2.0.26 moved remote-access URLs to "a persistent random subdomain rather than a predictable route." Version 2.0.27 made the first opencode pair --remote warn that it "will expose your server" and ask for confirmation, and it blocked file:// access through Code Mode's fetch.

Why it matters

A shared local service makes OpenCode behave more like a desktop app with several windows, and it fits long-running background agents. It also moves the agent out of whatever process you used to start it, which affects anyone who relied on wrapping that process. If you sandbox coding agents, check where OpenCode's service runs before trusting your wrapper.

OpenCode is one of four open-source launch partners for Sign in with ChatGPT's plan-usage feature, which launched September 29, 2026, so Plus and Pro subscribers can run it on their ChatGPT plan's usage. For how it fits among commercial agents, see Claude Code vs Codex vs Cursor.

What's confirmed, reported and uncertain

• Confirmed (Anomaly and OpenCode docs):
  • the shared background service and the --standalone and service-disable options
  • background subagents, async shell and Ctrl+B
  • Code Mode on by default for MCP servers
  • breaking changes and upgrade steps
  • the default-allow permission policy and the warning about shell authority
  • the security policy's statement that OpenCode doesn't sandbox the agent
  • changelog fixes for plugin permissions, remote pairing and Code Mode fetch
• Reported (user reports on Hacker News, October 14–15):
  • sandboxes wrapping the terminal client no longer containing the agent
  • plugin tools bypassing permission rules
  • claimed security regressions
• Uncertain:
  • whether every plugin-permission gap is closed
  • how the service authenticates local clients; the docs mention authentication but don't describe it
  • when the SDK leaves development