@agentcomms/resend

中文文档
0.37.0发布于 2026/10/29MITTypeScriptES Module构建来源已验证近 30 天下载 4663

Resend for coding agents: read domains, sent and received mail, metrics and suppressions, and send mail that nothing sends without a person's approval of exactly what goes out.

原始使用文档
文档目录5 节
  1. What it promises, and who enforces it
  2. Taking messages
  3. Getting started
  4. Accounts
  5. Commands and tools

@agentcomms/resend

Resend for coding agents. Read a team's domains, sent and received mail, metrics and suppressions — and send email that nothing sends without a person's approval of exactly what goes out, once.

npm install -g @agentcomms/resend    # or run it with npx @agentcomms/resend <command>

New in 0.7.0.

The local event daemon, @agentcomms/events-daemon, may call this package's internal read-only event operation. It adds no Resend command or MCP tool, and it cannot send.

What it promises, and who enforces it

Read-only is enforced by this package, not by the key. Resend has no read-only API key. A full-access key can read, send, delete domains and create keys; an account in read mode is kept from sending by this package's own code, but the key itself would not stop anything else that held it. A sending-only key can only send — Resend enforces that — and it cannot read anything, so reads with it are reported as unavailable. agent-resend doctor says this on every run.

Nothing is sent without a person. A send is prepared, previewed — every recipient, BCC included, the reach (unique recipients), the From domain and whether it is verified — and approved: a yes in the conversation under the account's chat policy, or the approve command the result gives and a typed code under confirm — which the agent learns of with resend_send_wait. Above ten recipients, or to an address that arrived in mail read here, a person at a terminal approves, whatever the policy. The approval id is the request's Idempotency-Key and an agentcomms_approval tag; a send whose outcome is unknown (SEND_OUTCOME_UNKNOWN) is never repeated, only checked, and a scheduled one is "accepted", never "sent", until Resend's own last event for it says so.

An agent's email says so in its From. Prepare labels it "Acme (agent)" <[email protected]>: the name the From gave, or, for a bare address, the label name the person set in the core (its CLI's label name, or comms_label), then their word — agent unless they chose another (design, §6). With neither name, or a label over Resend's 100 characters, prepare refuses. --as me (as: "me" on resend_send_prepare) sends the From exactly as given, for when the person said so for that email; their label rules decide otherwise, and with none an email is labelled. The preview's first line says which, and the approval binds the whole From.

The key is typed by a person, at a terminal. agent-resend account add reads it from a hidden prompt, or from RESEND_API_KEY in that terminal, and stores it in the system keychain. No MCP tool accepts a key: a key typed into a chat stays in the transcript.

Received mail is untrusted. Bodies, subjects, names and attachment names arrive inside the untrusted-content envelope with hidden text removed and counted, beside Resend's own SPF, DKIM and DMARC results. Attachments are listed, and downloaded only when asked, into the downloads folder.

It stays out of the way of the team's own mail. Resend's rate limit is shared by every key of a team, and Resend does not say which team a key belongs to, so this package asks at most twice a second from a computer in all, whichever account asks, and a 429 through any account stops every account until Resend says it may ask again.

It never manages domains, API keys, webhooks, broadcasts, contacts or audiences, from any surface.

Taking messages

When several agent sessions read the same received email, the first to take it has it, and the others leave it (design). resend_take (or agent-resend take <email>) reads the email from Resend first — one this account did not receive, or one it sent, cannot be taken — and keeps only its id and its Message-ID. A session that finds it is not its own hands it back (step: "hand-back", or --hand-back, with a reason: not-mine, wrong-account, needs-the-person, duplicate or other), and may mark one done (step: "done", --done). resend_taken (agent-resend taken [<email>…]) says who has each: you, another session or the person — never which session, folder or app — and the received list and one received email carry the same as taken.

  • A reply needs the take of the email it answers. A send with an In-Reply-To answers the received email with that Message-ID. Another session's take refuses it with TAKEN_ELSEWHERE (exit 10), whatever the setting; when the person turned taking on for the account (core's agentcomms taking acme/resend --require on, or comms_taking), a session that has not taken it is refused with TAKE_REQUIRED (exit 10). Both are asked at prepare, before any preview or approval, and again before the send — so a take released in between sends nothing. A new email, with no In-Reply-To, answers nobody and is not held to it. When several received emails carry that Message-ID — the sender writes it, so a forged copy can carry another's — the reply answers each, and is refused while another session has any of them.
  • An In-Reply-To nobody has taken, with taking on, is refused too: Resend cannot be asked which received email has a given Message-ID, so one naming the account's own earlier email cannot be told apart. Leave In-Reply-To out for a follow-up to your own mail, or let the person send it.
  • Who a session is is worked out by the server or the command from its own process, never passed in. The person at their own terminal is never held to taking: they keep an email with core's agentcomms takes keep, and end or move a session's take with agentcomms takes release or agentcomms takes give.
  • A speed bump, not a boundary. It keeps two sessions from answering one email; the send gate, the behaviour rules and the person's approval still decide what is sent. Every process here runs as the person.

