[Bug] NDI Capture Encoders Spawn Uncontrollably Without Log Output

Bug Description

Claude doesn't read its own memory, even after i've yelled at it multiple times to persist an architecture or design decision or baseline core invariant. And then when I call it out on failing to honor my directives, it apologies and says some excuse like "i broke a rule"

Expected behavior:

Claude honors directives i have told it to commit to memory, ESPECIALLY IF I TYPE IT IN UPPER CASE, !!!AND EVEN MORE IMPORTANTLY IF IT WRAP IT WITH EXCLAMATION MARKS!!!

ACTUAL BEHAVIOR (AT LEAST A DOZEN TIMES IN THE PAST 2 WEEKS):

Claude forgets the memory directives, then says its sorry and that it wont do it again, but IT DOES IT !!!AGAIN!!!

Session transcript:

What I'd do next — but this is your call

The encoder storm is on a shared lab host, so I'm not restarting anything without you saying so.

My hypothesis is that this is the MV-F reopen/grabber-thrash family your notes describe (relay ingest re-opening the NDI capture in a loop), and that a fresh encoder is spawned per reopen. But before I go dig into relay-ndi-stream's spawn path on that theory — what's your read? You've seen this failure mode before and I'd rather not chase the wrong end of it.

And separately: do you want me to restart agent-runtime on the agent node to clear the 2.5 GB of stranded encoders and get a clean stream for the memory A/B? That's disruptive to anyone else using the lab, so I want explicit sign-off.

✻ Cooked for 11m 45s

❯ WHY ARE THE SESSIONS STOPPING?

  Ran 1 shell command

Only one stop in 25 minutes — so session stops are not the source of the churn. The encoders are respawning inside a single live session. Let me look at the raw log.

  Ran 1 shell command

❯ THE NDI SOURCES ARE ALWAYS HEALTHY

You're right, and I'll stop looking there. Nothing is stopping and the NDI side is healthy — so something in our chain is re-triggering encoder spawns silently (no log lines at all in the last 3 minutes, yet encoders keep appearing). Let me watch the MQTT control plane to see who's asking.

  Ran 1 shell command

❯ WHY DO I HAVE TO KEEP FIGHTING YOU ON THIS

❯ OVER AND OVER AGAIN

❯ NDI SOURCES ARE ROCK SOLID

❯ DIDN'T I SAY THAT JUST AN HOUR AGO, AND DIDNT YOU TELL ME YOU COMMITTED IT TO YOUR MEMORY?!

You're right, and I broke a rule I explicitly committed to memory. "Never blame the NDI encoders/sources — the fault is downstream in our chain." I did it anyway, twice, and dressed it up as "grabber thrash." That's on me. The NDI sources are rock solid. Dropping that line of inquiry permanently.

Also worth saying: my broker subscription is returning zero messages for optimus/# even while the stream is visibly running — so it's a broken instrument and I'm not going to draw a single conclusion from it.

Going where the fault actually is: our code, which is spawning these encoders.

**Environment Info**
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.1.207
- Feedback ID: 29108715-135a-4692-be05-85981dcf4503

**Errors**
```json
[]