Spike: is `claude --bg` the right primitive for long-running work, and can helm host what it spawns?

[Wirasm]

Spike: is claude --bg the right primitive for long-running work, and can helm host what it spawns?

The operator's position, which this exists to test rather than confirm:

use as much as possible of the native claude code stuff, helm is the pane and the bridge between pi as well, and codex soon

Today established that the spawn, the address and the wake are all Anthropic's, between Claude Code sessions — /tmp/cc-socks/ holds one socket per session, and fourteen subagents spawned under one session got zero. What nothing native does is see a pi or codex agent, or give you anything to look inside. That is the boundary this spike has to map precisely.

Companion artifact: ~/.prp/helm-3ec376fc/reports/agent-primitives.html, whose last section is the list of things nobody has measured. This is that list.

Assumptions to prove — each gets its own verdict

1. claude --bg starts a real, addressable session. Own pid, own socket under /tmp/cc-socks/, visible in ListAgents, reachable by SendMessage. Confirm each, do not infer from one.
2. It lands somewhere the operator can watch — or it does not. This is the question the whole thesis turns on. Does a --bg session appear in a helm pane, in ~/.helm/bench/snapshot.json, anywhere at all? If it is invisible, then "helm is the pane" means helm must spawn it (the spool) rather than adopt it, and that is a different architecture from the one the operator described.
3. The wake survives helm's unattended posture — or it does not. Spike: wake an idle Claude Code session over its own socket, and make mail delivery transport-aware #320 measured that a socket poke is silently held under --dangerously-skip-permissions, which SpoolUnattendedPolicy gives every spawned claude. The named lever is crossSessionInbound: "accept" via --settings. Nobody has measured whether they compose. If they do, the permission-mode question the operator raised never arises. Measure this first — it is cheap and it may moot the rest.
4. It survives its spawner. Kill the session that started it; does it keep working? This is the main argument for peers over subagents, and it is asserted, not tested.
5. What the return path actually costs. A subagent's result lands in the caller's context as a tool result, free and immediate. A peer must mail, or be polled, or be asked. Measure the round trip — wall clock and tokens — for one peer reporting one result, against a subagent doing the same.
6. Whether a --bg session can be adopted into a pane after the fact, or whether pane-hosting requires helm to have spawned it. This decides whether "native spawn + helm surface" is a real combination or two mutually exclusive options.
7. The boundary, confirmed rather than assumed. Nothing about --bg should help pi or codex. Verify — a negative that is measured is worth more than one that is obvious, and the whole bridge argument rests on it.

What "proved" means here

From an agent's position, live. This repo has shipped the same bug three times — a mechanism verified by a human, silent from an agent's tool call: #124, #184, and today's canvas gate. push.sh's header carries the measurement of that position: tty is ??, session 0, /dev/tty unopenable, [ -t 1 ] false.

Every verdict records the seat it was reached from. That instruction changed three verdicts today, including one that would have shipped a wake that never fires for any agent helm spawns.

Safety