Getting started

A person connects an account at their own terminal, then registers the server with their agent:

npx -y @agentcomms/resend account add acme/resend               # type the key when asked; read mode by default
npx -y @agentcomms/resend mcp install --client claude-code      # a registration you approve

--client also takes codex, cursor, gemini, claude-desktop, vscode and json. Add --account acme/resend to pin the server to one account. From a chat with the core server connected, comms_server_install with channel: "resend" makes the same registration, and either one's approval is good for the other.

agent-resend doctor
agent-resend domains --account acme/resend
agent-resend received list --account acme/resend
agent-resend account policy acme/resend --mode send   # a change a person approves
agent-resend send prepare --account acme/resend --from "Acme <[email protected]>" --to [email protected] \
  --subject "Hello" --text "Hi Sam"

Accounts

An account is one Resend API key for one team, named organisation/resend. It lives in the one agent-communications configuration beside every mailbox and workspace, so agentcomms names migrate, agentcomms secrets migrate and agentcomms policy --account <name> treat it like any other; its key is in the one secret store under resend:key:<id>.

Its mode is read or send. Moving it to send, loosening its send policy (chat, confirm, never) or its change policy (chat, confirm), and removing it are change approvals: a preview, and nothing until a person agrees — in the conversation under the chat change policy, at their own terminal under confirm. Tightening applies at once.

Commands and tools

Every command has an MCP tool running the same operation, except three: account add (a key is typed at a terminal), approve (under confirm, a person at a terminal) and mcp (it starts the server).

CommandMCP tool
agent-resend account add <name>— typed at a terminal
agent-resend account listresend_accounts_list
agent-resend account show <name>resend_account_show
agent-resend account policy <name>resend_account_policy
agent-resend account remove <name>resend_account_remove
agent-resend doctorresend_doctor
agent-resend domainsresend_domains
agent-resend emails listresend_emails_list
agent-resend emails show <id>resend_email_show
agent-resend received listresend_received_list
agent-resend received show <id>resend_received_show
agent-resend received download <id>resend_received_download
agent-resend take <email>resend_take
agent-resend taken [<email>…]resend_taken
agent-resend metricsresend_metrics
agent-resend suppressionsresend_suppressions
agent-resend send prepareresend_send_prepare
agent-resend send execute <approvalId>resend_send_execute
agent-resend send status <approvalId>resend_send_status
agent-resend send wait <approvalId>resend_send_wait
agent-resend scheduled listresend_scheduled_list
agent-resend scheduled cancel <id>resend_scheduled_cancel
agent-resend approve <approvalId>— a person at a terminal, with the command the result gives
agent-resend mcp— it starts the server
agent-resend mcp install --client <client>comms_connection_change with add and app (core): Resend into the app's connection
agent-resend mcp install --client <client> --standalonecomms_server_install (core): an entry of its own
agent-resend mcp prunecomms_server_prune (core)

Every command that reads or changes an account — all but account, doctor, send wait, approve and mcp — is recorded in core's private activity log, the same from a command and a tool: the email ids, subjects and senders it touched, a download's file names and sizes, a send's recipients and approval, and how it ended. Never a body or an attachment's bytes. agentcomms activity sessions shows it, and agentcomms activity record off stops it.

Every command takes --json for the whole result, with stable exit codes: 0 ok, 10 a send or a change was refused or needs approval, 64 usage, 65 bad data, 66 not found, 69 Resend or the secret store unavailable, 75 temporary, 77 key or permission needed, 78 configuration problem.

The skills resend-reading and resend-sending teach an agent to use them. Everything else — the other channels, the design and the reference pages for every command and tool — is in the repository.

版本与发布记录

@agentcomms/resend 共发布 45 个版本,首次发布于 2026/09/27;过去 12 个月发布了 45 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
0.37.0latest2026/10/299 天前
0.36.02026/10/2810 天前
0.35.02026/10/2811 天前
0.34.02026/10/2711 天前
0.33.02026/10/2712 天前
0.32.02026/10/2612 天前

关于 @agentcomms/resend 的常见问题

@agentcomms/resend 是什么?

Resend for coding agents: read domains, sent and received mail, metrics and suppressions, and send mail that nothing sends without a person's approval of exactly what goes out.

如何安装 @agentcomms/resend?

在项目目录运行 npm install @agentcomms/resend,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 agent-resend,可以用 npx agent-resend 直接运行。

@agentcomms/resend 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@agentcomms/resend 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@agentcomms/resend 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=22.12.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@agentcomms/resend 可以商用吗?

@agentcomms/resend 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@agentcomms/resend 的下载量有多少?

根据 npm 官方下载统计,@agentcomms/resend 在 2026/10/05 – 2026/11/03 这 30 天内被下载 4,663 次,日均约 155 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@agentcomms/resend 还在维护吗?

最新版本 0.37.0 发布于 2026/10/29(9 天前);至今共发布 45 个版本,其中过去 12 个月发布了 45 个;首次发布于 2026/09/27。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。