Introduce a capability-negotiated Coven launch adapter without persisting prompts

[BunsDev]

Outcome

Route Psyche Build provider launches through Coven as a bounded, compatibility-negotiated product adapter without exposing composer prompts in process arguments, persisted pane launch metadata, or unsupported provider choices.

Control metadata

• Accountable owner: @BunsDev
• Parent outcome: Converge Psyche Build on protocol-owned identity and Psyche orchestration #201 — OpenCoven identity and Threads convergence
• Related product control: Maintain the authoritative Psyche Build roadmap and post-release control state #195
• Current implementation candidate: Route desktop agent launches through Coven #277
• Priority: P2 convergence; must not block Close the v0.0.1 runtime acceptance and stabilization baseline #196, Harden Psyche Build operations, diagnostics, and recovery #199, or Deliver the Psyche Build iOS internal beta and continuity loop #200
• Canonical runtime owner: OpenCoven/coven
• Product adapter owner: OpenCoven/psyche-build

Current gap

PR #277 replaces direct Codex, Claude, Copilot, and Grok launches with coven run <provider> -- <prompt>. That establishes the desired runtime direction, but the current slice also:

• places the full composer prompt in thread.launch.args, which is retained in the in-memory/persisted launch model and exposed through process argv;
• makes every provider launch depend on any discovered coven executable without negotiating a compatible CLI/profile version;
• renders provider options without querying Coven's installed/available adapter capabilities;
• treats PTY creation as launch success even when Coven may immediately reject an unavailable harness or incompatible command;
• removes the direct-provider path without an explicit migration, fallback, or rollback contract;
• includes unrelated Git-inspection test hardening in the same PR.

Required design

• Define the product-to-Coven launch contract and immutable compatibility/canary version.
• Add a machine-readable Coven capability query for supported harness IDs and launch features.
• Show only capabilities confirmed by the selected Coven executable/profile.
• Transport prompts through a bounded private channel that does not place raw prompt text in process argv or durable pane launch metadata.
• Persist only a prompt reference/digest and canonical Coven session identity where needed for recovery.
• Distinguish spawned, accepted, running, terminal failure, and recovery_required; PTY creation alone is not execution acceptance.
• Preserve project/worktree scope and canonical runtime receipts.
• Define behavior when Coven is missing, too old, unavailable, revoked, or lacks the requested adapter.
• Define a reversible migration from direct provider launch behavior.
• Split unrelated Git-inspection test changes into their own focused PR.

Authority boundary

Psyche Build selects a project/worktree and requests a launch. Coven owns runtime/session execution and adapter capability. Neither executable discovery, UI selection, tmux/PTY identity, nor a provider-local session ID proves protocol identity or authority. This issue does not claim Psyche conformance; the immutable protocol profile remains gated by #253 and upstream Psyche publication/ownership decisions.

Acceptance criteria

• No raw composer prompt appears in thread.launch.args, persisted workspace/session metadata, process listings, diagnostics, or support bundles.
• A pinned compatibility test proves Psyche Build against the exact Coven launch profile it consumes.
• Unsupported or incompatible providers are absent or explicitly unavailable before prompt submission.
• An immediately rejected launch does not clear the composer or report success.
• Restart/reconnect can recover the canonical Coven session without replaying the prompt.
• Missing/revoked runtime authority fails closed with actionable recovery.
• Focused exact-head CI and current review findings are complete before merge.

Non-goals

• Making Psyche Build the runtime authority.
• Reimplementing Coven's adapter registry.
• Treating executable presence as compatibility.
• Keeping prompts in argv merely because the interactive CLI supports positional prompt text.
• Blocking current stabilization, diagnostics, or iOS delivery on this P2 convergence slice.

Evidence

Link the approved design, Coven capability/profile artifact, focused implementation PRs, prompt-leak regression tests, exact-head CI, rollback proof, and a live reference launch with canonical Coven session/receipt identity.

[BunsDev]

