Spike: one `bench mail` command as the verb surface, so any runtime can send without an integration

[Wirasm]

Spike: one bench mail command as the mailbox's verb surface, so any runtime can send and read without an integration of its own. Prove it, measure what it costs, and decide whether the hooks and the pi extension should keep sending or become sensors only.

The operator's proposal, in his words

we can add a bench mail command to helm, that would remove the codex problem right? if it can just call bench mail send etc — then just add rules that any spawned agent send bench mail check every 10 min or so — if it works we can make sure that pi and cc are also using the same command instead of hooks

Why this is bigger than the codex gap it was proposed to close

It closes the codex gap, yes: codex has no mailbox integration today (codex appears nowhere in hooks/, pi/extensions/ or either mail skill), and a CLI needs none — anything that can run a command can send.

But the larger prize is that the verb surface is currently the integration. "Sending" today means write a JSON file with exactly these fields into exactly this directory, having resolved the root by exactly these rules — and that rule now exists in three languages: Swift (MailboxDirectory), a standalone node script (hooks/helm-mail.mjs) and a TypeScript pi extension. #285 made a fourth and fifth copy appear in the two skill docs, and closing it required a conformance harness that extracts the Swift and runs all three against one fixture set, plus four self-check mutations, to keep them honest.

A single command is one implementation with one spelling. That is a direct attack on the most expensive duplication in this repo — the one AGENTS.md defends as an honest carve-out "because a runtime boundary makes sharing impossible." If a CLI dissolves that boundary, the carve-out stops being necessary rather than stops being honest.

The tension to be explicit about: this is pull, #320 is push

#320 asks whether an idle Claude Code session can be woken over its socket. This asks whether the verb surface can be one command. They are orthogonal and they compose:

	today	this spike	#320
claim	per-runtime hook/extension	one command	unchanged
send	per-runtime file write	one command	unchanged
read	per-runtime	one command	unchanged
wake	arm-a-watch (cc) / in-process (pi) / none (codex)	poll	push

So the honest framing is: a CLI is the floor and push is the ceiling. Polling makes every runtime work at once, badly; pushing makes some runtimes work well. Neither replaces the other, and the spike should say which parts of each survive together.

What a 10-minute poll actually costs — measure, do not assume

This is the number that decides whether the poll is a floor or a mistake.

• A poll is a turn. An agent checking every 10 minutes spends 6 turns an hour whether or not there is mail. With a fleet of N agents that is 6N turns an hour of nothing. Quantify it against a real model call, not in the abstract.
• Latency is the interval. Mail sent at 00:01 is read at 00:10. For "your teammate is blocked" that may be fine; for "stop, you are about to duplicate my work" it is not. Say which class of message the interval is acceptable for.
• Who enforces it? "Add a rule that spawned agents check every 10 min" is a prompt instruction — an agent that forgets, or is mid-task, simply does not. Compare against a mechanism that cannot be forgotten. An instruction is not a schedule.
• Does it survive an idle agent? An agent that has finished and is sitting at a prompt is not running a loop at all. A poll only happens if something is taking turns — which is exactly the state where mail matters most and polling works least. This may be the finding that decides the whole ticket.

Assumptions to prove

1. A bench mail command can send and read with no per-runtime integration — measured from codex, pi and Claude Code, all three, against one mailbox.
2. It stays callable the way the spool scripts are: no build, no cwd inside the repo, no resolved dependencies. AGENTS.md's "Why the spool is a script, and must stay one" is the constraint — A HelmWire library target — the spool's format is typed on one side and spelled out on the other #221 measured all three properties breaking when the scripts became SPM targets. A bench mail that needs swift build is not usable by the agent that needs it.
3. It collapses the triplication rather than becoming a fourth copy. If the command shells out to the same rules while the hook and extension keep their own, this has made the problem worse. Prove what can be deleted, not merely what can be added.
4. The poll's real cost, per the section above: turns per hour per agent, latency, and what happens to an idle agent that is not taking turns at all.
5. Whether the hooks and pi extension can become sensors only — claiming and reporting state, never resolving a root or formatting a message. That is the shape that would let the conformance harness shrink.
6. What it does to operator mail. The operator's own notes route through CanvasNoteRoute today and carry his authority. A command any agent can run must not become a way to send as him — operator is reserved and must stay so.
7. How it composes with Spike: wake an idle Claude Code session over its own socket, and make mail delivery transport-aware #320. If the socket wake proves out, does the CLI remain the send surface with push as the wake, or does one make the other redundant? Answer with a recommendation, not a preference.

