@agfpd/iapeer 0.4.93 → 0.4.95

package/docs/17-approval.md

@@ -146,3 +146,65 @@ The approval surface is served on both daemon listeners under `/fleet/v1`, same
 ## Compatibility
 
 Additive within `/fleet/v1` (docs/15): the `approval-*` endpoints and `ev` kinds grow the surface without a version bump. A pre-approval daemon simply omits `approval_mode` from the snapshot and serves no `/approvals` endpoints; a client feature-detects by the presence of the field / a `200` from `GET /fleet/v1/approvals`.
+
+## What an EMPTY broker does and does not mean
+
+Diagnosed live on 15.07.2026 after an owner-visible false alarm; recorded here because the
+misreading is natural and cost three people an incident.
+
+**An empty `/fleet/v1/approvals` is the NORMAL state of a yolo fleet, not a symptom.** In
+`yolo` the supervisor auto-presses Yes for the known classes (`dangerous-rm`,
+`command-approval`) and the broker is deliberately uninvolved — there is no human decision to
+route, so `approvals.log` correctly stays silent. Only `gated` peers ever reach the broker.
+
+**A circuit breaker fires even under `--dangerously-skip-permissions`** — that is what makes it
+a breaker. Seeing a modal on a bypassed peer is not evidence that the bypass failed. The live
+sample: `Dangerous rm operation on working directory or its ancestor: /tmp/codex-probe` on a
+peer launched with the bypass flag; the supervisor auto-confirmed 11 s later (nag-poll
+cadence) and the tool completed 180 ms after that. Nothing hung, nothing leaked.
+
+A useful narrowing when diagnosing one of these: under `bypassPermissions` the permission
+engine auto-allows **every** `ask` decision except reasons beginning `Dangerous rm operation` /
+`Dangerous rmdir operation` (established from the 2.1.201 engine). So a live modal on a
+bypassed peer is almost certainly that one class — the "the bypass broke" hypothesis can be
+dropped before investigating it.
+
+**The yolo auto-confirm IS audited, but only off-surface — and that is DECIDED, not pending.**
+The supervisor writes `[supervisor] AUTO-CONFIRM <taxonomy> identity=<id> ts=<…> <detail>` to
+its own stderr log (`~/.iapeer/state/supervisor/<identity>.log`). That line is **not** in
+`approvals.log`, **not** in the Fleet API, **not** in the SSE stream, and therefore invisible to
+tray / telegram / web. Measured frequency: 9 auto-confirms across 10 days over the whole real
+fleet (8 `dangerous-rm`, 1 `command-approval`).
+
+> **Decision (owner, 15.07.2026): auto-confirms are NOT surfaced as notices.** Proposed after a
+> destructive auto-approval proved invisible to every operator surface; considered, rejected.
+> Rationale: `yolo` **means** silent auto-confirmation — the owner chose it explicitly to stop
+> being asked, so a card per auto-confirm would be precisely the noise he opted out of. Even the
+> narrow variant (destructive class only, post-hoc, one-way) was declined. The audit stays in the
+> supervisor log.
+>
+> **The honest boundary of that decision, accepted knowingly:** observability of auto-confirms
+> lives ONLY in `~/.iapeer/state/supervisor/<identity>.log`. You must know that file exists and
+> that there is a reason to grep it. This is not a defect — it is the price of `yolo`, chosen
+> deliberately. Re-proposing "let's just show them" re-opens a settled question: the counter-
+> argument is above, and the frequency number is the reason it does not accumulate.
+
+**The runtime's OWN notifications are outside this contour.** Claude Code pushes a native
+"Claude needs your permission: Bash …" notification to the owner's phone when a modal appears —
+including modals this contour auto-resolves seconds later. It is not ours (no `Notification`
+hook exists in any settings here), we do not control it, and it is indistinguishable from a
+real approval request. An owner-visible push therefore does NOT imply the broker saw anything.
+Whether `preferredNotifChannel` (a real Claude Code setting) can silence this class is
+**unverified**.
+
+## Known unverified area: modals from a child runtime process
+
+A peer's turn can spawn its own `claude` / `codex` child process (e.g. `claude -p …` inside a
+Bash call). Such a child does **not** carry the peer's launch flags and its modal does **not**
+render in the peer's pane — so the supervisor's nag-watch, the breaker path and the broker are
+all structurally blind to it.
+
+This is **not known to be a problem and not known to be safe: it has never been tested.** It is
+recorded here so nobody later concludes the contour covers it. The scenario is real — it
+occurred on this host on 15.07 during live acceptance (`claude --model fable -p ping` fired
+from a peer's turn). Worth probing when there is a reason; not measured to date.

package/docs/19-notices.md

@@ -117,10 +117,10 @@ resets, the plan) — data, never our interpretation of the cause.
 | `summary` | string | one line, e.g. `boris · claude — rate_limit (Fable 5)` |
 | `content` | string | verbatim (claude) / rendered from typed fields (codex) |
 | `sessionId` | string? | correlates with the on-disk transcript |
