Scheduled Claude Code session cannot list its own triggers/automations

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

I have a daily scheduled task ("dead-man's switch") in Claude Code that is meant to check whether my other scheduled tasks (automations) are still firing on schedule.

For that, the session would need read access to the list of my own scheduled tasks (name, enabled/paused, last-fired timestamp). From within a running scheduled session, this isn't reachable: it doesn't show up via tool search, and it's not in the full list of my connected connectors either.

Question: Is there a way to grant a scheduled Claude Code session read access to the list of my own automations/triggers (including enabled/paused state and last-run time)? If so, how do I enable it? If not, this seems like a useful feature — so a scheduled task can detect when another one has silently stopped running.

Proposed Solution

Add a way for a scheduled/automated Claude Code session to read the current state of the user's own scheduled tasks (automations) — at minimum: name, enabled/paused, and last-fired timestamp. This could be a built-in tool (similar to how GitHub access is exposed via MCP tools in these sessions) or an API/CLI flag that returns this list as JSON.

Alternative Solutions

I tried searching for this via tool search and checked the full list of my connected connectors from within the session — nothing related to listing automations/triggers exists today. The only workaround would be a human manually checking the automations list in the UI, which defeats the purpose of an automated dead-man's-switch check.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

1. I have a scheduled daily Claude Code task ("dead-man's switch") that checks whether my other scheduled tasks are still running.

2. To do that, it needs to know: is task X enabled, and when did it last fire? 3. With this feature, the switch could read that list directly and flag any task that silently stopped firing. 4. This would save me from discovering a broken automation weeks later, only because someone happened to notice a missing result.