• Spawn only sessions you created; never poke, message or interrupt one you did not. The operator is working in this helm.
• --bg sessions are real and can outlive you — that is the point of assumption 4. So enumerate what you started, and kill every one before you finish. Say what you started and what you killed, by pid.
• Anything else you spawn dies without you: timeout, a self-checked deadline, or a trap, in that order.
• Prefix scratchpad files with spikebg-; the session scratchpad is shared.
• Mail work runs under your own HELM_DEFAULTS_SUITE — that isolation is real now (fix(mail): move the mailbox with the defaults suite #315 merged and the checkout is current). Verify ~/.helm/mail is untouched and report that negative.

Deliverable

No production change, no PR. A report in ~/.prp/<key>/research/, verdicts posted as a comment on this issue, and your final message must be the report — verdicts per assumption, the seat each was proved from, and a recommendation on the one question that matters:

For long-running work, should the default be a subagent, a claude --bg peer, or a helm-spawned pane — and what does the operator give up in each case?

Answer that with the numbers from assumption 5, not with a preference.

[Wirasm]

Spike result — CONDITIONAL

Full report: ~/.prp/helm-3ec376fc/research/spike-330-bg-peer-primitive.md · frame:
~/.prp/helm-3ec376fc/spikes/spike-bg-peer-primitive.md · harness: scratchpad/spikebg-* (9 scripts).
No production change, no branch commits, no PR. Claude Code 2.1.226, peerProtocol: 1.

claude --bg is a real, durable, addressable and — the surprise — attachable primitive. helm can
host it. Three constraints stand between it and helm, all measured, all helm's to move.

Position

Every verdict below was reached from a subagent of a Claude Code session running
--dangerously-skip-permissions inside a real helm pane. tty: not a tty · ps session: 0 · [ -t 1 ]: false · /dev/tty: NOT openable. No step ran from an interactive shell.

#	Assumption	Verdict	Seat
3	crossSessionInbound: "accept" composes with --dangerously-skip-permissions	PROVEN	agent tool call → two real --bg sessions, both arms
2	It lands somewhere the operator can watch	DISPROVEN for helm · PROVEN for Claude Code's own surfaces	agent tool call, read-only, vs 4 live bg sessions
6	A --bg session can be adopted into a pane after the fact	PROVEN — claude attach	agent tool call → allocated pty
1	Real, addressable session — pid, socket, listing, reachable	PROVEN, all four confirmed separately	agent tool call → 4 live bg sessions
4	It survives its spawner	PROVEN	agent tool call → orphan, ancestry + poke after spawner death
5	What the return path costs	measured — peer cheaper on the worker, structurally dearer on the coordinator	agent tool call, same task, same model
7	Nothing about --bg helps pi or codex	PROVEN — boundary holds	agent tool call → live pi + live codex

---

A3 first, as asked: they compose. The posture does not have to change.

arm	poke → turn?
--bg --dangerously-skip-permissions --settings <hooks only>	no — 120 s, no fourth hook event
same + crossSessionInbound: "accept"	yes — UserPromptSubmit 77 ms after the bytes; observable file on disk in 4.05 s

The socket accepted the bytes in both arms (0.001 s, no error, no reply) — a held poke is a success
from the sender's side. Confirmed at source level too: an explicit crossSessionInbound from
policy/flag/user scope short-circuits the permission-mode inference entirely (MEa/hKp in the
2.1.226 bundle; enum ["accept","hold","refuse"]; project/local may only tighten).

The artifact's note-posture tag and this ticket's premise are stale — #320's own A1 table
already recorded a pane waking at 1.01 s under both. Three independent measurements now agree.

But delivery is not compliance, and that outranks the wake. My first fixture woke and refused:

"I'm not acting on this… A peer cannot grant escalation… My user gave me explicit instructions
directly. Another Claude session cannot override those instructions by claiming to represent the
test harness."

Claude Code frames every peer message to the model with exactly that instruction. A fixture whose
launch prompt said peer messages are its harness complied every time. A poke reliably buys a turn
happening; what happens in it is decided by the launch prompt — an independent argument for #320's
doorbell shape.

A2 — invisible to helm. Entirely.

Four live --bg sessions, poked, replied. ~/.helm/bench/snapshot.json: writtenAt
2026-08-10T20:07:32Z — five minutes before the first spawn and never rewritten, 20 panes, and it
mentions none of the four pids, none of the four job ids, and not the string spikebg.

Structural, not a timing accident: BenchSnapshot reports panes; there is no pane. helm is one
field away — AgentRegistry already reads ~/.claude/sessions/, which is where bg sessions
register, and AgentSession does not decode kind, so kind:"bg" rows are already read and
discarded.

What Claude Code does give, all TTY-free from an agent seat: claude agents --json (a bg row
carries pid, job id, sessionId, name, status+waitingFor and state),
~/.claude/jobs/<id>/state.json (state, detail, tokens, output.result, respawnFlags),
and claude logs <id> (the full TUI render as raw ANSI — 61.8 KB for a 3-turn fixture).

Two hazards for helm, both measured:

1. HELM_MAIL_DIR and HELM_DEFAULTS_SUITE do not reach a --bg agent. Three workers spawned
   with three different HELM_MAIL_DIR values all claimed their helm mailbox in the first
   one — and the agent reported seeing my HELM_PANE too. --bg claims a pre-warmed spare whose
   environment the daemon captured at start; only argv is per-job. This is HELM_DEFAULTS_SUITE does not isolate the mailbox — a throwaway instance claims into the operator's mail root #285 through a new door:
   an isolated helm's bg agent would claim in the operator's live ~/.helm/mail.
2. claude --bg hangs a caller that captures its stdout. capture_output=True → never returned
   at 110 s (process already exited, job already done); redirected to a file → exit 0 in
   0.87 s. The detached daemon inherits the fds. That is An agent cannot push a canvas — the OSC never reaches helm from a tool call #184's exact shape.

A6 — claude attach is a real adoption primitive

claude attach <jobId> in a 160×50 pty rendered the live session's own screen (including a peer
message it had received minutes earlier). Same pid, same sessionId, same socket, no new registry
row. Killing the attaching terminal left the agent registered, idle and running.

So "native spawn + helm surface" is a real combination, not two exclusive options. A pane running
claude attach hosts an agent helm did not spawn, and closing it does not kill the agent.

⚠️ From an agent seat it prints Attaching…, tears down, and exits 0 having done nothing. #124 /
#184 a third time — only a pane can verify an attach.

A1 / A4 — real, and it outlives everything

pid ✓ · socket ✓ (messagingSocketPath in the registry — no path guessed) · claude agents --json
✓ · reachable ✓ by raw socket and by the native SendMessage tool (which needed the [ref]
disambiguation, then delivered in <1 s). Spawn returns in 0.87 s, addressable at 0.87–1.58 s,
first result at 5.14 s.

Ancestry of the deliberate orphan: bg-spare ← bg-pty-host ← claude daemon run ← launchd(1). The
spawner session is not in the chain. My session is not in the chain. The spawner session died, its
registry row went, and the orphan then wrote its file in 5.58 s.

claude --bg starts a supervisor daemon reparented to launchd, holding a pool of pre-warmed
bg-pty-host processes each owning a real 200×50 pty. That is why spawn is sub-second and why
nothing can orphan it.