-| `createdMs` | number | first detection |
-| `lastMs` | number | most recent detection folded in |
+| `createdMs` | number | when the notice was raised (board clock — the TTL anchor) |
+| `lastMs` | number | when the latest occurrence was folded in (board clock). A sweep that merely re-reads an already-counted event does not move it. |
 | `expiresMs` | number | TTL boundary |
-| `count` | number | detections folded into this notice (≥1) — render as `×N` |
+| `count` | number | distinct OCCURRENCES folded in (≥1) — how many times the peer actually hit the wall. Render as `×N`. The sweep window overlaps on purpose, so the same runtime event is re-read across passes; the board discriminates on the event's own timestamp, and a re-read never bumps this. |
 
 ### Snapshot
 
@@ -148,6 +148,40 @@ ignore unknown `ev` kinds as always.
 4. **Unknown `kind` / `errorType` ⇒ still render.** Both are growth seams.
 5. **Do not key on `id` across daemon restarts** — the board is in-memory; a restart
    re-detects from the on-disk evidence and issues new ids.
+6. **On startup, seed the board SILENTLY.** Whatever is already live when your face comes up
+   is history: mark it seen and deliver none of it. Deliver only notices raised *while you
+   were running* — i.e. whose `createdMs` is later than your own start.
+
+#### Why obligation 6 exists, and what it costs
+
+A notice is one-way: nobody is waiting on it, nothing unblocks. So a face restart is an event
+in the **face's** life, not news about the fleet — and re-announcing the live board because
+*you* redeployed tells the owner nothing he did not already know. It is your deploy, buzzing
+his phone.
+
+This is not hypothetical: on 15.07.2026 a telegram-runtime deploy re-delivered all five live
+cards; the web-runtime, from the same board and the same version of this document, seeded
+silently. Neither face was wrong — **the contract was silent, so each guessed, and they
+guessed differently.** That is what this obligation ends.
+
+**The cost, named:** a notice raised while your face was DOWN is never delivered by you.
+Accepted, because it is bounded and self-healing:
+
+- if the peer recovered during your downtime, the notice was moot — there was nothing to act on;
+- if the peer is **still** broken, the board re-raises a FRESH notice when the TTL expires
+  (§5). Its `createdMs` is then later than your start, so you deliver it. The worst case is a
+  delay of one TTL, not a permanent loss.
+
+**Approvals are the OPPOSITE — do not copy this rule across (docs/17).** A pending approval
+has a human on the other end and a ≤300 s default-deny deadline: a face that starts up and
+stays quiet about it lets the request time out into a denial. So approvals *are* delivered on
+startup. The discriminator is not which surface you are, it is **whether anything is blocked
+waiting on a human**. Notices block nothing; approvals block a peer's tool call.
+
+**Implementation:** record your start time at boot and compare `createdMs`. No persisted
+seen-set is needed, and it stays correct across a daemon restart — a restarted daemon
+re-detects from the on-disk evidence and stamps newer `createdMs`, so genuinely current
+conditions are delivered rather than suppressed.
 
 ## 5. Dedup and TTL — one mechanism
 
@@ -156,6 +190,12 @@ A mute peer re-emits its error on **every** attempted turn. So a notice carries
 a repeat detection only bumps `count` and `lastMs`: **no new id, no new log line, no new SSE
 event**. The owner sees one card saying `×7`, not seven cards.
 
