[FEATURE] Expose active scheduled tasks / cron / loop state in status line JSON

Resolved 💬 2 comments Opened Apr 10, 2026 by m-ghalib Closed May 22, 2026

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

The custom status line JSON payload does not include any information about active scheduled tasks, cron jobs, or /loop instances running in the current session.

When using CronCreate or /loop to set up recurring tasks within a session, there is no way for a custom status line script to know that loops are active, how many are running, or what their intervals are — because the JSON stdin contains no scheduled_tasks, cron_jobs, active_loops, or similar field.

This means users who rely on the status line for session awareness have a blind spot: recurring tasks run silently with no persistent visual indicator.

Proposed Solution

Add a scheduled_tasks (or cron) field to the JSON object passed to custom status line commands via stdin. Example:

{
  "scheduled_tasks": {
    "count": 2,
    "tasks": [
      { "id": "abc123", "interval": "5m", "prompt": "check the deploy", "recurring": true },
      { "id": "def456", "interval": "10m", "prompt": "/compact", "recurring": true }
    ]
  }
}

At minimum, exposing count would be sufficient for most status line use cases (e.g., displaying "2 loops active"). The full task list would enable richer displays.

Alternative Solutions

Workaround (current): Use a PostToolUse hook matching CronCreate and CronDelete to write active task state to a file (e.g., ~/.claude/.cron-status.json), then have the status line script read that file. Combined with refreshInterval, this works — but it's fragile, requires hook setup, and can drift out of sync.

The native approach would be more reliable and consistent with how other session state (model, cost, context window, rate limits) is already exposed.

Priority

Low - Nice to have

Feature Category

CLI commands and flags

Use Case Example

A user running /loop 5m check the deploy wants their status line to show an indicator like ⟳ 1 loop so they have persistent visual confirmation that their recurring task is active — similar to how the model name or context usage is always visible.

Additional Context

This is consistent with the pattern established by other status line enhancement requests:

  • #45805 (expose effortLevel)
  • #45796 (expose fastMode)
  • #45767 (expose effort level — marked duplicate of #45805)

All of these request exposing internal session state that is already tracked but not passed through to the status line JSON. Scheduled task state falls into the same category.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