For AI agents: the complete documentation index is available at https://scriptedalchemy.github.io/agent-bundle/llms.txt, the full documentation bundle is available at https://scriptedalchemy.github.io/agent-bundle/llms-full.txt, and this page is available as Markdown at https://scriptedalchemy.github.io/agent-bundle/reference/notices.md.
Skip to main content
agent-bundle
  • English

      • Notice delivery matrix

      Generated page

      This page is rendered at documentation build time from the pinned host capability tables amp-0.0.0-20260907001852-gf348fed.json, claude-2.1.260.json, codex-0.147.0.json, cursor-2026-08-28.json, portable-1.0.0.json. Those JSON files are the source of truth every target adapter compiles against; change them, not this page.

      A notice is an entry in the journal-backed notice ledger co-mounted with project state (the reserved store id @agent-bundle/runtime/agent-notice-ledger/v1). It targets a recipient and moves only through evidenced states — pending, attempted, acknowledged, expired, unavailable, withdrawn; settled terminal notices are pruned and the journal compacted under the project's notices.retention policy, so history is bounded, not permanent. Delivery is attempted through the channels below, and a generated MCP server wires each cross-request route only where its host advertises it: the recipient-scoped inbox resource agent-bundle://notices/inbox is registered for stateful projects on hosts advertising mcp-inbox (every built-in host), and resources/subscribe plus one notifications/resources/updated per newly eligible pending notice is offered only where the host additionally advertises mcp-resource-updated and the state lifetime is workspace-durable — recorded on the ledger as an availability receipt, never a delivery claim. No host delivery is claimed without a supported channel.

      Recipient axes

      A recipient is the conjunction of the observed identity axes it names: every axis present must match the admitting request, and an axis the request cannot observe never matches. conversation and root are read from the request's lineage, so they address one agent thread — or every thread under one root — where session cannot: on Claude and Codex every subagent's hooks carry the root session_id, and a conversation-addressed notice is never admitted on a sibling's event. There is no push channel on any pinned host, so addressing a conversation still means publish plus admission on that conversation's next event.

      AxisMatched againstReaches
      actorrequest.actor.idThe HTTP-authenticated MCP client only; never mounted in event scopes.
      hostrequest.host.nameEvery request on that host.
      sessionrequest.session.sessionIdEvery request in that host session — on Claude and Codex, every subagent under the root.
      workspacerequest.workspace.rootEvery request whose observed workspace root (hook cwd) is that directory.
      conversationrequest.lineage.conversationExactly one agent thread: the root, or one subagent (Claude/Codex agent_id, Cursor child conversation_id).
      rootrequest.lineage.rootThe root conversation and every subagent whose lineage root it is — the publisher included when it is under that root.

      Publisher view

      A recipient never sees another recipient's notices, and a publisher does not see a recipient view either. What a publisher gets is notices.published(): the notices its own principal published, in every state, with their receipts. publish() records the publishing request's observed axes on the notice (publisher: actor, host, session, workspace, and conversation from request.lineage); a reader is the publisher when it resolves the same lineage conversation — so the hook that published and the MCP tool call that asks agree even though host name, session id, and cwd differ — or, for a publisher recorded without lineage, when every recorded axis matches. The view records nothing on the ledger, is judged per notice under authorization phase published, and discloses content under the default internal ceiling (internal secret-passed, public as authored, secret as the placeholder). A notice published by a request that observed no identity belongs to no view.

      Delivery channels

      Channelamp 0.0.1788739286-gf348feclaude 2.1.260codex 0.147.0cursor 2026-08-28portable 1.0.0
      current-response—supportedsupportedsupportedunavailable
      directed-push—unavailableunavailableunavailableunavailable
      host-toast—unavailableunavailableunavailableunavailable
      mcp-inbox—supportedsupportedsupportedsupported
      mcp-resource-updated—supportedsupportedsupportedsupported
      next-event—supportedsupportedsupportedunavailable

      Sensitivity ceilings

      Every notice carries an author-declared sensitivity — public, internal (the default), or secret. A supported channel names the most sensitive class it carries in full, with the dated evidence for that ceiling; a channel without a named ceiling admits internal. A notice above a channel's ceiling is withheld from that channel and the refusal is recorded on the notice; internal content is passed through the runtime's secret pass (flare-redact, an exact-pinned dependency of @agent-bundle/runtime; every finding is replaced whole by [REDACTED]) before it leaves the store, public content travels as authored, and secret content travels as authored only where a channel admits it.

      Channelamp 0.0.1788739286-gf348feclaude 2.1.260codex 0.147.0cursor 2026-08-28portable 1.0.0
      current-response—secretsecretsecret—
      directed-push—————
      host-toast—————
      mcp-inbox—internalinternalinternalinternal
      mcp-resource-updated—internalinternalinternalinternal
      next-event—secretsecretsecret—

      Ceiling evidence

      ChannelHostsReason
      current-responseclaude2026-09-03 (#99 close-out): the hook response is returned to the same Claude Code process that ran the recipient's hook (https://code.claude.com/docs/en/hooks, retrieved 2026-09-02), the trust boundary the recipient already holds; no third party observes it, so a secret notice may travel in full.
      current-responsecodex2026-09-03 (#99 close-out): the hook response is returned to the same Codex process that ran the recipient's hook (rust-v0.147.0 generated hook schemas), the trust boundary the recipient already holds; no third party observes it, so a secret notice may travel in full.
      current-responsecursor2026-09-03 (#99 close-out): the hook response is returned to the same Cursor process that ran the recipient's hook (hooks reference retrieved 2026-08-28), the trust boundary the recipient already holds; no third party observes it, so a secret notice may travel in full.
      mcp-inboxclaude, codex, cursor, portable2026-09-03 (#99 close-out): inbox identity is derived from the MCP transport only (authInfo clientId / transport sessionId), which this pinned host does not authenticate to the plugin, and a bare stdio inbox is honestly empty; secret content is withheld and internal content is secret-passed before the resource is served.
      mcp-resource-updatedclaude, codex, cursor, portable2026-09-03 (#99 close-out): notifications/resources/updated carries only the inbox URI (MCP 2025-11-25 server/resources, retrieved 2026-09-02) and is sent only for notices the inbox route may itself disclose, so it can never leak content above the inbox ceiling.
      next-eventclaude2026-09-03 (#99 close-out): the hook response is returned to the same Claude Code process that ran the recipient's hook (https://code.claude.com/docs/en/hooks, retrieved 2026-09-02), the trust boundary the recipient already holds; no third party observes it, so a secret notice may travel in full.
      next-eventcodex2026-09-03 (#99 close-out): the hook response is returned to the same Codex process that ran the recipient's hook (rust-v0.147.0 generated hook schemas), the trust boundary the recipient already holds; no third party observes it, so a secret notice may travel in full.
      next-eventcursor2026-09-03 (#99 close-out): the hook response is returned to the same Cursor process that ran the recipient's hook (hooks reference retrieved 2026-08-28), the trust boundary the recipient already holds; no third party observes it, so a secret notice may travel in full.

      Why a channel is unavailable

      ChannelHostsReason
      current-responseportable2026-09-02: Agent Plugins 1.0.0 defines no hooks, so there is no synchronous hook response surface (https://agent-plugins.org/).
      directed-pushclaude, codex, cursor, portableretrieved 2026-09-02 (#99 survey): no documented plugin-initiated directed cross-actor message API at this pin; the Claude Notification hook observes host-emitted notifications and does not send them.
      host-toastclaude, codex, cursor, portableretrieved 2026-09-02 (#99 survey): no documented plugin-facing toast/notification send API at this pin.
      next-eventportable2026-09-02: Agent Plugins 1.0.0 defines no hooks, so no event admission surface exists (https://agent-plugins.org/).