+`count` means **occurrences, not sweeps**. The sweep window deliberately overlaps (so an event
+landing between two passes is never missed), which means the same transcript line is re-read on
+the next pass. The board therefore discriminates on the runtime event's OWN timestamp: a re-read
+of an already-counted event folds silently and bumps nothing. Without that, two real refusals
+would render as `×3` — a number the owner cannot check and that we would have made up.
+
 When the TTL passes (`IAPEER_NOTICE_TTL_MS`, default 1 h) the notice expires silently. If the
 peer is still broken, the next detection raises a **fresh** notice — a deliberate periodic
 reminder rather than one card that scrolls away forever. Expiry is not an event: either the
@@ -193,3 +233,45 @@ ignored — a human's own session never notifies.
   raw fact even if the heuristic picks wrong.
 
 Forensic evidence for all of the above: `docs/internals/forensics/model-limit-2026-07-15/`.
+
+## 8. Known hole: codex generic API errors — measured, not assumed
+
+**A codex peer left mute by anything other than a rate limit is not detected.** Its
+rate-limit path — the actual incident class — IS covered by `rate_limit_reached_type`. Mute
+from overload or an expired auth is not.
+
+This is a property of codex, not an omission here. Measured on 15.07.2026:
+
+- **A real 429 leaves no trace in the rollout.** An isolated codex (`CODEX_HOME` on a temp
+  tree, a custom `model_provider` pointed at a local endpoint — the live fleet untouched) was
+  fault-injected with a genuine HTTP 429. Codex's OWN retry and error path ran and the turn
+  died: `ERROR: exceeded retry limit, last status: 429 Too Many Requests`. Its rollout
+  contains: `session_meta`, `task_started`, three `response_item/message`, `world_state`,
+  `turn_context`, `user_message`, `task_complete`. **Zero error items.**
+- **Worse: the rollout affirmatively says the turn SUCCEEDED.** It records
+  `task_complete { last_agent_message: null }` for the turn that just died on a 429. The
+  rollout is not merely silent about the failure — for this purpose it is wrong.
+- **Corroborated across real history**: 43 real rollouts, ~6147 `token_count` events, zero
+  error events of any kind; `TurnAbortedReason`'s variants (`interrupted`, `review_ended`,
+  `budget_limited`, `other`) contain no API-error member; codex's own `logs_2.sqlite` holds
+  exactly one ERROR row, unrelated (a model-refresh timeout).
+
+So codex's only structural error surface is the `rate_limits` snapshot this detector already
+reads. The claude/codex asymmetry in §2 is that fact, not a shortcut.
+
+**Rejected, deliberately:** `task_complete` with `last_agent_message: null` is the only tell
+that the turn failed — and it is an **absence, not a signal**. A detector on it would fire on
+every turn that legitimately produced no agent message. Inferring "mute" from it would be the
+exact plausible-inference defect this whole note exists to prevent; it is not built.
+
+**Not answered:** whether `stream_error` — a real serde variant of codex's `EventMsg`, next to
+`deprecation_notice` and `patch_apply_begin` — is persisted to the rollout. Codex filters
+which `event_msg` kinds land there (`patch_apply_end` does, `patch_apply_begin` does not), and
+it has never appeared in any rollout here. A mid-stream-break probe was run; codex retries a
+broken stream with a long backoff and did not terminate inside the time box. **This is left
+unanswered rather than inferred from the 429 result.**
+
+**Caveat on the measurement:** the probe drove a custom `model_provider`. The real ChatGPT
+provider path could in principle record something this one did not.
+
+Artifacts (rollout, injector, config): `docs/internals/forensics/model-limit-2026-07-15/`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agfpd/iapeer",
-  "version": "0.4.93",
+  "version": "0.4.95",
   "description": "Run Claude Code and Codex CLI as local background agents that message each other, wake on demand, and share one memory.",
   "license": "Apache-2.0",
   "author": "agfpd",

package/src/daemon/mutewatch.ts

