You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 6102079
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: .opencode/skills/opencode-dev/SKILL.md
+26-17Lines changed: 26 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,17 +12,18 @@ Workflow for interactively exercising the V2 CLI/TUI and server while developing
12
12
opencode V2 is a client/server system, not a single monolithic process:
13
13
14
14
-**Server process** runs the Effect HTTP API (`packages/server`) and owns all domain state: sessions, database, plugins, permissions, Location services. It's started by the `serve` command (`packages/cli/src/commands/handlers/serve.ts`).
15
-
-**TUI process** is a separate process that runs no application logic itself — it's an HTTP/SSE client of the server via the generated SDK (`createOpencodeClient` / `sdk.client.v2`).
16
-
-**Discovery**: CLI processes find the shared server through a JSON registration file at `~/.local/state/opencode/service.json` (or `service-local.json` for the local/dev channel) containing `{id, version, url, pid}`. A separate password file under `~/.config/opencode/service.json` provides HTTP Basic auth. Before reusing a registration, the client calls `GET /health` to confirm the server is alive, authenticated, and version-compatible.
15
+
-**TUI process** is a separate process that runs no application logic itself — it's an HTTP/SSE client of the server via `@opencode/client` (`OpenCode.make`).
16
+
-**Discovery**: CLI processes find the shared server through a JSON registration file at `~/.local/state/opencode/service.json` (or `service-local.json` for the local/dev channel) containing `{id, version, url, pid, password}`; the password is used for HTTP Basic auth. Before reusing a registration, the client calls `GET /api/info` to confirm the server is alive, is the registered PID, and is version-compatible. `opencode service status` prints the registered URL.
17
17
-**Sharing**: because of this registration/health-check dance, many concurrent `opencode`/TUI invocations converge on one shared background daemon rather than each spawning their own. If no compatible healthy daemon is found, a new one is spawned detached (`serve --service`) and registers itself.
18
18
-**`bun dev service start|status|stop|restart`** manages this shared background daemon's lifecycle directly — useful when you need to force a fresh server, confirm one is running, or kill a stuck one.
19
19
-**Standalone mode** (`--standalone`) opts a single invocation out of the shared daemon: it spawns a private one-off `serve --stdio --port 0` child tied to that invocation's lifetime, with its own random password. Use this to isolate a debugging session from your other running opencode sessions.
20
20
- Every log line is tagged `role=server` or `role=cli` and a per-process `run=<id>`, so you can distinguish server-side and client-side activity in one shared log file (see "Logs" below) even when both roles are interleaved from concurrent processes.
21
21
22
22
## Starting the dev TUI
23
23
24
-
- This package is the V2 CLI adapter. Run its `dev` script when testing the TUI; do not use the repository-root `bun dev`, which launches the legacy `packages/opencode` CLI.
25
-
- Run commands from `packages/cli`. Use `bun dev` for most debugging so the TUI starts with a private V2 server.
24
+
-`packages/cli` is the CLI and TUI entrypoint. `bun dev` from `packages/cli` and the repository-root `bun dev` both run `packages/cli/src/index.ts`.
25
+
-`bun dev` connects to the shared local-channel background service (`service-local.json`), starting it if needed. Every worktree on the machine shares that service. Add `--standalone` for a private server tied to this one process.
26
+
- Use `bun run dev:live` from the repository root to run this worktree's TUI against the installed `opencode` background server and your real sessions.
- Source changes may require restarting the process. Use `termctrl restart opencode-v2-dev` rather than assuming the running TUI reloaded the change.
61
+
- Source changes may require restarting the process. Use `termctrl restart opencode-v2-dev` rather than assuming the running TUI reloaded the change. Restarting the TUI does not restart the shared background service, so run `bun dev service restart` after server-side changes, or use `--standalone`.
61
62
- To exercise background-service behavior, use `bun dev service start`, `bun dev service status`, and `bun dev service stop`.
62
63
- Always clean up the Terminal Control session when the check is complete:
63
64
@@ -67,13 +68,13 @@ termctrl stop opencode-v2-dev
67
68
68
69
## Comparing V2 against the legacy TUI
69
70
70
-
Run both versions in separate Terminal Control sessions and save PNG-only captures at equivalent states:
71
+
The legacy V1 CLI is still published as `opencode-ai` on npm; V2 is `@opencode/cli`. Run both versions in separate Terminal Control sessions and save PNG-only captures at equivalent states:
71
72
72
73
```bash
73
74
# From packages/cli: local V2 TUI
74
75
termctrl start opencode-v2-dev --host opentui --cols 112 --rows 34 -- bun dev
-`bun dev api` accepts either an OpenAPI operation ID or a raw HTTP method plus path:
91
92
92
93
```bash
93
-
bun dev api get /health
94
+
bun dev api get /api/info
94
95
bun dev api get /openapi.json
95
96
bun dev api <operationId> --param key=value
96
97
```
@@ -99,13 +100,13 @@ bun dev api <operationId> --param key=value
99
100
- If no compatible background server is registered, `bun dev api` starts one through the daemon service. Use `bun dev service status`, `bun dev service restart`, and `bun dev service stop` when you need explicit lifecycle control.
100
101
- Prefer raw method/path calls for quick server debugging and operation IDs when exercising documented OpenAPI routes with path or query parameters.
101
102
102
-
## Auditing installed `opencode2` sessions
103
+
## Auditing installed `opencode` sessions
103
104
104
-
Installed next-channel sessions normally use `~/.local/share/opencode/opencode-next.db` and `~/.local/share/opencode/log/opencode.log`; `OPENCODE_DB` can override the database. Before calling `opencode2 api`, inspect `~/.local/state/opencode/service.json` because the command may start a daemon when none is healthy.
105
+
Installed (released) sessions use `~/.local/share/opencode/opencode.db` and `~/.local/share/opencode/log/opencode.log`. A local/dev checkout uses `opencode-local.db` and `opencode-local.log` instead, and `OPENCODE_DB` overrides the database. Run `opencode service status` before `opencode api`, because `opencode api` starts a server when none is healthy.
105
106
106
107
For a supplied `ses_...` ID, compare three sources:
107
108
108
-
-`opencode2 api get /api/session/active` and the Session/message endpoints for live server state.
109
+
-`opencode api get /api/session/active` and the Session/message endpoints for live server state.
109
110
- The database's ordered `event` rows for durable history.
110
111
-`packages/tui/src/context/data.tsx` and the relevant route for client projection and rendering.
The CLI installs a `SIGUSR1` listener on non-Windows processes in `packages/cli/src/heap.ts`. Use it to capture the installed `opencode2` server without restarting it or attaching an inspector.
145
+
On every platform, including Windows, capture the running background server without restarting it or attaching an inspector:
146
+
147
+
```bash
148
+
opencode debug heap-dump
149
+
```
150
+
151
+
It discovers the already-running service (never starts or replaces one), calls `POST /api/debug/heap-dump`, waits until the file is complete, and prints its server-local path. Pass `--server <url>` (with `OPENCODE_PASSWORD`) for a server started with `serve`. A 404 means the running server predates the endpoint.
152
+
153
+
The Unix `SIGUSR1` listener in `packages/cli/src/heap.ts` shares the same writer (`packages/util/src/heap-snapshot.ts`) and is still useful for a process that is not an HTTP server, such as a TUI client:
145
154
146
155
1. Find the processes and inspect their roles and memory:
2. Signal the process whose heap needs investigation. For shared-service memory, target the `opencode2.exe serve --service`child, not the short wrapper/TUI process:
162
+
2. Signal the process whose heap needs investigation. For shared-service memory, target the `opencode serve --service`process, not a TUI process:
154
163
155
164
```bash
156
165
kill -USR1 <server-pid>
@@ -189,13 +198,13 @@ Heap serialization itself can temporarily increase RSS and allocator high-water
189
198
190
199
The CLI installs a `SIGPROF` listener on non-Windows processes in `packages/cli/src/cpu-profile.ts`. One signal starts a ten-second CPU profile and stops it automatically; additional signals are ignored while a profile is active. There is no CPU profile CLI flag or environment variable.
191
200
192
-
1. Get the PID from the health endpoint. For shared-service performance, target the server PID returned here rather than the short wrapper or TUI process:
201
+
1. Get the PID from the info endpoint. For shared-service performance, target the server PID returned here rather than a TUI process:
193
202
194
203
```bash
195
-
opencode2 api get /api/health
204
+
opencode api get /api/info
196
205
```
197
206
198
-
Use `bun dev api get /api/health` instead when targeting the local/dev channel.
207
+
Use `bun dev api get /api/info` instead when targeting the local/dev channel.
0 commit comments