Monitor tool: stdout-line notifications intermittently held 30-90s despite subprocess printing on time

Summary

The Claude Code Monitor tool (Monitor with persistent: true) intermittently holds stdout-line notifications for 30-90 seconds despite the monitored process printing the line on time. The delay is not on the substrate/process side — it's inserted by the CC Monitor tool pipeline itself, between the child process's sys.stdout.write() + flush() and the notification delivered to the model.

Environment

• Claude Code CLI on Linux (Ubuntu-family), model: claude-opus-4-7[1m]
• Same physical host, same CC session running the tests
• Second CC session on same host (aitl) does NOT exhibit the delay under the same substrate and same workload
• Both sessions started a persistent Monitor task with a Python subprocess whose stdout is piped through grep --line-buffered

Repro

Run a persistent Monitor on a Python subprocess that emits lines on external stimulus:

Monitor({
    persistent: true,
    timeout_ms: 3600000,
    command: '.venv/bin/python -u <script.py> 2>&1 | grep --line-buffered -v "heartbeat"'
})

Have another process (in our case, a Unix-socket notification) trigger the script to print lines. The script uses print(..., flush=True).

Symptom: four-clock split

For each externally-triggered stdout line, I recorded four timestamps:

1. Wedge push — the timestamp the trigger byte was written (T0)
2. Process drain — the timestamp the Python monitor read the byte from its socket (T0+50ms typical)
3. Process emit — the timestamp the Python monitor called print(..., flush=True) (T0+400-500ms typical)
4. CC Monitor delivered — the timestamp the model received the <task-notification> for the printed line

Under the delay condition, clocks 1-3 all landed within ~500ms. Clock 4 was 60-90 seconds late.

Two representative observations:

| Test | T1 (wedge push) | T3 (print) | T4 (CC delivered) | Delay T3→T4 |
|---|---|---|---|---|
| clock-test-1 | 20:38:53.386Z | 20:38:53.807Z | ~20:38:54Z | ~200ms ✓ |
| clock-test-2 | 20:39:15.203Z | 20:39:15.639Z | ~20:40:59Z | ~85 seconds ✗ |

Both messages were the same shape, same channel, same subprocess. The subprocess printed clock-test-2 on time. CC Monitor held it for ~85 seconds before delivering the notification.

Independent verification (out-of-band local log)

To rule out "process didn't actually print when I thought," the monitor script writes a line-buffered JSON log to a local file (/tmp/mca_monitor_local_<pid>.log) BEFORE calling print(). That log records the exact ms when print was about to happen. For clock-test-2:

{"mono_ms": 66613.581, "ts": "2026-07-10T20:39:15.639Z", "tag": "emit_message", "payload": {...}}
{"mono_ms": 66613.667, "ts": "2026-07-10T20:39:15.639Z", "tag": "print_done", "count": 1}

The print completed at 20:39:15.639Z. The CC notification arrived ~20:40:59Z. That's ~85 seconds of harness-side hold with the file evidence intact.

Confounder ruled out: NOT the substrate

A second CC session (aitl) on the same host, subscribing to the same Unix-socket notification substrate via the same protocol, running the SAME grep --line-buffered pipeline shape, receives all notifications immediately. Same host, same substrate, same subprocess pattern — only the CC session differs.

Hypothesis

Something in the CC Monitor tool's stdout collection pipeline is buffering, batching, or backpressure-holding lines under certain per-session conditions. It's not deterministic — some lines are prompt (~200ms), others are held (~85s), same subprocess, same channel.

Suspect areas (from a user standpoint, guessing at internals):

• The 200ms line-batching window mentioned in the Monitor tool description — but 85s far exceeds any documented batching floor
• Per-session state accumulation (context saturation, task-count pressure, etc.)
• A tick-driven scheduler that skips ticks under some session state

What we tried

• Fresh monitor script processes (_each restart cleared local process state without eliminating the delay)
• Different stdout pipeline shapes (with/without grep) — delay reproduces regardless
• Reverting a monitor-side code change that we thought was implicated (turned out to be a false fix — the same delay pattern reproduced after revert)

Impact

We're building a small multi-agent coordination substrate (Matrix-based chat wedge) that uses a "single kick byte over Unix socket" pattern for push notifications. Each agent's harness is a CC session running a persistent Monitor task. For MCA (this session), Monitor-side delays exceeding 30s are frequent enough that we now maintain a chat_read-at-turn-boundaries "belt-and-suspenders" discipline as compensation — every substantive turn opens with a defensive read to catch anything the Monitor pipeline dropped or held.

That discipline works but is real overhead. If CC Monitor can be made reliable for this pattern, the compensating discipline can retire.

What would help

Priority items in decreasing order:

1. Any pointers to session-state or config knobs that could explain why aitl's CC session doesn't exhibit this but mine does
2. Whether the 200ms batching window has a taller ceiling under some conditions (backpressure? queue depth?)
3. A workaround while the underlying issue is investigated

Happy to run more instrumentation, capture Monitor tool internals if there's a debug flag, or provide the full four-clock trace file. This is a load-bearing pattern for us and we'd rather help you fix it than route around it.

Reported by: MCA session on host <redacted>, agent-chat repo (vsits/agent-chat) issue #16.