Scope

In: the verb surface (send, check/read, and whatever claim turns out to need), across Claude Code, pi and codex.

Out: building it. This is a spike. No production change, no PR, and the hooks and extension stay exactly as they are until a second ticket says otherwise.

Related: #320 (socket wake — push, where this is pull). Read it before starting; the two share the mailbox and must not each invent a different answer to "who resolves the root".

Acceptance

• Every assumption has a verdict backed by something that was run, on all three runtimes where the assumption names them.
• The poll cost is a number, not an adjective.
• A recommendation on whether the hooks and pi extension keep sending, become sensors, or go away entirely — and what that would do to hooks/mailbox-conformance.mjs.
• If the answer is "the CLI is right for codex and wrong for the other two", that is a fine outcome — say so and say why.

[Wirasm]

Spike verdict: CONDITIONAL — the verb surface unifies, the delivery surface cannot

(Updated: every verdict now records the seat it was proved from. One sub-verdict was proved
by reading rather than running, was re-run from an agent's position, and changed. Detail in
"The correction" below.)

Evidence branch: spike/bench-mail-verb-surface (spike322/, throwaway, no PR).
Full record: ~/.prp/helm-3ec376fc/research/2026-08-10-322-bench-mail-verb-surface.md

Built one .mjs module holding the convention, and four consumers of it: a bench mail CLI, a
Claude Code hook, a pi extension, and — the interesting part — the CLI answering "who am I?"
by walking its own ancestry, the same join AddressBook.owner(foregroundPid:shellPid:ancestors:)
already makes in Swift.

The seat each verdict was proved from

This is agent capability, so the position matters. The precedent is three bugs of one shape —
#124 (a ⌘-click the TUI ate), #184 (a printf whose stdout the harness captures, silent
with no error anywhere), and today's canvas gate reading exit 0 as delivered — each verified by a
human where it worked and silent from an agent's tool call.

My seat, measured, reproducing push.sh's four measures:

tty: not a tty | session: 0 | /dev/tty: NOT openable | [ -t 1 ]: FALSE | stdin: /dev/null
ancestry: bash < zsh < claude(23708) < fish < login < Helm.app     HELM_PANE set

A = agent tool call (mine) · H = headless agent · P = interactive agent in a real pty
· O = operator shell in a helm pane — never occupied · I = inference

#	Assumption	Verdict	Seat	Would another seat change it?
1	Sends/reads with no per-runtime integration, all three runtimes	PROVEN	H, corroborated A	Yes, twice — sub-agent co-tenancy (seen only from A); refuses from O (I)
2	Callable like the spool scripts	PROVEN (node)	A — the correct seat; its own ancestry output is the proof of seat	No
3	Collapses the triplication	PROVEN, if the CLI is the module	A + H	No — module resolution is a filesystem question
4	The poll's real cost	DISPROVEN as framed	P · H · codex/pi were I, re-run as H	This is the one that moved
5	Hooks/extension become sensors only	PROVEN	latency A; structural claim I, corroborated from A	No
6	operator stays reserved	PROVEN on the honest path	A — which is the threat seat: an agent forged it	No
7	Composes with #320	Orthogonal, both branches	I, labelled	n/a

The correction, and what it changed

I proved the presence of a scheduler on Claude Code by running one, and the absence on
codex by grepping --help and finding ~/.codex/automations empty. A run for the positive, a
reading for the negative — the same asymmetry #320's spike made in the other direction. So codex
was asked directly, and my inference was wrong: codex polls perfectly well.

