Expose /loop state to hooks so tools can see active loops

Ideas Feature Requests
, ,
1

Feature request for product/service

Cursor CLI

Describe the request

/loop runs as a monitored background shell (sleep N plus a sentinel line) that wakes the agent. From outside the agent, a tool that watches sessions (a status bar, a session dashboard, a terminal multiplexer) can’t reliably tell:

  • that a loop is active, with its interval and its prompt;
  • when the next tick is due;
  • when the loop has stopped: stopped by the user, by its end condition, or because the background shell died. That last one is the known case where long-interval loops never tick (topic 162544).

The background shell’s command line shows up in the process list, but that’s an implementation detail, not something to build on. And the CLI’s own stop hook isn’t emitted yet (topic 169059), so a watcher can’t even check at turn ends.

Request: any of these would do:

  1. Loop state in the stop hook input: active loops with interval, prompt and next tick (an empty list means none). Qwen Code did this for its scheduled tasks (QwenLM/qwen-code#6529).
  2. Hook events for loop start, tick and stop, with a reason on stop.
  3. A small status file per session listing active loops and their next tick.

With any of these, a session watcher can show “next run at 14:30”, and tell an idle session from one waiting on its loop. (This applies to the IDE’s /loop too.)