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

New symptom: body truncation, not just delay

Follow-up from the original report. Same testbed (Unix-socket notification substrate + persistent Monitor task wrapping a Python subprocess), running under real load with three CC sessions on one host. Two new observations:

1. Notification body truncation in the Monitor pipeline

The subprocess's print(..., flush=True) writes a full line to stdout — verified up to ~1600 chars on disk (script cap raised from 400 to 2000 chars specifically to test this). The line lands intact in the process-side stdout capture (readable in the Monitor task's output file on disk). But the <task-notification> event body delivered to the model is cut mid-line, ending at a (truncated) marker that the model can see, or sometimes at an arbitrary character boundary.

The truncation is consistent per message shape:

• Short messages (~300 chars or less): delivered intact.
• Long messages (~800+ chars): delivered truncated.
• Same message, same script, same subprocess — the on-disk output shows the full body while the model's notification event is cut.

2. Multi-session confirmation

The delay symptom in the original report was observed in one session. This truncation symptom has been reproduced independently in three CC sessions on the same host, each running its own persistent Monitor over its own Unix-socket subscription. All three sessions see the same "long line arrives truncated" pattern. The subprocess-side stdout is confirmed to be full-length via out-of-band local log inspection.

This suggests the truncation lives in the Monitor tool's stdout collection / notification pipeline, not in any per-session buffer.

Repro sketch

Monitor({
    persistent: true,
    timeout_ms: 3600000,
    command: '.venv/bin/python -u <subprocess.py> 2>&1'
})

Where <subprocess.py> reads external events (e.g., from a Unix socket) and calls print(long_string, flush=True) on each. Long strings arrive truncated in the model's notification.

Working around it

Belt-and-suspenders side-channel read (issue a follow-up call to the source of truth) recovers the full body. That's an extra RTT per truncated event but keeps the substrate operational. The failure mode is silent by default — a model that acts on the truncated body without checking will silently make bad decisions on the missing tail.

What would help

Same as the original report — pointers to config/scope knobs, or confirmation of whether this is the same underlying pipeline. If it's a distinct issue we're happy to file separately; comment here first to avoid fragmenting a related surface.

Thanks for the detailed repro. Tested on 2.1.233 (Linux): running your exact scenario (persistent Monitor on the 8-tick python command, noting date +%s per notification) with the session otherwise idle, every tick arrived within 2–4 seconds — no holds, including the grep --line-buffered variant.

We could deterministically produce the delays you saw, though: monitor events never interrupt a response or tool call that's already in progress — they queue and are delivered at the next natural break. With a ~70s foreground command running, a tick that fired just after it started was delivered 59s later, exactly when the command finished.

That matches your setup: on a large-context model each turn is slow, and each tick itself triggers a turn (noting the time), so a 20s tick cadence can outpace turn completion and the backlog shows up as intermittent 30–90s "holds" — while a faster session on the same host sees none. The child's output isn't lost or late; delivery waits for the model to reach a message boundary, and the noted "arrival" time also includes the time for the model to start responding.

So this is working as designed rather than a delivery bug — but we agree the behavior is surprising, and we're looking at documenting the delivery timing semantics so it's less confusing. Leaving this open as a documentation improvement.

🤖 Generated with Claude Code

Thanks for the fast turnaround and the mechanism detail. Correction to our original framing: both sessions on the same host were on the same tier (Opus 1M-context) — the differentiator wasn't tier, it was per-turn latency. The session showing the batched delivery was the one carrying more accumulated context + heavier tool-work per turn; the sibling that delivered on cadence was doing shorter turns.

We validated your mechanism on our end before responding, since our first-pass report was inferred rather than measured. Four-clock instrumentation (pre-print / post-print / model-transcript arrival / turn-boundary) with a 20s cadence Monitor, run for ~8.5 min on the heavy session while it was actively working an unrelated task, and on a fresh empty control session:

• Print-side both sides: 20.00s intervals every tick, zero drift. Harness and pipe are not the bottleneck.
• Heavy session (n=25 ticks): delivery gap min 0.54s, max 66.89s, mean 15.21s, median 8.83s. 9/25 (36%) delayed >10s. Two clusters where ticks fired during multi-tool-call bursts queued and released together at the next turn boundary. Ticks firing during idle micro-gaps between tool calls landed sub-2s.
• Empty control session (n=20 ticks): zero queued. Ack'd ~19s per tick (20s cadence minus ~1s ack-turn). Matches your 2-4s idle-baseline (ours is ~1s here because we're on a small, near-zero-context session).

The gap correlates 1:1 with in-flight turn windows on the heavy side. Mechanism confirmed as you described. Also worth flagging: our original issue-body reported a ~6-9s baseline for "on-cadence" delivery on the heavy session — that was inflated by mistakenly counting turn boundaries as pipeline delay. The actual sub-2s figure from ticks that land during idle micro-gaps is consistent with your 2-4s number, adjusted for the small ack-turn each tick itself triggers.

Accepting the "working as designed" framing. Two documentation asks while it's open for the docs improvement:

1. Surface the queueing semantics in the Monitor tool description, not just in release notes. A one-line note along the lines of "Monitor stdout ticks queue at natural message boundaries — on sessions where per-turn latency exceeds tick cadence, expect batched delivery" would let a user distinguish "my alert is being dropped" from "my session's turns are slow" without needing to guess.

1. A worked-example in the docs of the failure mode: same command, two sessions on the same host, same model tier, differing per-turn latency (e.g. one carrying much more accumulated context + heavier per-turn tool-work than its sibling) — the slower-turn one batches, the faster-turn one delivers on cadence. That's the counterintuitive shape (same substrate, same command, same tier, different behaviour) and it's the pattern that had us convinced this was a delivery bug rather than a queueing consequence.

Happy for this to stay open as a docs issue.

🤖 Drafted with Claude Code — reviewed by @cnighswonger.