Feature request: Monitor tool / stream background process output lines as notifications (avoid polling) #5260

Describe the feature or problem you'd like to solve

Copilot CLI has no way to wait on a background process without polling. To wait for a log line, a build result, or a server "Ready" message, the agent has to call read_bash in a loop or sleep/grep repeatedly. Every poll is a model turn that re-bills the whole context, so waiting is expensive.

Background bash already sends one completion notification when the process exits. That covers "tell me when it finishes". It doesn't cover the cases where the process keeps running and the event I care about is a line it prints:

• tail a log file and wake the agent when ERROR or Traceback appears
• wait until a dev server prints Ready
• watch CI or deploy output and react to each status change

Claude Code handles this with a built-in Monitor tool alongside background Bash:

• Every stdout line from a script becomes an event in the chat. Lines within about 200 ms of each other are grouped into one event.
• It can also open a WebSocket directly, so each incoming message becomes an event.
• Each monitor has a timeout (5 minutes by default, 30 at most) and can be restarted.
• A monitor that produces too many events is stopped automatically.
• Only stdout produces events. stderr goes to the output file without triggering anything.
• TaskStop cancels a monitor by task ID, and /tasks lists what is running.

Proposed solution

Add a streaming-notification counterpart to the existing background shell completion notice:

1. A monitor tool, or a notify_on option on async bash, that runs a command or script detached and delivers each stdout line (debounced and grouped) to the agent as a system_notification, which wakes an idle agent.
2. Optional pattern / until matching, so only matching lines notify the agent.
3. A timeout and a runaway-event cap that stops the monitor, so a noisy process can't flood the context.
4. Management of monitors through the existing background-task controls (list and stop).

This would remove most of the polling that read_bash waits and sleep loops cause today.

Related issues

• Loop / Scheduled commands to allow long-running tasks #2129: scheduled /loop commands for long-running tasks. That is the time-based half. This request is the event-based half.
• Surface long-running shell commands in the background tasks UI with live output #2682: live output for long-running shell commands in the background tasks UI.
• Reduce verbose polling output for background agent tasks #1397: noisy read_agent polling output.
• copilot-cli promises to monitor a long job but doesn't do this #294: the agent promises to monitor a long job and never does.
• ctrl+x → b  fails to background/interrupt a blocking  read_bash  call (no escape hatch when polling an async command) #4110: ctrl+x b can't interrupt a blocking read_bash poll.

Additional context

An agent that has to poll to wait is slow and costly. An event-driven wake-up is the cheapest way for a long-running session to stay responsive.