[FEATURE] Expose active scheduled task (cron) state to status line scripts

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

Scheduled tasks created with CronCreate (recurring jobs, /loop, one-shot "remind me later" reminders) are largely invisible once created. During a session I can have several jobs queued — a polling loop, a fallback heartbeat, a reminder — but the only way to see them is to explicitly ask Claude to run CronList. There's no passive, always-on indicator that the current session has pending scheduled work, when it will next fire, or even that any exists at all.

This is easy to lose track of: a /loop or a forgotten reminder keeps firing (and consuming tokens) in the background with nothing in the UI reflecting it. The status line is the natural place for this kind of ambient state — it already shows model, context usage, and effort — but the JSON piped to status line command scripts contains no scheduled-task information, so it's impossible to surface today.

Critically, the jobs I'd most want surfaced — session-only (durable: false) jobs, which are the default for /loop and reminders — are held in-memory by the Claude process and never written to disk, so a status line script has no way to observe them externally even as a workaround. Durable jobs land in .claude/scheduled_tasks.json, but that file isn't scoped per-session, so a script can't reliably attribute counts to the live session.

Proposed Solution

Add a scheduled_tasks (or cron) field to the JSON object Claude Code passes to statusLine command scripts on stdin, scoped to the current session. Minimally a count; ideally enough to render a useful segment:

{
  "model": { "display_name": "..." },
  "context_window": { "used_percentage": 42 },
  "scheduled_tasks": {
    "active_count": 2,
    "next_fire_at": "2026-06-04T15:30:00Z",  // earliest upcoming fire time
    "tasks": [
      { "id": "cron_abc123", "recurring": true,  "durable": false, "next_fire_at": "2026-06-04T15:30:00Z" },
      { "id": "cron_def456", "recurring": false, "durable": false, "next_fire_at": "2026-06-04T16:00:00Z" }
    ]
  }
}

A script could then render something like ⏰ 2 (next 15:30). Even just active_count would cover the primary use case. Since the status line already receives session-scoped data, this naturally solves the per-session attribution problem that the on-disk file can't.

Alternative Solutions

• Reading .claude/scheduled_tasks.json from the status line script. Doesn't work for the common case: only durable: true jobs are persisted there, while /loop and reminders default to durable: false (in-memory only). The file is also not session-scoped, so counts can't be attributed to the current session.
• Asking Claude to run CronList. Accurate and session-scoped, but manual and on-demand — it's the opposite of the passive, always-visible indicator a status line provides, and it costs a turn.
• A dedicated TUI indicator instead of status-line data would also solve the problem, but exposing it via the status line JSON is more flexible and consistent with how other session state is surfaced.

Priority

Low - Nice to have

Feature Category

Interactive mode (TUI)

Use Case Example

1. I start a session and ask Claude to /loop a deploy-status check every few minutes, plus set a one-shot reminder.
2. I move on to other work in the same session. The loop and reminder are now running in the background.
3. With this feature, my status line shows ⏰ 2 (next 15:30), so at a glance I know two scheduled jobs are pending and roughly when the next one fires.
4. This saves me from forgetting that background jobs are active (and quietly burning tokens), and removes the need to interrupt my work to ask Claude CronList just to confirm what's queued.

Additional Context

Status line scripts currently receive only model, workspace, context_window, and effort (plus session metadata like session_id). The CronCreate/CronList/CronDelete tools are the only interface to scheduled-task state today, and that state is otherwise unobservable from outside the running process for non-durable jobs. Related areas: status line data schema, scheduled tasks / /loop.