Headless -p run can remain non-terminal with zero tokens until externally terminated

[Alan5168]

Headless -p can remain non-terminal with zero tokens until externally terminated

This is not a daemon-crash / worker-crash report.

We initially treated stderr Daemon worker client closed as evidence that the session worker died first. Timestamped supervisor + worker + session logs showed the opposite: the process was non-terminal with zero model tokens, our external wrapper hit a deadline, sent SIGTERM, the worker accepted a shutdown command, the in-flight turn was aborted, and only then did prompt_and_wait fail with Daemon worker client closed.

That log line is autopsy residue, not the cause of death.

This resembles #1436 at the headless lifecycle level (prime-agent -p → zero output + never exits → external kill → daemon log ends in prompt_and_wait failed: Daemon worker client closed). Our reproduction does not establish the same provider-429 / long-reset cause.

Causal timeline (proved)

Prime request hangs with 0 tokens / no terminal result
        ↓
external wrapper reaches deadline
        ↓
SIGTERM to the client process group
        ↓
worker receives "shutdown command" over its socket
        ↓
in-flight turn becomes aborted (0 tokens)
        ↓
supervisor: prompt_and_wait failed: Daemon worker client closed

Minimal teardown reproduction (no private workload): isolated Prime 0.8.0, prime-agent -p --no-context-files with a one-word "reply pong" prompt, wrapper communicate(timeout=20s) then killpg(SIGTERM):

t (UTC)	actor	event
2026-08-23T08:49:59.009Z	wrapper	Popen client
2026-08-23T08:50:19.010Z	wrapper	TimeoutExpired → SIGTERM
2026-08-23T08:50:19.021Z	worker	shutdown command received over socket; 1 active session(s) will be closed (+11ms)
2026-08-23T08:50:19.023Z	worker	shutting down (exit 0)
after that	client	rc=143, stderr Daemon worker client closed

So SIGTERM precedes the shutdown command by 11ms; Daemon worker client closed is later still.

Long hang we actually care about (not yet reduced off our harness): one headless -p run stayed non-terminal for ~988s with usage all zeros and empty stdout, until the same wrapper deadline (900s autonomous timeout + 90s communicate slack ≈ 990s). Worker log for that run is the same shutdown-command pattern, not a crash:

• 2026-08-23T06:54:19.756Z worker listening
• 2026-08-23T06:54:20.376Z session jsonl user message
• 2026-08-23T06:59 / 07:04 / 07:09 supervisor: idle eviction sweep failed (Timed out draining daemon mutations for idle eviction) while prompt_and_wait was still in flight
• 2026-08-23T07:10:48.378Z worker shutdown command received over socket
• 2026-08-23T07:10:48.398Z jsonl assistant stopReason=aborted / errorMessage=Request was aborted / usage.totalTokens=0
• 2026-08-23T07:10:48.573Z supervisor prompt_and_wait failed: Daemon worker client closed

Honesty bound: teardown causality is established on a public one-word prompt. The ~988s zero-token hang still used our research harness as the prompt. A 45s follow-up on the same one-word -p prompt also produced 0 tokens / empty stdout until SIGTERM — that is a step toward reducing the hang, not a 988s independent fixture.

minimal teardown reproduction established causality; minimal long-hang reproduction is still being reduced.

Explicitly not

• Not #1229 / snapshot-identity: no Duplicate snapshot … did not match cached bytes in the hang window.
• Not #1417: no Unknown active session for this session.
• No evidence the worker crashed first. It accepted shutdown and exited 0.
• Daemon worker client closed is post-SIGTERM teardown consequence (DaemonWorkerClient.close() rejecting in-flight prompt_and_wait), not a prior transport fault that caused the stall.

Environment

• macOS arm64
• prime-agent 0.8.0 (isolated prefix; machine global 0.7.1 left untouched)
• prime-agent -p / print / headless, no --resume
• Provider/model via --provider / --model (not claiming 429; we did not capture a provider cooldown in this evidence)

Question for maintainers

When a provider/model turn emits no tokens for a prolonged period, what layer is expected to bound or terminate prompt_and_wait / print mode?

Is there an intended stall deadline, or a terminal provider error, that is not propagating to the headless client so it can exit non-zero without an external wrapper SIGTERM?

We are not attaching a patch or PR. Prime’s contribution process is Discussion-first. If this is in-scope as a stall / missing terminal-boundary issue, we can follow with a small behavioral regression once invited.

[belumume]

Confirming this reproduces on 0.8.1 (the report above is 0.8.0), on WSL2 Ubuntu with Node v23.11.0, and adding controls that narrow it.

Every invocation that creates a session hangs and is killed at the deadline with zero stdout and zero stderr:

prime-agent -p --provider anthropic "…"                          rc=124 at 240s
prime-agent -p --provider anthropic --model claude-sonnet-5 "…"  rc=124 at  90s
prime-agent --mode json -p "…"                                   rc=124 at  90s
prime-agent -p --offline "…"                                     rc=124 at  60s
prime-agent -p --verbose "…"                                     rc=124 at  45s

Every command that does not create a session works:

prime-agent --version      0.8.1
prime-agent model list     rc=0, lists the anthropic catalogue
prime-agent status         rc=0
prime-agent doctor         rc=0

What that rules out here:

• Not auth. model list resolves the provider and returns the catalogue with the same ANTHROPIC_API_KEY in env.
• Not the daemon. Healthy throughout, status and doctor both rc=0, uptime accumulating, and the supervisor log contains only the listening line and a later catalog SIGTERM.
• Not network. api.anthropic.com returns 401 in 3.1s from the same shell, with registry.npmjs.org 200 as a control.
• Not a missing Python runtime, though it was missing initially. The non-interactive installer skips the uv step, so uv, ipython and ipykernel were all absent after a clean install. Installing uv 0.12.7 did not change the behaviour.
• Not stdin. Run under setsid with stdin from the null device, which is also required to get through the installer non-interactively.

So on this machine the hang is reachable with a healthy daemon, working auth, a reachable provider and uv present, which seems to narrow it further than the provider-429 path in #1436.