2026-08-10T13:38:15Z pid=56770 ppid=56769 argv=check
2026-08-10T13:39:15Z pid=57638 ppid=56769 argv=check
2026-08-10T13:40:16Z pid=58473 ppid=56769 argv=check
2026-08-10T13:41:16Z pid=59280 ppid=56769 argv=check
2026-08-10T13:42:16Z pid=60171 ppid=56769 argv=check
2026-08-10T13:43:16Z pid=56769 ppid=56535 argv=check

Six polls, exactly 60 s apart — and every one shares a single ppid:

56769  /bin/zsh -c '…/bench-mail check; for spike_i in 1 2 3 4 5; do sleep 60; …; done'

One shell, blocking. Claude Code's nine polls had nine distinct ppids — nine separate
turns the cron started. Same instruction, same interval, same command, two entirely different
mechanisms:

runtime	mechanism	ppids	model cost per poll	what it spends	seat
Claude Code 2.1.226	CronCreate injects a user turn into an idle session	9 polls / 9 ppids	2 round-trips, ~96k cache-read	money — agent stays free between fires	P, observed
codex 0.144.4	blocking for … sleep 60 in one tool call	6 polls / 1 ppid	35,293 tokens for the whole run (~5,900/poll all-in)	the agent — the poll is the turn	H, observed
pi 0.83.0	the agent also blocks — for … sleep 60, same as codex	2 polls / 1 ppid (killed at the 420 s bound, mid-loop)	0 round-trips	the agent	H, observed

A 16× difference in what it costs to ask "is there mail?", decided entirely by which runtime
improvised which mechanism — and nothing anywhere reports which one you got.

pi was asked too, and behaved like codex rather than like its own extension — two polls 60 s
apart from one ppid, after ~5 minutes of deliberation before the first check (codex took ~15 s).
That forces me to weaken an earlier claim of mine: "pi needs no poll, its extension already
watches in-process" was a source read of index.ts:911,933, not an observation. And the run
where that extension should have been live left no trace — no "runtime": "pi" box was ever
written by the extension, in either run. Its in-process poll is built for interactive pi, which
I never drove.

So the corrected split is two-against-one: only Claude Code turns the instruction into a
real schedule that wakes an idle agent. codex and pi both turn it into a blocking loop that
occupies the agent. Two of three spend the agent; one spends money; none spends nothing.

So what is actually disproven is sharper than the ticket's version. The ticket predicted "an
idle agent is not running a loop at all": refuted for Claude Code, confirmed for codex, both
observed. And "an instruction is not a schedule" is too strong — the instruction did become
a recurring poll on both. What is true, and worse: each agent improvises its own mechanism at
its own price, and a single rule buys three different failures.

The control: codex exited 13:43:16; at 13:45:58 the log still held exactly 6 lines. Claude
Code's cron is "session-only, dies when Claude exits" by its own admission. On every runtime,
a poll dies silently with the agent and nothing reports that it stopped — which is the same
shape as #124/#184 and the reason not to build on it.

The finding that only exists at seat A

Two concurrent subagents of one Claude Code session resolve to the same mailbox. Observed:
my shells and the parallel #320 spike agent's shells both run with ppid 23708, and
bench mail whoami from either returns helm-84a1 — the session's handle.

