[FEATURE] In-session watcher - wake the main agent in-context when an awaited event completes

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 the main session is waiting on an external thing to finish — a long build, a deploy, a data sync, an index rebuild, a file to land, a remote job — there is no first-class way for the main agent to wait on that event and resume automatically in the same context. Today the options are all lossy:

• Hand off to a routine / background task / sub-session → runs in a separate context; the result must be summarized back, and the main session loses the rich in-context state and momentum it already built up.
• Poll on a timer (self-wake) → wastes turns, and is time-based not event-based: poll too often and you burn cost, too slow and you add latency.
• Block and manually re-prompt → the user has to babysit and paste the "it's done now" message back in.

So the agent either loses context or burns turns polling. There is no "watch for this specific condition and wake me, in this same session, the moment it is true" primitive.

Proposed Solution

An in-session watcher — effectively "routines inside the main session." Mid-task, the agent registers a watcher for a condition (a command's exit, a file appearing or changing, a URL returning an expected status, a background task completing, a webhook/MCP event). The session yields control back (non-blocking — the user can keep chatting) but keeps its context warm. When the condition fires, the session automatically starts a new turn in the same context with the watcher's result available, and continues the work.

Key properties:

• Event-driven, not just timer-based (complements existing self-wake polling).
• Context-preserving — resumes the existing main session, not a fresh one; no handoff or re-summarization.
• Non-blocking — runs in the background; only wakes the agent on the event.
• Agent-initiated — the agent sets up a watcher for whatever it is currently waiting on, mid-task.

Illustrative UX (not prescriptive): a tool the agent can call, e.g. watch({ until: <condition>, then: "resume" }); a small "watching: <condition>" indicator shown while the session is idle; on fire, the agent receives a structured wake event ("watcher matched: <result>") and proceeds automatically.

Alternative Solutions

• Routines / background tasks / sub-agents — work, but run in a separate context; momentum is lost and the result must be relayed back.
• Timer-based self-wake — exists, but it is polling, not event-driven: either too frequent (cost) or too laggy (latency).
• External wake signal (#60943) — provides the plumbing (an external process pokes a session via IPC). This request is the in-session, agent-owned, event-driven layer on top: the agent declares what it is waiting for and self-resumes in-context, with no external orchestrator. Complementary, not a duplicate.
• Manual babysitting — the user re-prompts when the thing is done; defeats the point of letting the agent work autonomously.

Priority

Medium - Would be very helpful.

Feature Category

Interactive mode (TUI)

Use Case Example

1. I ask the agent to make a change, deploy it, then do follow-up steps once it is live.
2. The deploy takes several minutes on external infrastructure the agent cannot directly block on.
3. Instead of spawning a separate routine (which loses the context we built) or polling every 30s (which wastes turns), the agent sets a watcher: "wake me when the deploy health-check returns 200."
4. The agent yields control; I keep using the session for something else.
5. The moment the check passes, the agent wakes itself in the same context and continues the follow-up steps — remembering everything from before.

Other everyday cases: waiting on a long data sync or index rebuild before running validation; waiting for an artifact file to be produced by an external tool; waiting for a remote job queue to drain.

Additional Context

• Related issues (this request is the in-session, event-driven, context-preserving layer; linking for dedupe and visibility):
• #60943 — External wake signal for interactive sessions (the external-IPC plumbing that could power the "wake" half of this).
• #61523 — "Dormant" / "Scheduled" session state for background monitors (idle-monitor UI/state).
• Adjacent building blocks today: timer-based self-wake, background shell tasks, and routines/sub-agents (separate context). This asks for an event-driven watcher that resumes the main context instead.
• Security note: a watcher that auto-resumes the agent is, by design, an autonomous-action trigger. Mirroring the red-team discussion in #60943, the wake event should carry only a structured result of the watched condition (e.g. "URL returned 200", "file X created"), never free-form, externally-controllable instruction text. Watchers should be user-visible and cancelable.