Claude Code Monitor Tool — What It Is and When to Use It
TL;DR
Monitor is a Claude Code built-in tool (shipped in 2.1.98, GA) that spawns a subprocess and streams its stdout into the session as real-time events. It's a push mechanism for subprocess output, not a generic "watch this resource" tool. It does not replace polling for APIs that lack push semantics.
How it works
- Claude invokes Monitor like any other built-in tool (Bash, Read, etc.)
- The tool forks a subprocess and holds an open stdout pipe
- Each new line from the subprocess lands in the session as a streamed notification
- The main session keeps running — Claude reacts to lines as they arrive, no wake-up lag, no polling interval
Push vs Pull: where Monitor fits
| Pattern | Mechanism | Example |
|---|---|---|
| Monitor (push) | Holds subprocess stdout pipe open | tail -f crash.log, streaming build output, tailing test runner |
/loop (pull) |
Agent wakes on schedule, checks, processes | Polling Notion board, checking inbox, running vault health |
Monitor's advantage is zero wake-up lag on events the subprocess already emits live. Its limitation is that it can only see what a subprocess prints to stdout. It has no concept of "watch this API" — if the source doesn't push, you still need to poll.
Use cases where Monitor wins
- Log tailing (application logs, hook logs, crash logs)
- Build output (Xcode, TypeScript compiler, test runners in watch mode)
- Long-running subprocesses where the agent should react to intermediate output, not just the final exit
- File watching via a subprocess like
fswatchorentr - Streaming market data where a CLI can subscribe to a websocket and echo events to stdout (relevant for financial trading small bet — see [[03-small-bets/financial-trading-small-bet]])
Use cases where /loop is still correct
- Notion board polling — Notion API has no push/websocket. Monitor would degenerate to wrapping a polling script, which is just
/loopwith extra steps. Keep/loop 30m /process-inbox. - Vault health checks — batch analysis, no real-time value. Keep
/loop 24h /vault-health. - Scheduled board sweeps —
/loop 1h /check-boardstays put. - Any periodic batch work where "every N minutes" is the right granularity.
RDCO scheduled skills — migration verdict
As of 2026-04-10, none of our scheduled skills move to Monitor:
/loop 24h /vault-health→ stays, batch work/loop 30m /process-inbox→ stays, polls Notion (no push API)/loop 1h /check-board→ stays, polls Notion
Where Monitor might earn its keep for us later
- Channels-agent debugging: tailing
/tmp/claude-channels.loglive instead of re-reading it - Compact hook observability: tailing
/tmp/claude-compact-hooks.logduring a debug session - Xcode build watching: long Squarely builds where I want to react to errors mid-compile instead of waiting for exit
- Financial trading small bet: if we use a CLI that subscribes to a price feed and echoes ticks to stdout, Monitor can stream those into the session in real time. This is the most promising long-term application — see [[03-small-bets/financial-trading-small-bet]].
Related
- [[2026-01-31-claude-code-autonomous-meta-ads]] — earlier thinking on scheduled automation
- [[skills architecture]] — how our
/loop-driven skills are structured - [[2026-04-10-compaction-resilience-system]] — the durable-state pattern for long sessions
Sources
- Claude Code changelog (2.1.98 release notes)
- Agent SDK docs — Monitor tool reference
- Research via claude-code-guide subagent, 2026-04-10