Repository navigation
Open
Labels
Description
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), channellatest - Active plugins:
./plugins/claude-mem(server plugin),./plugins/plugin-info(cli plugin), both local directories under~/.config/opencode/plugins/
Reproduction
- From any directory (I ran it with cwd = my project directory), run
opencode service restart. - Grep the server log for location boots:
rg "location services booted" ~/.local/share/opencode/log/opencode.log - 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 wholeserena.exeprocess tree plus its own web-dashboard port). - Global plugins are instantiated for the home location as well. Because
ctx.event.subscribeis the server-wide stream, that extra instance also handles other locations' sessions: I measured a singlesession.text.endedevent 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 --standaloneboots its own cwd as the location (verified: it booted the temporary directory it was started from), which suggests the service is nominally started with$HOMEas its cwd. - Registration is written to
~/.local/state/opencode/service.jsonas{ 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
serviceoption (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.
Reacted by Mario and Mario
Activity
github-actions commentedon Sep 15, 2026
This issue might be a duplicate of an existing issue. Please check:
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report. I can reproduce the core of this on 2.0.3, and it still happens on the latest
dev(950111f).What I saw (Linux, server API):
serve --service, whichopencode service startlaunches) from a project directory. Its working directory was still the home directory: in service mode it always switches to$HOME.GET /api/agentwithoutlocation[directory]or thex-opencode-directoryheader) makes the server fall back to its own working directory. It logslocation services booted directory=<home>and starts a full location for home, with its MCP servers and plugins.One thing I couldn't pin down: on Linux, the bundled CLI commands and the TUI attached to the service only booted the project. So something in your setup (the Windows client, or possibly a plugin calling the SDK without a location) is sending the request without a location. If you can find which request it is, for example from the server log just before the home boot, that would help.
The script below reproduces it against the service API.
Closely related:
Reproduction script (repro.sh)
Run it:
bash repro.sh