The agent can alter the machine it is using.
OpenCode 2.0 moves its terminal interface, web interface, desktop app, and programmatic client onto one background service. The announcement says clients discover that local service automatically. It also says the service can be paired with other applications.
The plugin change is sharper. OpenCode says it implemented more than 80 internal plugins, made terminal-interface plugins stable, and added hot reload across 2.0. The post says the agent can write a plugin for itself during a session and use it at once.
A plugin reload is a code deployment. Treat it like one, even when the author and operator share the same chat window.
Fast feedback changes the review point
A restart used to create a natural pause. You could read the file, inspect the permissions, and decide whether to load it. Hot reload removes that pause. The review gate has to move before activation or the generated plugin becomes active before anyone has checked its authority.
The same service holds sessions for several clients. A bad plugin can therefore affect more than the tab that requested it. The exact reach depends on the plugin hooks and permissions. The 2.0 announcement does not prove that every plugin has broad access, so the right question is concrete: which hook runs, which files can change, which hosts can receive traffic, and which credentials are available?
Keep source and active state separate
Save the proposed plugin as a reviewable file. Record its digest before activation. List the hooks and capabilities it requests. Load that exact digest, then confirm which process accepted it. If the file changes again, the earlier review no longer applies.
Rollback needs its own test. Disabling a plugin should stop new calls, drain or cancel work already started, and leave the service in a known state. A backup file is not a rollback test. Run the unload path and confirm the old behavior returns.
Upgrade with the brakes visible
The 2.0 post calls out breaking changes. Version 1 plugins do not work in version 2. The server API changed. The terminal-interface configuration moved into the main configuration. That makes a parallel review useful before the major upgrade: inventory plugins, save the old configuration, identify each client's service target, and write the downgrade route.
The Hacker News discussion is not product documentation. It does expose the pressure point. Some users praised hot reload and the client-server split. Others argued that immediate self-modification needs stronger controls. That disagreement is enough reason to make the control sheet explicit instead of burying it in one upgrade command.