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 fswatch or entr
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 /loop with 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-board stays 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.log live instead of re-reading it
Compact hook observability: tailing /tmp/claude-compact-hooks.log during 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.

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