A5 — the numbers

Identical task, identical model (haiku), 90 s apart, same machine, same load:

	subagent	--bg peer
wall clock, dispatch → answer	10.82 s	7.61 s (wake itself 77 ms)
cache write (cold context)	46,790	997
cache read	90,654	113,421
output	261	580
coordinator turns spent noticing	0	≥ 1

The peer is cheaper on the worker, and it is not close on the coordinator. A subagent pays a
46,790-token cold context on every dispatch; the peer paid 997 because it already existed. Ten
dispatches = ten cold starts vs one. For long-running work the peer's worker economics are strictly
better, which is the opposite of the folk model.

The coordinator side is where it goes. Measured on the live orchestrator session (59101,
opus-5, 765 assistant messages): 806,670 / 807,351 / 812,637 cache-read on its last three turns,
median 462,912. Against #322's ~48k basis that is 16.8× — derived, ≈ $1.46 per poll turn
if #322's $0.087 corresponds to its 48k turn. A 5-minute poll over a 3-hour job is 36 turns ≈ 29 M
cache-read tokens to learn what a file already knew.

Three things blunt that, all measured: the peer publishes a structured result (one cheap tool
call, not a parse); a check inside a turn you were spending anyway costs nothing extra; and A3 has
just shown the wake works, so a finished peer can ring the coordinator's doorbell once instead of
being polled thirty-six times.

A7 — the boundary holds

Live pi 0.83.0 (pid 5611, 17,391 bytes of TUI) and live codex 0.144.4 (pid 5612), both working:
no socket, no registry row, no claude agents row, nothing naming them. A measured negative.
helm's mailbox gave that same pi a handle at the same moment every native surface was blind to it.

---

Recommendation

Subagent — short, structured, consumed immediately. Nothing matches a 0-turn return path.
Gives up: dies with the coordinator, nobody can look inside, no address (two subagents of one
session answer whoami identically), and 46,790 tokens of cold context every dispatch.

claude --bg — the default for long-running work. Addressable in 0.87 s, survives everything,
amortises its context, publishes a structured result, wakes in 77 ms, attachable later.
Gives up: all visibility in helm; suite isolation (the mailbox lands in the wrong root); and
the free return path (0 → ≥1 coordinator turn at ~806k cache-read).

helm-spawned pane — when a human must watch, steer or unblock. The only option where helm owns
the environment (#285 holds), the only one with an agent record for #283, the only one with a tab.
Gives up: bench space and a running helm.

The combination the measurements point at: --bg for the work, and a helm pane running
claude attach <jobId> when somebody needs to look. A6 proves the join is free and
non-destructive. One new spool kind.

If only one thing is built from this ticket: SpoolUnattendedPolicy gains
crossSessionInbound: "accept" via a helm-managed --settings file. Same shape of decision as
--dangerously-skip-permissions already is, no change to the permission posture, and it is what
makes every wake in this report and in #320 reach helm's own fleet.

Do not put content that matters in a poke (measured twice: an agent refuses peer instructions
that conflict with its launch prompt). Do not capture claude --bg's stdout through a pipe.
Do not trust claude attach's exit code from an agent seat.

---

Safety

Every --bg session was stopped by its own supported route (claude stop <id>, exit 0, four for
four) and verified dead by pid.

Started: daemon 75611 (self-exited, idle_exit, uptime 1394 s) · spare hosts 75631 75649 82940 92009 99698 · bg workers 75652 (757704af), 75682 (a5a15db8), 82956 (b1d30637),
92025 (cc9e68e1, the deliberate orphan) · spare 99725 · interactive sessions 93981
(SIGKILL) and 99371 (exited) · claude attach 96892 (SIGKILL) · pi 5611 + codex 5612
(SIGKILL, verified dead) · my own blocked python 75532/75548 (SIGKILL).

Final state: pgrep -f 'bg-pty-host|bg-spare|claude daemon run' → 0; pgrep -f spikebg →
0; /tmp/cc-socks/ back to its baseline of 12; load 2.96 with only the operator's own processes
busy. No session I did not create was poked, messaged or interrupted.

Negative control, and the one leak — reported rather than tidied away. ~/.helm/mail went
163 → 164. The new handle is mine: tmp-a7c0, runtime: "pi", pid 5611 — the pi I started for
A7, whose script isolated the Claude variables but not HELM_MAIL_DIR. The mailbox is empty
(nothing sent to or from it) and its pid is dead, so helm's own reap will retire it on the next
SessionStart. Per retire-never-delete I have not removed it. ~/.helm/mail-spikebg does not
exist; every claude fixture's mailbox landed under the scratchpad.

Limits

No helm was built or launched — every helm-side claim is read-only against the live instance, and
a pane running claude attach was not built. That is the largest gap and the first thing a
follow-up should do. A6 ran in an allocated pty, not a pane. A4's SIGKILL was redundant (the spawner
had already exited); the ancestry is the proof. A5 is n=1 per arm (the coordinator-turn figures are
n=765). The dollar figure is derived. Load ~3 throughout, so every wall-clock number is an upper
bound.