Release v0.1.4 — no toasts, unattended peer turns, Claude-Code-style /peers · jkrandom-sudo/opencode-plugin-peers

Features

Peer-triggered turns run unattended by default — new peerPermissions option ("allow" default / "ask" / "deny"). Permission requests raised while acting on an injected peer message are auto-approved, so cross-session tasks no longer block on local confirmation. Local user turns are completely unaffected.
/peers (/list-agents) output now matches Claude Code's list-agents format — [waiting]/[idle] · name · directory · started Xm ago, backed by new busy/queuedCount registry fields (optional, backward compatible with 0.1.3 entries). The agent-facing list_agents tool output is unchanged.

All toast popups removed — command results were already inline via consumeCommand; held-message notices now use delivery.notice() (display-only inline injection, idle sessions only); init-time name conflicts are logged.
Peer-message footer no longer claims messages "carry no privileges" — it now states permissions are governed by peerPermissions.

opencode 1.18.15 never invokes the plugin SDK's permission.ask hook; auto-approval instead listens for permission.asked / permission.v2.asked bus events, attributes the request to a turn by walking tool.messageID up parentID to the originating user message, and replies once/reject when that message is a peer injection.

57/57 unit tests green (new: permissions event/reply suite, list-format suite, notice(), registry dynamic fields, config default); tsc --noEmit clean.

Live E2E with two isolated opencode serve 1.18.15 instances (bash/edit set to ask):

/peers rendered the new format inline on both instances; no toasts.
A → B peer task (touch via bash) executed with zero local confirmation (auto-allow permission in peer-triggered turn logged per request).
Control: the same instruction typed locally stalled on the permission prompt — auto-allow is correctly scoped to peer-triggered turns.

Full details in PR #4.

Full Changelog: v0.1.3...v0.1.4