PR #324 merged as 1642ab52dc74bd473613f537b9f16d516c221401 from exact reviewed head 3c3880b2fd1ae6517ca05a84b93e925645c25306. The focused product adapter now negotiates the pinned Coven daemon profile and installed harness capabilities, transports prompts only in the bounded daemon request body, persists canonical session identity before local attachment, quarantines accepted/effect-unknown outcomes, and serializes accepted-session conversion against concurrent pane or project closure so a late response cannot leave an untracked native attachment.

Evidence: 156 focused launch/adapter/persistence tests, test typechecking, deterministic bundle regeneration, resolved review threads, exact-head required CI, and final independent R3 review with no findings.

#279 remains open for live restart/reconnect recovery, canonical runtime receipt, migration/rollback, and reference-launch evidence; the merge does not claim Psyche protocol conformance.

[BunsDev]

Post-merge authority/recovery follow-up #328 merged as 0917ecbd2152e3c5e51437957176ed4d802e08d1 from exact reviewed head e68964a2f337ddcf10ac5fb1b37b71ba51e018ff. It closes the remaining launch/revocation and teardown/reopen TOCTOUs, gates every persistent native session creation path, preserves accepted-but-unattached recovery evidence, and durably rolls back project/thread/pane/focus-set state when persistence or native revocation fails. Evidence includes the complete 5,276-test repository suite (11 skipped), 87 serialized focused Rust Coven tests, four native authority lifecycle tests, desktop bundle regeneration, source/test typechecks, the pinned fast gate, terminal cross-platform exact-head CI, and independent R3 review with no findings.\n\n#279 remains open: live restart/reconnect recovery, canonical runtime receipt, migration/rollback observation, and reference-launch evidence are still required. Neither #324 nor #328 claims Psyche protocol conformance.

[BunsDev]

Live Coven profile verification — first pass against a real daemon

