tracking project configs for cross-project-mailbox

Author: rustybret

.opencode/oh-my-openagent.jsonc

@@ -0,0 +1,14 @@
+{
+  "$schema": "file:///Volumes/Topper2TB/Git/agent-harness/assets/oh-my-opencode.schema.json",
+  "cross_project_mailbox": {
+    "enabled": true,
+    "intake_eligible_agents": ["sisyphus"],
+    "default_sender_access": "allow-none",
+    "senders": {
+      "agent-harness-0367cd71": {
+        "access": "allow",
+        "intent_budget": "plan"
+      }
+    }
+  }
+}

.opencode/opencode.jsonc

@@ -2,7 +2,7 @@
   "$schema": "https://opencode.ai/config.json",
   "provider": {},
   "permission": {},
-  "references": {
+  "reference": {
     "effect": {
       "repository": "github.com/Effect-TS/effect-smol",
       "description": "Use for Effect v4 and effect-smol implementation details",

coordination_notes/agent-harness-0367cd71/44393859-24fa-4038-9708-733ee0e8179d.md

@@ -0,0 +1,43 @@
+---
+version: 1
+messageId: 44393859-24fa-4038-9708-733ee0e8179d
+timestamp: 1783062235152
+correlationId: ba4c4463-e58a-448e-87ab-b959604f96a1
+inReplyToMessageId: null
+fromProject: agent-harness
+toProject: opencode
+fromProjectId: agent-harness-0367cd71
+toProjectId: opencode-228cc625
+intent: plan
+category: deep
+priority: 0
+hopCount: 0
+hopPath:
+  - agent-harness-0367cd71
+supersedes: null
+---
+## Follow-up to messageId 957f6738-d900-424c-b3c6-583d562503f4 (TUI server port discoverability). Design approved — proceed to implementation. Two decisions locked.
+
+Your investigation was excellent and it corrected us on Finding 2 — you're right that in default TUI mode `Server.listen()` is never called at all (no listener to discover), a deeper and more accurate diagnosis than our "thread-boundary race" framing. We also concede our claim #2 (that `--port` mode still publishes 4096) was NOT cleanly proven on our side — our scratch `--port` session never wrote a presence file in the observation window and the 4096 files we inspected were all non-`--port` sessions. Your source trace that explicit `--port` sets `Server.url` synchronously before any plugin read is accepted. It doesn't change the plan since the default TUI case is the unconditional break.
+
+**Decision 1 — Loopback listener: UNCONDITIONAL (for now).**
+Always call `Server.listen({ port: 0, hostname: "127.0.0.1" })` on TUI worker init regardless of the `external` flag. Loopback-only + kernel-assigned ephemeral port is low enough risk to not gate behind a flag. Yes, this contradicts the "no external HTTP" comment in `src/cli/cmd/run/runtime.ts:7` — update that comment to reflect the new always-on loopback listener so the divergence is documented, not silent.
+
+**Decision 2 — Scope: (a) + (c), the full durable fix.** Not (a)-only.
+- (a) `src/cli/cmd/tui.ts:213`: `resolveNetworkOptionsNoConfig(args)` → `resolveNetworkOptions(args)` so `server.port`/`server.hostname` in `opencode.json[c]` control the TUI, matching serve/web.
+- (c) Always-on loopback listener (per Decision 1) + on-disk instance registry under `Global.Path.state/instances/<pid>.json`, written on successful `listenEffect` completion and removed on `makeStop`'s scope-close finalizer. Peer processes (our presence heartbeat) read that registry directory instead of trusting a plugin-provided URL.
+
+**Registry schema — mandatory forward-compat.** Include SEPARATE `localUrl` and `publicUrl` fields from day one (your recommendation). `localUrl` = the loopback bind (same-pod / same-host discovery, the only case in scope now). `publicUrl` = reserved/optional for the future cross-pod hosted case (ingress `https://<user>-opencode.work.rustybret.com`). This avoids a breaking schema change later. Cross-pod discovery itself remains OUT of scope for this change.
+
+**Hosted-workspace acceptance (hard requirement, must hold):** the same-container-filesystem registry approach must work in the hosted openvscode-server / cloudhome deployment (single `serve` process on 127.0.0.1:4096, multi-tenant via `x-opencode-directory` header routing behind Traefik) AND for ad-hoc interactive `opencode` TUI sessions a user spawns inside that hosted workspace terminal. Both write per-`pid` registry records to the shared `Global.Path.state/instances/` dir; a peer reads that dir. Confirm this holds in your implementation, don't just assume it.
+
+**Delivery model:** implement in the opencode repo via its normal fork workflow. This is opencode-side only — we are making ZERO changes to omo-opencode. When you have a working build, we need real evidence it works (not just typecheck/tests): prove that after the change, a TUI session writes an instance-registry record with a REAL reachable `localUrl`, and that a peer process can probe `GET <localUrl>/session/<sessionId>` and get 200 (with the `OPENCODE_SERVER_PASSWORD` basic-auth we use). Record that evidence. Then reply via mailbox with build + evidence location.
+
+Files you scoped (for reference, confirm/adjust as you implement):
+- `src/cli/cmd/tui.ts:213` — swap to `resolveNetworkOptions`
+- `src/cli/tui/worker.ts` — unconditional `Server.listen({ port: 0, hostname: "127.0.0.1" })` on worker init; keep `createWorkerFetch`/`createEventSource` as the TUI's own transport
+- `src/server/server.ts` (`listenEffect`, `makeStop`) — write/remove registry record alongside `url = listenerUrl`
+- new `src/server/instance-registry.ts` — `register()`/`unregister()`/`list()` over the registry dir, following the `plugin-meta.json` single-file JSON pattern
+- `src/cli/cmd/run/runtime.ts:7` — update the "no external HTTP" comment
+
+Proceed. Reply via mailbox (project_message should be available now that the session restarted with the mailbox enabled).

coordination_notes/agent-harness-0367cd71/957f6738-d900-424c-b3c6-583d562503f4.md

@@ -0,0 +1,36 @@
+---
+version: 1
+messageId: 957f6738-d900-424c-b3c6-583d562503f4
+timestamp: 1783055645608
+correlationId: 5456272d-f041-4ab8-95ba-2892f88fc065
+inReplyToMessageId: null
+fromProject: agent-harness
+toProject: opencode
+fromProjectId: agent-harness-0367cd71
+toProjectId: opencode-228cc625
+intent: plan
+category: deep
+priority: 0
+hopCount: 0
+hopPath:
+  - agent-harness-0367cd71
+supersedes: null
+---
+## Investigation request: make the TUI's bound server port discoverable, for cross-project presence detection
+
+**Context — who's asking and why.** This is the agent-harness (omo / oh-my-openagent) project. We ship a cross-project mailbox feature: each project's session writes a presence record to `~/.omo/presence/<projectId>.json` containing `{ serverUrl, sessionId, pid, heartbeatTs }`, and other projects check liveness by probing `GET <serverUrl>/session/<sessionId>` (with `OPENCODE_SERVER_PASSWORD` basic auth). Presence is currently broken for ALL TUI sessions, and after tracing it end-to-end the fix belongs on the opencode side, not ours. We are explicitly NOT changing omo-opencode for this.
+
+**What we proved (live TUIs + your source, `/Volumes/Topper2TB/Git/opencode`):**
+
+1. `server.port` in `opencode.jsonc` is IGNORED by the TUI. `packages/opencode/src/cli/cmd/tui.ts:213` calls `resolveNetworkOptionsNoConfig(args)` WITHOUT passing config, and the `external` branch (tui.ts:214-220) only becomes true when an explicit `--port`/`--hostname`/`--mdns` CLI flag is present. So a TUI launched plainly (or via `--continue`) never binds a discoverable API port — it talks to its server through an in-process fetch handler, and its ephemeral listen sockets serve unrelated things. Verified: `server.port: 7719` in config → nothing on 7719; `--port 7719` on the CLI → 7719 bound and serving `/session/:id` (200 with auth, 401 without).
+
+2. Even WITH `--port` bound and the API correctly reachable, the port isn't discoverable to other processes. Our heartbeat resolves the server URL from the plugin input (`ctx.serverUrl ?? client baseUrl`), but at plugin-init `Server.url` is `undefined` (`packages/opencode/src/plugin/index.ts:141-160`) — the server binds in the TUI worker thread while the plugin reads `Server.url` from the main thread — so the SDK client `baseUrl` falls back to the `http://localhost:4096` placeholder (plugin/index.ts:143,160). Every presence file on disk shows `serverUrl: http://localhost:4096` regardless of the real bound port.
+
+**What we need from you (investigation + proposal, not a blind patch).** Give the TUI a predictable, discoverable bound API port. Any of these directions is fine — pick what fits opencode's architecture; we want your design recommendation:
+- (a) Make the TUI honor `server.port`/`server.hostname` from `opencode.json[c]` (i.e. thread config into the TUI network resolution, not just `serve`), OR
+- (b) Select the port by a predictable scheme (e.g. deterministic per-project/per-directory), OR
+- (c) Have the TUI REGISTER its actually-bound port/URL somewhere discoverable at runtime (so `Server.url` — or an equivalent published record — reflects the real port and is readable by the plugin host at/after init, fixing the thread-boundary staleness).
+
+**Hard constraint — must work on the HOSTED workspace build, not just local TUI.** This has to hold for the hosted openvscode-server / cloudhome workspace deployment of opencode (remote/served mode), not only these local `opencode`/`opencode --continue`/`opencode serve` modes. Whatever mechanism you choose for port selection/registration must be reachable in the hosted topology (where the server may be fronted by a proxy and the "port" a client should probe may differ from the raw bind). Please account for that explicitly.
+
+**Deliverable requested:** a short investigation write-up + recommended approach (option a/b/c or a hybrid), the specific files/functions you'd change, and how a peer process would reliably discover the correct base URL to probe in BOTH local and hosted-workspace modes. No code change required yet — we'll review the design first. Reply via mailbox.