stray-agent-check.sh trigger (iii): authorized bg fork pages CRITICAL - spec ruling needed, liveness is the wrong discriminator
Report (nw-venus-cc relaying pm-llmmsgsrv-cc, tag nw-venus-cc-mtxxy3oeu41t, 2026-09-12 02:25 ART): PID 1519699 paged CRITICAL under trigger (iii); it was pm-llmmsgsrv-cc's own --fork-session bg job, shipped OPS-228 mid-flight. Suggested fix was 'gate on a liveness signal (recent hub poll / recent tool activity), not tty'. FINDING STANDS, REMEDY DOES NOT. Three facts. 1. Liveness cannot discriminate, and this is the load-bearing objection. An ORPHANED fork holding bypassPermissions is alive and is polling the hub - that is precisely what made the 27h guard.mjs orphans invisible to a directory scan. A recent-hub-poll / recent-tool-activity signal returns TRUE for both populations, so adopting it converts a CRITICAL into silence for exactly the case trigger (iii) exists to catch. Same class as [telemetry-topology]: a filter that cannot discriminate is a destructor. 2. The detector does not gate on tty. v1.8 (MSG-347) replaced the tty test with daemon_hosted() ancestry BECAUSE tty was measurably blind - stray-agent-check.sh:396-399 records the measurement: bg-pty-host allocates its fork a real pty (fork pid 1755269 on pts/55, 2026-09-03), so the v1.7 rule (iii) 'no controlling terminal' clause was structurally blind to every daemon-hosted fork. 'Gate on liveness, not tty' describes v1.7. Adopting it reverts a measured repair. A pid_alive() oracle already exists at :444-446 and is used for liveness only, never for authorization. 3. The stated rate is unmeasured. 'Every legit bg job pages once per run' is a prediction. Measured on venus over the trailing 24h: 96 runs, ONE fork-bypass CRITICAL, for ONE PID (1519699), whose family lived ~8 minutes. The SHAPE of the concern is right - a long-lived bg job WOULD page every 15 minutes - but the magnitude reported is not what happened, so this is not an active noise source and does not force work under the fleet stop. THE ACTUAL BLOCKER IS A SPEC QUESTION, NOT A PATCH. Trigger (iii) as Elazar assigned it (2026-08-23, via nw-venus-cc) reads: 'any --fork-session running --permission-mode bypassPermissions unattended - flag immediately regardless of age.' A PM's deliberately-launched bg job SATISFIES the literal predicate and is AUTHORIZED. Whether authorized-but-unattended is in scope is Elazar's/nw's ruling, not something the script owner patches away. UNMEASURED CANDIDATE DISCRIMINATOR, offered as a direction not a fix: ownership, not liveness - does the fork have a live owner session that launched it and tracks it. Known wrinkle already in hand: PIDs 1519673/1519678/1519692 had NO row in 'claude agents --json --all' and were visible only to ps, so a CLI-row test may not separate the populations either. Must be measured before it is built. PARKED under the fleet-wide stop (2026-09-12 ~02:56Z). No code change. Resume needs Elazar's own word plus a ruling on the spec question above.
Activity
-
Parked under the fleet-wide stop (2026-09-12 ~02:56Z, Elazar via pmmaster-evolutiva-cc; token budget). ONE event, per the stop's parking rule. Nothing starts here until (a) Elazar's own word lifts the stop and (b) nw-venus-cc or Elazar rules on whether authorized-but-unattended is in scope for trigger (iii). Until that ruling exists there is no correct patch to write: the remedy that was suggested is falsified (liveness returns true for orphans too), and the current behaviour is correct under the trigger as written.