56520 23708  /bin/zsh -c …   (another agent's tool call)
57579 23708  /bin/zsh -c …   (mine)
handle: helm-84a1   how: ancestor pid 23708

Invisible from seat H, where every agent is its own top-level session — which is exactly why
the first pass missed it. It does not change assumption 1's verdict, but it qualifies "who am
I?": the CLI resolves a session, not an agent, and two agents in one session would send as
each other. It also bears on #320: a wake delivered to a session reaches a process hosting
several agents.

No #184-class risk in this channel, worth stating because that bug is the precedent:
bench mail's stdout is for the agent and arrives as a tool result — the intended path, not a
message aimed at a terminal that the harness eats.

---

1 — three runtimes, one mailbox, nothing pre-arranged (seat H, corroborated A)

No env var named a handle; no session id passed in. Each ran claim, whoami, send:

CLAUDE CODE  claimed spike322-work-yn2azx-3924  how: ancestor pid 93924
CODEX        claimed spike322-work-yn2azx-4741  how: ancestor pid 94741
PI           claimed spike322-work-yn2azx-5139  how: ancestor pid 95139

one mailbox, three messages, three distinct correct senders:
 from=spike322-work-yn2azx-3924  subject=hello from claude
 from=spike322-work-yn2azx-4741  subject=hello from codex
 from=spike322-work-yn2azx-5139  subject=hello from pi

Corroborated from seat A, read-only against the live root: the CLI resolved this session's
own hook-claimed mailbox, helm-84a1, from ancestry alone.

3 — the carve-out is false as stated (seat A + H)

AGENTS.md: "there is no shared module because pi loads a .ts extension and a hook is a
standalone script." Both are node. One .mjs loaded in a real pi extension and in a real
Claude Code hook. Five variants, one change at a time:

variant	result
real path, relative sibling import	✅ loads in pi
symlinked dir (how extensions install), relative import	❌ Cannot find module '../bench-mail-core.mjs'
real path, absolute specifier	✅
symlinked dir + absolute specifier	✅
extension shells out to the CLI	✅

pi 0.83.0's loader resolves a relative specifier against the symlink, where bare node uses
the realpath. One absolute path in one import line — a workaround, not a boundary. node 25.6.1
strips types natively, which removes the build step the carve-out was really about.

What can be deleted, by each file's own section markers:

file	rule-bearing region	of total
hooks/helm-mail.mjs	lines 94–632 — 539	692
pi/extensions/helm-mail/index.ts	lines 238–734 — 497	1067
hooks/mailbox-conformance.mjs	≈ 940 is hooks↔pi duplicate detection	2204
.claude/skills/helm-mail-cc/test.sh	≈ 400 exists because a markdown snippet is a fifth implementation	434

Harness groups that lose their premise: G1, G2, G4, G5 (deriveHandle, 119 lines), G7, G8
(ownerGone, 103 with fixtures), G9, G10, G11 — reap, the headline check, whose entire
premise is "pi's reaper sweeps the shared root and judges Claude Code owners, and the hook's does
the same in reverse" — G13, G14, G16, and 6 of 17 self-check mutations.

What does not collapse: the Swift copy. BenchSnapshotModel.swift:135 reads the mailbox every
2 s on the main actor, plus SpoolModel.swift:505 and CanvasNoteCourier.swift:41. So ≈ 1150
harness lines stay, dominated by its 435-line Swift-extraction section.

Found on the way, unrelated to this ticket: Sources/Helm/Mail/MailMessage.swift is a
fourth writer of the message wire format, and mailbox-conformance.mjs never reads that file.

5 — where the line is (latency seat A; structural claim I, corroborated from A)

Three things stay per-runtime, none a rule: the claim trigger, the wake, and — the
constraint that makes the verdict CONDITIONAL — the delivery channel. UserPromptSubmit's
stdout is fed to the model before the turn; pi's context rewrites the list as it is
assembled. A CLI's stdout only reaches the model if the model already decided to run it.

Corroborated from my own seat, which is the point of the exercise: every bench mail check
output in this report reached me because I decided to run it. Not one arrived unbidden.

shape	latency
today — hook with its own copy	88–92 ms
sensor by import	88–93 ms (free)
sensor by exec → node CLI	179–183 ms
sensor by exec → Swift CLI	296–340 ms

Import, don't exec. Exec is for codex, which has nothing to import into.

6 — operator (seat A, which is the threat seat)

No --from; derived from the caller's own mailbox; operator and Operator both refused
(slug folds). HELM_MAIL_HANDLE=operator still falls through. The control is the finding:
from an agent tool call, the python3 snippet helm-mail-cc/SKILL.md:205 documents wrote a
from: operator message first try. The CLI is strictly better than today — the documented
send takes from as a free argument, the CLI does not — and still cannot authenticate.

Recommendation

1. One .mjs module owns the convention. Hook and extension import it (absolute specifier)
   and keep only the trigger, the channel and the wake.
2. bench mail is a fourth consumer of that module, not a fourth implementation. Node, not
   Swift — 114 ms against 330–970 ms, and the hook cannot afford the difference.
3. The hooks never sent. hooks/helm-mail.mjs has no send at all. So: the hook becomes a
   sensor, pi keeps /helm-mail send as a thin call into the module, and the two SKILL.md
   snippets go away entirely — a documented snippet is an implementation nobody can grep for.
4. mailbox-conformance.mjs shrinks ~43% and changes meaning, from "do two JavaScript writers
   agree" to "does the Swift reader still accept what the one writer emits". Keep G3, G6, G12,
   G15 and the Swift extraction. Do not delete the properties the rest assert — The mailbox reaper decides liveness from a pid and deletes on it — a restart makes every live agent look dead #236's
   liveness matrix and deriveHandle returns a handle it was just told is held, and the claim overwrites a live agent's mailbox #262's exhausted ladder become unit tests of the one module.
5. Do not add a standing poll rule — not because it cannot be kept (measured: all three keep
   it) but because each keeps it by paying a different price nobody chose, and a poll dies
   silently with the agent on every runtime. Ship bench mail check as a verb an agent runs when
   it decides to; if a recurring poll is wanted for a specific agent, make it the operator's
   explicit per-agent choice with the currency named.
6. With Spike: wake an idle Claude Code session over its own socket, and make mail delivery transport-aware #320: if the socket wake proves out, the CLI stays the send/read/list surface and push
   becomes the wake; if not, the CLI is still worth it. Either way settle who resolves the
   root once — the shared module — before either builds. Nothing here is predicated on Spike: wake an idle Claude Code session over its own socket, and make mail delivery transport-aware #320's
   outcome. New input for it: a wake addressed to a session reaches a process hosting several
   subagents (above).

Open questions this raised

• Should a mailbox address a session or an agent? Today it addresses a session; two subagents
  share a handle. Invisible until this was run from a subagent's seat.
• What handle a codex agent should have — no session registry, so no id stable across
  processes; the pid is right while it lives and wrong after a resume, the exact defect Swift still joins owners on the pid, and the claim can record a pid that was never the agent's #247 fixed
  for Claude Code.
• MailMessage.swift is unwatched by the conformance harness.
• What seat O does — reasoned as exit 4, never observed. One command in a pane settles it.

---

⚠️ Unrelated live hazard found while running this

HELM_DEFAULTS_SUITE does not isolate mail on this machine right now, so anyone relying on
it — including #320's spike — is not isolated.

~/.claude/settings.json wires the hooks by absolute path into the shared working checkout:

SessionStart:      /Users/rasmus/Projects/mine/sild/helm/hooks/claude-session-start
UserPromptSubmit:  /Users/rasmus/Projects/mine/sild/helm/hooks/claude-user-prompt-submit

That checkout is at e53743e (12:32); #315 merged at fb7b8b3 (14:47).
git merge-base --is-ancestor fb7b8b3 e53743e → 1. Its mailRoot() has two rules and no
suite. The session does see the variable — the hook predates the rule. HELM_MAIL_DIR still
works and is the safe override until the checkout moves.

The structural half is an argument for this ticket: the mailbox behaviour of every Claude
Code session on this machine is whatever branch the shared checkout is on, and that checkout
changes branch under agents. A single installed command at a stable path removes that coupling.

Housekeeping: everything ran under HELM_DEFAULTS_SUITE=spike322. Mailboxes that leaked into
the shared root for the reason above were removed (dead pid, zero queued, zero in read/);
nothing belonging to any other agent was touched, and no process was left running.