The agent left the tab.

One process, several cockpits

OpenCode 2.0 now starts one background service on the local machine. Its terminal interface, web interface, desktop app, and programmatic client connect to that process. The release post says @opencode/client can discover the service. The CLI also exposes API commands and a pairing flow for other applications.

That changes the operating model. Closing one interface does not necessarily define the life of the work. A session can belong to the service, move to a worktree, and continue while another client watches it.

The terminal tab used to contain the job. A persistent service needs a dashboard that names the job.

Sessions need addresses

The new API can create worktrees, rename sessions, move a session to another directory, interrupt work, send another prompt, and close tabs. OpenCode's release demo shows those actions as calls against named session IDs and locations.

VS Code 1.142 landed a related idea on the same day. Its Agents window can move an eligible Codex chat into another folder or a new Git worktree while keeping the conversation history. The release notes say the current turn finishes before the workspace changes. Commands and edits then run in the new location.

The shared lesson is narrow. Conversation history is becoming portable across work locations. That makes the current directory, repository, worktree, and process owner more important, not less. Put them where the operator can inspect them without scrolling through old messages.

Background work needs a brake

OpenCode 2.0 adds background subagents and asynchronous shell commands. A long foreground operation can also be moved to the background. VS Code 1.142 now lists attached background shells and provides a keyboard-reachable Stop Shell action. Its documentation draws a boundary: detached shells run independently and cannot be stopped from that control.

A useful pit wall should make the same distinction. Show which process owns a task. Name whether a stop action reaches the session, an attached command, or the whole service. A red button without a named target is stage dressing.

Code mode raises the stakes

OpenCode's Code Mode turns MCP servers and OpenAPI endpoints into functions that an agent can compose in a script. The release post says this can replace several sequential tool calls with one scripted round trip. It also says MCP servers opt into Code Mode by default in 2.0.

That is a useful execution path. It also compresses several consequential actions into one program. The operator still needs a readable record of the selected tools, arguments, returned identifiers, and stop boundary. Fewer model round trips do not remove the need for review.

We checked the shipped handle

The public repository and npm registry expose the product. We resolved @opencode/cli version 2.0.29 and ran only its help command in a temporary home and cache. The help listed the api, service, pair, and serve commands. It also listed --standalone for a private server and --server for a chosen server URL.

We did not authenticate, start the service, open a repository, connect a provider, or test process containment. The control below drafts an operator sheet. It does not prove that OpenCode or any other agent is running.

Build the fixed readout

1. Pin the service and client versions separately.
2. Give every session a stable ID, repository, worktree, and authority mode.
3. List attached and detached work under different stop controls.
4. Record which surface issued each consequential action.
5. Test session stop, service stop, restart, and recovery with harmless fixtures.