[Bug] Unbounded agent_status journal writes when the summary model has no configured auth

[albrorithm]

Affected area

Coding agent and CLI

What happened?

(Claudeslop follows)

When no credential is configured for the prime-inference provider, DaemonSessionSummarizer
can never produce a recap — but it still appends an agent_status entry to the session
journal on every 25s sweep and every turn-end debounce, for every idle daemon-hosted
session. There is no convergence condition and no retry ceiling, so it writes forever.

On this machine it has produced 46,739 identical entries across 50 session files — 8.2 MB,
about 8% of ~/.prime/agent/sessions — with a single session file carrying 4,185 of them.
Every entry is identical apart from basedOnMessageCount:

{"type":"agent_status","id":"<redacted>","parentId":"<redacted>","timestamp":"2026-08-21T06:06:46.168Z","status":{"summary":"","taskState":"needs_input","basedOnMessageCount":4}}

Measured with the machine idle

Two sessions left idle, no user activity at all, 27 minutes elapsed:

Entries appended	130 (65 per session)
Elapsed	1,625 s (05:58:42Z -> 06:25:47Z)
Rate	1,625 / 65 = exactly 25.0 s per session

That matches SWEEP_INTERVAL_MS = 25_000 exactly, which confirms the sweep alone drives it
— no user interaction is involved. Extrapolated, that is ~3,456 entries per idle session per
day, or roughly 600 KB/session/day at the ~175 bytes these entries average.

Two distinct impacts:

1. Unbounded journal growth. Session files grow without limit for as long as the daemon
   runs, on any install that hasn't authed prime-inference.
2. The persisted verdict is fabricated. The fallback hardcodes
   taskState: "needs_input", so every one of those entries records a classification the
   summarizer never actually performed — the model was never called. That's a data-integrity
   problem for anything that reads agentStatus back out of the journal, independent of the
   disk cost. To be clear about scope: I have not observed a user-visible effect from this
   in the TUI — idle sessions display correctly for me — so I'm reporting it as a bad
   persisted value rather than a rendering bug.

Steps to reproduce

1. Ensure no credential is configured for the prime-inference provider — no entry in
   ~/.prime/agent/auth.json, no PRIME_API_KEY in the environment, no ~/.prime/config.json.
2. Run prime-agent, start a session, send one message, and let the turn finish so the
   session goes idle.
3. Leave the daemon running and watch the session journal:
   watch -n5 'grep -c agent_status ~/.prime/agent/sessions/.jsonl'
4. Observe the count rise by one roughly every 25 seconds, indefinitely, with every
   appended entry byte-identical to the last.

Expected behavior

• An unchanged status verdict should not be appended again. The journal should record
  status transitions, not sweeps — appendAgentStatus currently runs unconditionally for
  idle sessions, while the changed flag computed three lines above it gates only the
  in-memory broadcast.
• When the summary model cannot be resolved at all, the summarizer should stop retrying
  rather than re-arming owesSummary on every pass, and should not persist a needs_input
  verdict it never computed.

Prime Agent version

0.8.0

Environment

macOS 15

Additional context

No response

[sankks11]

Independent journal audit confirms this is still recurring.

Across 25 top-level journals, I found 54,000+ persisted agent_status rows occupying about 9.6 MB. More than 53,000 were exact consecutive duplicates. One journal alone contained 8,306 rows, including 8,300 consecutive duplicates, for about 1.58 MB of repeated status data.

The affected status payloads did not add useful summary text. This matches the no-auth fallback in daemon-session-summarizer.ts: when prime-inference auth is unavailable, the 25-second retry path still calls appendAgentStatus() with the same fallback state.

This supports a narrow persistence fix: append only when the durable status changes, do not fabricate a new needs_input record on every unavailable-auth retry, and apply bounded backoff. The in-memory retry can continue without growing the journal.

No raw journals are attached because they contain private session data.