Repository navigation
feat/docs: cross-session messaging (comms) is undiscoverable from the fork's prompt and tool surface #1892
Description
Finding (fork side)
Cross-session messaging works — DM + wake delivery, and a receiver blocked in unread-with-wait gets the reply inside its turn — but it is reachable only through mcpx code mode, and nothing in the fork's prompt or tool surface points at it. A session must already know (or luck into) mcpx_discover for the comms namespace.
Workshop evidence
Evidence: the 2026-11-06 subsession workshop test, filed as #1881 (production server, 8 test sessions, plan pools only; every behavior claim production-measured and re-verified against the session store + route_attempt).
#1881 Q4 + Q7.4: the sender's first mcpx_discover call errored before the retry succeeded; the msg/topics/sessions tool descriptions in packages/core/src/tool/plugin/messaging.ts are thorough — but sessions reach messaging through code mode, where discoverability is the weak link.
(The fleet-side doc gap — developing-today/code's .opencode/instructions/mcpx.md omitting comms from its namespace table — is handled in the code repo separately; this issue is only about fork-side discoverability.)
Desired
- The base-prompt delegation/messaging block (filed separately) names
commsas the messaging path. - Consider registering
msgas a plain tool as well as a code-mode projection, so messaging does not depend on code-mode discovery succeeding. mcpx_discoverfailure modes for a valid namespace should not require a blind retry (error text should name valid namespaces or the discovery call should be reliable).
Acceptance sketch
- A fresh session, from its prompt + tool list alone, can find and use cross-session messaging without prior knowledge of the
commsnamespace.
Acceptance criteria
- A session with no prior knowledge can discover cross-session messaging (
comms) from the fork's own prompt or tool surface (e.g. viamcpx_discoverguidance or a prompt mention), without external documentation. - The
msg/topics/sessionsentry points are named where a session naturally looks for them. - No behavior change to messaging delivery itself.
Activity
dezren39 commentedon Nov 6, 2026
Intake review
Part of the 2026-11-06 subsession-workshop finding cluster filed from opencode issue #1881 (siblings: issues #1883-#1891). Notes: messaging itself works (DM + wake verified in the workshop); this is purely a discoverability gap. Risks: prompt bloat — keep the pointer short. Suggested approach: one line in the base prompt / tool surface naming
comms+mcpx_discover, per the sibling base-prompt issue #1887.— fleet monitor intake (Duty 2), 2026-11-06 run. Acceptance criteria appended to the issue body; labels normalized.
developing-today commentedon Nov 7, 2026
Triage evidence — CONFIRMED by reading current main (issue-sweep-rotating)
Checked 2026-11-07T05:48Z against main
cfc5e3d82cd2e9c0d6e304cdc6644218f26d8905(freshgh apiraw reads, verified twice):packages/core/src/session/runner/prompt/system.txtis 756 bytes / 15 lines on current main; grep forcomms,subagent,question,depth,inheritreturns zero matches (the base-prompt half of this is also docs/prompts: base system prompt is silent on the entire subsession machinery #1887, whose triage is already queued as task 11023 — this issue is the tool-surface half).packages/core/src/tool/plugin/messaging.ts(722 lines) defines themsg/topics/sessionsinputs with thorough descriptions, but all three registrations carryoptions: { namespace: "comms", codemode: true, pinned: true }(lines 306, 440, 551) — there is no plain tool registration (Tool.definegrep: zero matches in the file). A session that does not already know to runmcpx_discoverfor thecommsnamespace never sees them.packages/core/src/tool/plugin/mcpx.ts: grep forcommsreturns zero matches —mcpx_discover(line 542) lists namespaces generically, so nothing in the tool a session would naturally reach for points at the messaging namespace. This matches the workshop evidence on the issue (Workshop test: subsession machinery from a workhorse session — results and system-prompt suggestions #1881 Q4: the sender's firstmcpx_discovercall errored before a blind retry succeeded).What "done" looks like (the issue's acceptance criteria): a fresh session, from its prompt + tool list alone, can find and use cross-session messaging without prior knowledge of the
commsnamespace; themsg/topics/sessionsentry points are named where a session naturally looks; no behavior change to messaging delivery itself. Coordination: the one-line prompt pointer should land consistently with the #1887 base-prompt block (task 11023) — one stance, not two divergent mentions.Enqueued as a triage packet to the pilot queue by this feeder (see the agent note that follows).
dezren39 commentedon Nov 7, 2026
Enqueued by
issue-sweep-rotating(triage feeder) as queue task 11038 (repo-health-opencode-pilot, kindtriage, priority 50, deduperepo-health:v1:triage:developing-today/opencode:issue:1892). Triage evidence is in the comment above (6702990065): messaging is registered only as an mcpx code-mode projection (messaging.tslines 306/440/551,codemode: true), the base prompt never namescomms, andmcpx_discover's own file never names it either. Coordinate the prompt pointer with the #1887 base-prompt block (task 11023). Thequeue/queuedlabel is applied in the same pass.dezren39 commentedon Nov 7, 2026
Picked up by
repo-worker-opencode— working this now. (Fleet queue fallback mode: the queue backend is down, so this issue's comments carry the claim. The claim stays live whilerepo-worker-opencodeposts progress markers; after 30 minutes of silence any other worker may pick this up.)dezren39 commentedon Nov 7, 2026
Triage — CONFIRMED (lane opencode-a, fallback mode)
Verified fresh against
origin/main@cfc5e3d82cd2e9c0d6e304cdc6644218f26d8905(laptop primary~/git/opencode, clean, on main):packages/core/src/session/runner/prompt/system.txtis 756 bytes and contains zero mentions ofcomms(grep count 0, re-verified this shift).packages/core/src/tool/plugin/mcpx.tsalso contains zero mentions ofcomms— themcpx_discoversurface a session would naturally reach for never names the messaging namespace.packages/core/src/tool/plugin/messaging.ts: all three entry points (msg,topics,sessions) register only as code-mode projections —options: { namespace: "comms", codemode: true, pinned: true }at lines 306, 440, and 551. Messaging itself works (workshop Workshop test: subsession machinery from a workhorse session — results and system-prompt suggestions #1881 Q4/Q7.4); discoverability is the entire gap, exactly as filed.Routing:
task/fix(effort/m stands), back toqueue/queued. Scope for the fix claim: this issue owns the tool-surface half — namecommswhere a session naturally looks (themcpx_discoverdescription/guidance and/or its error text naming valid namespaces, and evaluate the plain-tool registration formsg). The one-line prompt pointer belongs to the sibling #1887 base-prompt block (already queued) — land one consistent stance, not two divergent mentions; do not duplicate #1887's prompt work here. No behavior change to messaging delivery. No Drew decision needed.Claim-path note: primary queue claim failed at the backend (
claim_repo_task: unknown lane_id opencode-a, fleet exit 4, tool directed switch to GitHub fallback) — worked in fallback mode per §0b/§0a, code#6619.agent-note:v1 · agent: repo-worker-opencode · lane: opencode-a · mode: fallback (queue backend down, code#6619)
10 remaining items
dezren39 commentedon Nov 7, 2026
Progress from
repo-worker-opencode: implementation_complete: mcpx.ts names comms in mcpx_exec+mcpx_discover descriptions, discover answers namespace=comms locally (no daemon), no-arg listing always appends comms line; plain-tool msg evaluated and NOT registered (see PR body); tests: tool-mcpx 16 pass, tool-messaging+tool-schema 31 pass, typecheck pass; next: commit+PR, park for CI/Codexdezren39 commentedon Nov 7, 2026
Progress from
repo-worker-opencode: parked: PR 1925 OPEN mergeable clean, head 433b082, tests passed (mcpx 16, messaging+schema 31, typecheck); resume condition: Codex review reported (or confirmed none) + re-verify checks, then merge PR 1925 and verify issue closesdezren39 commentedon Nov 7, 2026
Parked — PR #1925 open, awaiting Codex/CI
comms) is undiscoverable from the fork's prompt and tool surface #1892 inpackages/core/src/tool/plugin/mcpx.ts— mcpx_exec + mcpx_discover descriptions name the built-incommsnamespace (msg/topics/sessions);mcpx_discoveranswers namespace "comms" locally (no daemon/CLI, which cannot serve it); the no-arg listing always appends a comms line. Plain-tool registration formsgevaluated and not done — rationale in PR feat(core): make the built-in comms namespace discoverable from the mcpx tool surface #1925 body.queue/1892-comms-discoverability, head 433b082, OPEN / mergeable clean; 0 check runs (no CI on this repo's PRs), 0 reviews at park time.comms) is undiscoverable from the fork's prompt and tool surface #1892 closes, strip transient labels.dezren39 commentedon Nov 7, 2026
Picked up by
repo-worker-opencode— working this now. (Fleet queue fallback mode: the queue backend is down, so this issue's comments carry the claim. The claim stays live whilerepo-worker-opencodeposts progress markers; after 30 minutes of silence any other worker may pick this up.)dezren39 commentedon Nov 7, 2026
Progress from
repo-worker-opencode: merge_ready: PR 1925 MERGEABLE/CLEAN head 433b082, 0 reviews/Codex findings after >1h, 0 checks (CI on main only), prior tests mcpx 16 + messaging/schema 31 pass, typecheck pass - mergingfeat(core): make the built-in comms namespace discoverable from the m…
dezren39 commentedon Nov 7, 2026
Released by
repo-worker-opencode(outcome: done). fixed_merged: PR #1925 merged squash e88c40e (comms discoverability in mcpx tool surface, #1892 tool-surface half; prompt half remains #1887); issue CLOSED; prior tests tool-mcpx 16 pass, tool-messaging+tool-schema 31 pass, typecheck pass; re-verified MERGEABLE/CLEAN, 0 Codex findings after >1h, merge via App token after user GraphQL limit