Verification pass at main @ 9f06de0d (after #324 and #328) against a live Coven daemon: pid 40747, socket ~/.coven/coven.sock, coven v0.4.1 (engine coven-code 0.7.0). Every test cited in those two merges runs against mocked daemon responses, so the acceptance criterion "a pinned compatibility test proves Psyche Build against the exact Coven launch profile it consumes" had not yet been exercised against the actual runtime.

Read-only apart from one deliberately-invalid POST chosen because it cannot create a session. All findings below were re-verified immediately before posting.

Verified live

• Pinned API version. GET /api/v1/health returns apiVersion: "coven.daemon.v1", matching STABLE_API_VERSION (coven_sessions.rs:41) exactly. Negotiation succeeds against the real runtime.
• Capability query. coven adapter list --json returns 7 entries; all 7 satisfy parse_adapter_list. The live payload also carries executable, install_hint, and capabilities, all ignored by the parser — confirming the documented additive-compatibility claim against real output rather than a fixture.
• Rejection path. A POST with an unsupported harness returns HTTP 400 with body {"error":{"code":"invalid_request","message":"…"}} — exactly the shape bounded_daemon_error_message parses via error.message. The newest session id was identical before and after, so no session row was created. covenLaunchOutcome maps this to failed, not accepted, so the composer is not cleared. Acceptance criterion 4 verified against the real runtime.
• Success-branch shape. Live session records carry both id and harness (the two fields parse_launch_record requires) and the handler returns 201, inside the adapter's accepted 200..=299 range.

The prompt-transport defence is load-bearing, not theoretical

The comment at coven_sessions.rs:540 says the title "deliberately never defaults to the prompt." That is factually correct about the canonical runtime — crates/coven-cli/src/api.rs:3583:

let title = payload.get("title").and_then(Value::as_str)
    .filter(|title| !title.trim().is_empty())
    .unwrap_or(&prompt)          // omitted title BECOMES the prompt

This leak is live right now. Of 40 sessions sampled from the running daemon, 33 have prompt-shaped titles (>45 chars), including one claude session whose title begins ## Prior conversation\n\n**Assistant:** The board … — a conversation transcript sitting in a session title, readable from coven sessions.

Those came from coven run, not Psyche. Because Psyche always sends title: entry.label (a fixed provider label), Psyche-launched sessions cannot leak this way. Acceptance criterion 1 is genuinely satisfied, and it mitigates an observed, live failure mode rather than a hypothetical one.

New finding: the capability source disagrees with launch authority

coven adapter list --json advertises 7 harnesses, all available: true. The daemon's validate_harness → configured_harness_specs() accepts only 5. The daemon says so itself in the 400 body:

Configured harnesses: codex, claude, coven-code, copilot, grok. Known installable adapter recipes: grok, hermes, opencode.

So hermes and opencode advertise available: true in the capability query but would be rejected with 400 at launch. covenLaunchGate (main.js:15209) checks capability.available but does not consider source, so a source: "manifest" recipe passes the gate.

Not currently exploitable — the picker offers a hardcoded 5 entries (main.js:15049-15081) that happen to equal the daemon's configured set, so hermes/opencode are unreachable.

Why it still matters here. The capability query answers from the CLI's recipe catalog, not the daemon's launch authority, and the two disagree by two entries. The safety property is currently supplied by a coincidence between two independently-maintained hardcoded lists. The moment the picker is driven from adapter list — the obvious next step toward "show only capabilities confirmed by the selected Coven executable/profile" — the criterion "unsupported or incompatible providers are absent or explicitly unavailable before prompt submission" breaks silently, and the user learns only after submitting a prompt.

Suggested fix: expose the daemon's configured set over coven.daemon.v1 and gate on that, rather than re-encoding the assumption in a second hardcoded list.

Minor: the daemon self-reports covenVersion: "0.0.0" while the CLI reports v0.4.1. Psyche does not read it, so there is no impact today, but any future compatibility logic keyed on it would read a meaningless value.

Remaining items

• Canonical runtime receipt — not implemented. No Coven receipt concept exists in the desktop codebase; the only receipt matches are unrelated browser automation (automation_receipt). Per docs/REPOSITORY-MAP.md and AGENTS.md, receipt semantics are owned by OpenCoven/psyche and gated behind Adopt Psyche through a versioned compatibility canary and incremental adapters #253, so this may be blocked upstream rather than merely undone — worth reclassifying.
• Migration / rollback — not implemented. No reversible path back to direct-provider launch; the only migration code is unrelated legacy workspace handling.
• Restart/reconnect recovery — in flight. Canonical session identity is already persisted on main (covenSessionId, main.js:1215), so recovery builds on an existing foundation.
• Reference launch — deliberately not performed. An accepted POST spawns a live harness process; everything short of it is verified above.

To complete criterion 1's direct live proof, after a real accepted launch:

ps -eo command | grep -c 'reference launch probe'   # expect 0

Nothing here claims Psyche protocol conformance.

[BunsDev]

Tracking update — 2026-09-02

Follow-up PR #336 merged as 7018ce53 from exact head a4c44f6e0c564b4ab1c328516b2453aad81f424b, linearizing project removal, workspace persistence, native session creation, and root revocation/reopen transactions and reconciling Rust-owned startup project authority to the restored UI project set (5,103-test suite, 193 focused Coven/pane tests, independent R3 review with no findings).

Reclassification from the live-daemon verification above, now recorded in PR #343:

• Canonical runtime receipt is gated on the Adopt Psyche through a versioned compatibility canary and incremental adapters #253 protocol pin (OpenCoven/psyche#11/#12), not merely undone here; it is not to be invented locally.
• Capability source vs. launch authority: the CLI adapter catalog can advertise harnesses the daemon rejects. Before the picker is driven from adapter list, gate on the daemon's configured set; this is a required design item, not a current exploit.
• Still open for closure: live restart/reconnect recovery, migration/rollback observation, and one reference launch with the ps prompt-absence probe.

#279 stays P2 and non-blocking for #196, #199, and #200.

[BunsDev]

Removed the stale v0.0.1 macOS milestone under the macOS-first rollout decision in #454, merge c4fb84b. This remains an open, deferred P2 Coven-adapter outcome; live recovery, canonical receipt/profile, and rollback gates are unchanged. It is not a prerequisite for the macOS operator-acceptance rollout, and milestone cleanup does not claim implementation completion or protocol conformance.