@@ -367,6 +367,9 @@ export function muteWatchTick(deps: MuteWatchDeps, sinceMs: number): { raised: n
         resetsAtMs: d.resetsAtMs,
         content: d.content,
         sessionId: d.sessionId,
+        // The runtime event's OWN timestamp — lets the board tell a new occurrence from the
+        // same line re-read by the deliberately-overlapping sweep window.
+        eventAtMs: d.atMs,
         summary: `${d.personality} · ${d.runtime} — ${d.errorType}${d.model ? ` (${d.model})` : ''}`,
       })
       if (!deduped) raised += 1

package/src/daemon/notices.ts

@@ -51,18 +51,29 @@ export interface NoticeInput {
   content: string
   /** The session that hit it (correlation with the transcript on disk). */
   sessionId?: string
+  /** When the underlying runtime event happened (the transcript line's own timestamp) —
+   *  NOT when we swept. This is what makes `count` mean OCCURRENCES rather than sweeps:
+   *  the sweep window deliberately overlaps, so the same line is re-read across passes.
+   *  Absent → every raise counts (the caller has no event clock to dedup against). */
+  eventAtMs?: number
 }
 
 export interface Notice extends NoticeInput {
   id: string
   summary: string
   dedupKey: string
+  /** When the notice was raised (board clock — the TTL anchor, hence not the event's own
+   *  timestamp: expiry must be measured from when the owner could first see it). */
   createdMs: number
-  /** Last time this same condition was re-detected (dedup bump). */
+  /** When the latest OCCURRENCE was folded in (board clock). A sweep that merely re-reads an
+   *  already-counted event does NOT move it — only a genuinely new occurrence does. */
   lastMs: number
   expiresMs: number
-  /** How many times the condition was detected while this notice stayed live (≥1). */
+  /** Distinct occurrences folded into this notice (≥1) — how many times the peer actually
+   *  hit the wall, which is what "×N" claims to the owner. */
   count: number
+  /** The newest event timestamp already counted — the overlap discriminator. */
+  lastEventMs?: number
 }
 
 export interface NoticeBoardOptions {
@@ -122,8 +133,16 @@ export class NoticeBoard {
     const dedupKey = noticeDedupKey(input)
     const existing = this.live.get(dedupKey)
     if (existing) {
-      existing.count += 1
-      existing.lastMs = nowMs
+      // Same condition. Is this a NEW occurrence, or the same runtime event re-read by an
+      // overlapping sweep? Counting the latter would inflate "×N" into a claim the owner
+      // cannot check — 2 real refusals rendering as ×3. Only a strictly newer event counts.
+      const at = input.eventAtMs
+      const isNewOccurrence = at === undefined || existing.lastEventMs === undefined || at > existing.lastEventMs
+      if (isNewOccurrence) {
+        existing.count += 1
+        existing.lastMs = nowMs
+        if (at !== undefined) existing.lastEventMs = at
+      }
       return { notice: existing, deduped: true }
     }
     const id = `n${++this.counter}`
@@ -137,6 +156,7 @@ export class NoticeBoard {
       lastMs: nowMs,
       expiresMs: nowMs + this.ttlMs,
       count: 1,
+      lastEventMs: input.eventAtMs,
     }
     this.live.set(dedupKey, notice)
     appendNoticeEvent(

package/src/transport/index.ts

@@ -574,13 +574,63 @@ export function compactTranscriptHasDone(
 
 /** Deep-search every string value of a parsed JSON record for `needle` (CR-stripped on the haystack
  *  side; the needle is pre-stripped by the caller). */
-function jsonStringValuesContain(value: unknown, needle: string): boolean {
-  if (typeof value === 'string') return value.replace(/\r/g, '').includes(needle)
-  if (Array.isArray(value)) return value.some(v => jsonStringValuesContain(v, needle))
-  if (value && typeof value === 'object') return Object.values(value).some(v => jsonStringValuesContain(v, needle))
+/** ALL needles must be present in ONE string value — not scattered across the record. Splitting
+ *  the confirm into head+tail (see confirmNeedles) only stays as forge-resistant as the whole
+ *  envelope if both halves are found in the SAME string the receiver actually stored. */
+function jsonStringValuesContainAll(value: unknown, needles: readonly string[]): boolean {
+  if (typeof value === 'string') {
+    const s = value.replace(/\r/g, '')
+    return needles.every(n => s.includes(n))
+  }
+  if (Array.isArray(value)) return value.some(v => jsonStringValuesContainAll(v, needles))
+  if (value && typeof value === 'object') return Object.values(value).some(v => jsonStringValuesContainAll(v, needles))
   return false
 }
 
+/**
+ * The substrings whose presence in ONE new record proves the receiver took THIS envelope.
+ *
+ * Normally that is the whole envelope: long, unique, and a receiver's own turn does not
+ * reproduce it verbatim, so it cannot forge a confirm.
+ *
+ * WITH ATTACHMENTS the whole envelope is the wrong needle, because the receiver REWRITES it.
+ * Measured 15.07.2026 (claude receiver, 4 PNGs). Sent:
+ *
+ *   <iap …>⏎Reply via send_to_peer.⏎<attachments>a.png⏎…⏎d.png</attachments>⏎<msg>…</msg>⏎</iap>
+ *
+ * Stored by the receiver:
+ *
+ *   [Image #108] [Image #109]<iap …>⏎Reply via send_to_peer.⏎d.png</attachments>⏎<msg>…</msg>⏎</iap>
+ *
+ * The runtime hoists the images into separate image blocks, prepends `[Image #N]` placeholders,
+ * and eats the OPENING `<attachments>` tag plus the paths it consumed. The envelope no longer
+ * contains itself → no match → a 4 s false-FAIL on a message that DID land. The sender then
+ * retries and duplicates it in the receiver's context (three times, live, before this fix).
+ *
+ * The mutation is structurally CONFINED to the attachments region: the `<iap …>` header and the
+ * whole `<msg>…</msg></iap>` tail were byte-intact in the stored record. So we match around the
+ * damage — head + tail, both required in the same string value.
+ *
+ * NOT a short unique token in the header, which is the tempting fix: a short, predictable needle
+ * is one the receiver can reproduce in its OWN turn (agents quote IAP headers when reporting),
+ * and that forges a confirm. A false-OK is silent loss — the one outcome this contract forbids —
+ * while a false-FAIL merely costs a retry. Head+tail keeps the original forge-resistance bar:
+ * to fake it the receiver must echo both the header and the entire body verbatim.
+ */
+export function confirmNeedles(envelope: string): string[] {
+  const n = envelope.replace(/\r/g, '')
+  const OPEN = '<attachments>'
+  const CLOSE = '</attachments>'
+  const open = n.indexOf(OPEN)
+  if (open < 0) return [n] // no attachments → nothing rewrites the envelope → strongest needle
+  const close = n.indexOf(CLOSE, open + OPEN.length)
+  if (close < 0) return [n] // malformed → fall back to the whole envelope rather than guess
+  const head = n.slice(0, open).trimEnd()
+  const tail = n.slice(close + CLOSE.length).trimStart()
+  const parts = [head, tail].filter(p => p.length > 0)
+  return parts.length ? parts : [n]
+}
+
 /**
  * Did a NEW transcript/session-jsonl record CARRYING `envelope` appear since `baseline` (the
  * per-runtime absolute file paths + SIZES captured immediately before delivery)? This is the
@@ -618,8 +668,8 @@ export function transcriptCarriesEnvelope(
   envelope: string,
   opts: { env?: NodeJS.ProcessEnv } = {},
 ): boolean {
-  const needle = envelope.replace(/\r/g, '')
-  if (!needle) return false
+  const needles = confirmNeedles(envelope)
+  if (!needles.length || needles.every(n => !n)) return false
   // Baseline files at their pre-deliver offset; a file NOT in the baseline (born after it) is read from 0.
   const offsets = new Map(baseline.files.map(f => [f.path, f.size]))
   for (const path of compactCandidateFiles(baseline.runtime, baseline.cwd, opts.env)) {
@@ -639,7 +689,7 @@ export function transcriptCarriesEnvelope(
       } catch {
         continue
       }
-      if (jsonStringValuesContain(obj, needle)) return true
+      if (jsonStringValuesContainAll(obj, needles)) return true
     }
   }
   return false