docs: OpenCode plugin setup step and managed service env #3

Merged

troed merged 1 commit from docs/plugin-setup into main

2026-10-15 16:30:35 +02:00

troed commented

2026-10-15 16:24:52 +02:00

Owner

What

README — new ### 4. OpenCode plugin (optional, any deployment) setup step. The Setup
flow (local / hub / client) registered the read MCP server but never the plugin, and said
nothing about how the background service gets its environment.
The step registers the plugin directory and persists the hub endpoints with
opencode service set env … followed by opencode service start — the managed service
configuration every service start reuses — instead of a shell export the detached service
never sees.
plugin/opencode/README.md — the "environment belongs to the service" operator note now leads
with the same opencode service set env mechanism.

Why

OpenCode's shared background service starts once with the environment of the first client
invocation and keeps it. A variable exported for a later opencode run never reaches the plugin,
which then loads and registers nothing (no REFLECT_HUB_URL) — the most likely "it never injects"
cause.

Notes

Docs only, no code change.
--standalone / opencode serve do not read the managed configuration; the text says so.
Hygiene scan of the diff is clean (no hostnames, LAN IPs, or home-dir paths).

## What - **README** — new `### 4. OpenCode plugin (optional, any deployment)` setup step. The Setup flow (`local` / `hub` / `client`) registered the read MCP server but never the plugin, and said nothing about how the background service gets its environment. - The step registers the plugin directory and persists the hub endpoints with `opencode service set env …` followed by `opencode service start` — the managed service configuration every service start reuses — instead of a shell export the detached service never sees. - **plugin/opencode/README.md** — the "environment belongs to the service" operator note now leads with the same `opencode service set env` mechanism. ## Why OpenCode's shared background service starts once with the environment of the first client invocation and keeps it. A variable exported for a later `opencode run` never reaches the plugin, which then loads and registers nothing (no `REFLECT_HUB_URL`) — the most likely "it never injects" cause. ## Notes - Docs only, no code change. - `--standalone` / `opencode serve` do not read the managed configuration; the text says so. - Hygiene scan of the diff is clean (no hostnames, LAN IPs, or home-dir paths).

troed added 1 commit

2026-10-15 16:24:52 +02:00

docs: OpenCode plugin setup step and managed service env 1adb9b7b6c

The Setup flow (local/hub/client) registered the read MCP server but never
the OpenCode plugin, and nothing said how the background service gets its
environment. Add a plugin setup step that registers the directory and
persists the hub endpoints with `opencode service set env`, which every
service start reuses, then starts the service. Update the plugin README's
operator note to the same mechanism.

troed merged commit 9acc8b20d7 into main

2026-10-15 16:30:35 +02:00

troed deleted branch docs/plugin-setup

2026-10-15 16:30:35 +02:00

troed referenced this pull request from a commit

2026-10-15 16:30:36 +02:00

docs: OpenCode plugin setup step and managed service env (#3)