service: background server boots the user home directory as a location

Summary

The background server (opencode service) comes up with the user's home directory as its working directory and boots that directory as a location, even though no client asked for it. Every location gets its own MCP servers and plugin instances, so an unused "home" project is started on every server start.

Environment

• opencode version: 2.0.3
• OS: Windows NT 10.0.26200 (win32, x64)
• Terminal: TERM=xterm-256color, TERM_PROGRAM/COLORTERM unset
• Shell: cmd.exe
• Install/channel: global Bun install (@opencode/cli), channel latest
• Active plugins: ./plugins/claude-mem (server plugin), ./plugins/plugin-info (cli plugin), both local directories under ~/.config/opencode/plugins/

Reproduction

1. From any directory (I ran it with cwd = my project directory), run opencode service restart.
2. Grep the server log for location boots:
   rg "location services booted" ~/.local/share/opencode/log/opencode.log
3. Observe that the server boots the user's home directory as a location before/alongside the requested project.

Expected Behavior

The background server should boot only locations that a client actually requests (or at minimum the caller's project directory). Starting the service should not create a location for the user's home directory.

Actual Behavior

Immediately after opencode service restart, the log shows two location boots:

18:22:08Z location services booted directory="C:\\Users\\<user>"
18:22:10Z location services booted directory="C:\\Users\\<user>\\Workspace\\Work\\<project>"

The second is my session's project. The first is the home directory, which nothing requested.

Impact observed:

• A full set of MCP servers is spawned for the home location (8 configured servers, including serena, which starts a whole serena.exe process tree plus its own web-dashboard port).
• Global plugins are instantiated for the home location as well. Because ctx.event.subscribe is the server-wide stream, that extra instance also handles other locations' sessions: I measured a single session.text.ended event being delivered to 3 plugin instances, producing duplicate observation posts.
• Extra language-server / child processes and one wasted dashboard port per server start.

Additional Context

• The service is spawned detached and its cwd is not inherited from the caller — the restart above was issued with cwd = the project directory, yet home was booted. A private server started with opencode api --standalone boots its own cwd as the location (verified: it booted the temporary directory it was started from), which suggests the service is nominally started with $HOME as its cwd.
• Registration is written to ~/.local/state/opencode/service.json as { id, version, url, pid, password } (password redacted here).
• No autostart is involved: there is no scheduled task or startup shortcut for opencode; the service is started on demand by the CLI and then stays resident.
• No configuration field seems to control the server's initial location, so there is no user-side workaround. A service option (or not booting any location until a client asks) would resolve it.
• Related, but distinct: when the same project is reachable through two path spellings (a symlinked path and the real path), opencode registers two locations with two sets of instances. The home boot is a third, automatic one that appears even with a single spelling.