[Feature Request] Session cron / loop wakeups can only be listed and cancelled through the model — impossible to stop while rate-limited

Summary

Session-scoped scheduling state (/loop cron jobs and dynamic-mode wakeups) lives entirely in the local CLI process, but the only way to list or cancel it is to ask the model, which costs an API round-trip. There is no CLI-native command for it.

The asymmetry is the problem: mutating a local in-memory value requires a server round-trip.

Why this matters (the failure mode)

/loop is commonly used to keep working across a usage-limit reset — that is exactly what I was using it for ("resume when the token limit resets"). But while you are at the usage limit, you cannot stop the loop, because stopping requires an inference call that the limit is blocking. The loop you set up to survive token exhaustion cannot be cancelled during token exhaustion.

The only token-free escape today is quitting Claude Code entirely, which also discards the session context — a blunt instrument when you only wanted to cancel a scheduled job.

Current behavior

• CronCreate reports Session-only (not written to disk, dies when Claude exits), confirming the state is local and in-memory.
• CronList / CronDelete / ScheduleWakeup {stop: true} are model tools, not slash commands. Typing CronList in the prompt does not invoke anything directly; it is read by the model, which then calls the tool.
• Consequently every list/cancel operation costs tokens, and none of them work when the account is rate-limited.
• Built-in local commands (/help, /clear, …) are handled by the harness without inference, so the mechanism for token-free commands already exists — scheduling just is not exposed through it.

Expected behavior

CLI-native (harness-handled, no inference) commands for session-scoped scheduling, e.g.:

• /loop list (or /cron list) — print active cron jobs and pending wakeups
• /loop stop [id] — cancel one or all of them

Since the state is already local and in-memory, these should be answerable without contacting the API at all.

Reproduction

1. /loop 10m <anything> to create a recurring session cron.
2. Note the only documented way to inspect or cancel it is to ask the model (CronList / CronDelete <id> / "stop the loop").
3. Reach the usage limit (or simulate loss of API access).
4. There is now no way to cancel the scheduled job short of terminating the CLI process.

Notes

• Related but distinct: #77235 (/clear does not cancel pending ScheduleWakeup), #78334 (CronDelete reports success but the job reappears). Those are correctness bugs in the tools; this report is about the tools being the only interface.
• A user-authored slash command would not help, since custom skills are also prompts routed through the model.
• Hooks do not help either — they intercept tool calls and cannot cancel a scheduled job on demand.

Environment

• Version: 2.1.225 (Claude Code)
• Platform: win32 (Windows 11 Pro 26200)
• Shell: PowerShell / Git Bash