[FEATURE] Event-based process monitoring instead of polling loops

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude Code runs a long-running process (e.g. ./gradlew build on a Kotlin project),
it monitors completion using a polling loop — repeatedly sleeping and checking if the process
has finished.

This causes a serious problem:
Repeated confirmation prompts — every polling iteration triggers a new user confirmation,
which is extremely disruptive and breaks the development flow

Note that if there is a risk of infinite loops — if the process hangs or never exits, there is no safety net (held problem)

Proposed Solution

Replace the polling approach with an event-driven model:

1. Attach to the process output/exit event directly (via stdout/stderr stream end or process exit code)
2. Wait silently for the event — no repeated confirmations needed
3. Apply a configurable timeout as a safety net (e.g. default 5 min, user-configurable)
4. On timeout, surface a clear message and let the user decide how to proceed

This means a single confirmation at the start, then Claude Code waits silently and reacts when done.

Alternative Solutions

Currently using no workaround — the repeated confirmation prompts must be manually dismissed
each time, making long builds very tedious to work with.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. I ask Claude Code to write a Kotlin function and run it via Gradle
2. Claude Code runs: ./gradlew build
3. The build takes ~60 seconds
4. During those 60 seconds, Claude Code polls every few seconds using sleep loops
5. Each polling iteration triggers a confirmation prompt I must manually dismiss
6. By the end of the build, I've dismissed 10-15 prompts for a single command

With the proposed solution:

1. Claude Code starts the process (one confirmation)
2. It attaches to the process exit event and waits silently
3. When the build finishes, Claude Code immediately continues — zero interruptions

Additional Context

This pattern (event-driven + timeout) is the standard approach in async programming
and is already used in most modern CLI tools and IDEs for process monitoring.
A configurable timeout (similar to how jest --testTimeout works) would give users
control without risk of infinite waits.

Note: This issue is written with claude help