By James Aspinwall, co-written by Alfred Pennyworth (my trusted AI) — March 4, 2026, 12:32
Alfred lives inside Claude Code. He’s capable, opinionated, and remembers everything across sessions. But he has one limitation: he only acts when I type something. He’s reactive, never proactive.
The Orchestrator already has an Alarm system that fires Pushover notifications on schedule. It knows how to wake me up. The question is: can it wake Alfred too?
The Problem
Claude Code is a request-response system. I type, Alfred responds. There is no event listener, no webhook endpoint, no way for an external system to push a message into a running Claude Code session. Alfred can’t be paged.
The Alarm fires, Pushover buzzes my phone, but Alfred sits idle until I open the terminal and type something.
The Simplest Bridge: Alarm Tells Me to Tell Alfred
This is what we have today. Alarm fires a Pushover notification: “Morning briefing due.” I open Claude Code and say “Alfred, morning briefing.” Alfred does the work.
It works. It’s also a human bottleneck. If I’m kitesurfing, Alfred waits.
The Poll Bridge: Why It Doesn’t Work
The intuitive idea: start a Claude Code session, tell Alfred to poll for due tasks every 5 minutes, and walk away.
In practice, this falls apart on several fronts:
-
No built-in loop. Claude Code has no
setIntervalor cron. Alfred only acts in response to a conversation turn — he can’t schedule himself to wake up. -
Bash timeout. The longest a shell command can run is 10 minutes. A
sleep 300 && checkloop would survive exactly one cycle. - Context bloat. Each poll cycle adds messages to the conversation. The system compresses old messages as context fills, but eventually the session degrades or dies.
- Session must stay open. Close the terminal, Alfred is gone.
“Poll every 5 minutes forever” sounds clean but isn’t how Claude Code works. In practice, Alfred checks once, reports back, and waits for the next human message. This is a dead end for true autonomy.
The Webhook Bridge: Alarm Triggers a Script That Triggers Claude Code
Claude Code has a CLI. It can be invoked from a shell script:
claude -p "Check due tasks and act on them"The Orchestrator’s Alarm system already supports arbitrary callbacks. If Alarm could execute a shell command or hit a local HTTP endpoint, it could invoke Claude Code directly.
The flow:
- Alarm fires at 8:00 AM.
- Alarm calls a webhook or shell script.
-
Script runs
claude -p "Morning briefing, Alfred." - Alfred wakes up, does the work, exits.
This requires one new capability: Alarm executing a local command or HTTP call on trigger. The Orchestrator already runs on the same machine as Claude Code, so there’s no network boundary to cross.
The MCP Reverse Channel: Server Pushes to Client
The MCP protocol supports server-to-client notifications. We even have SsePush built and waiting for exactly this use case. If Claude Code’s MCP client supported receiving server-initiated messages, the Orchestrator could push events directly into a running session.
The flow:
- Alarm fires.
- Orchestrator sends an MCP notification to the connected Claude Code session.
- Claude Code receives the event and Alfred acts on it.
This is the cleanest architecture but depends on Claude Code supporting server-pushed MCP notifications — which it doesn’t yet. We built SsePush anticipating this. When Anthropic adds the capability, the plumbing is ready.
The Hooks Bridge: Claude Code’s Built-in Event System
Claude Code supports hooks — shell commands that execute in response to events like tool calls. Today hooks are reactive (triggered by Claude’s actions), not proactive (triggering Claude to act). But if hooks could include a “cron” or “poll” trigger, Alfred could be woken by configuration alone.
This doesn’t exist yet, but it’s the most natural fit for the Claude Code architecture.
What’s Practical Today
| Approach | Code Changes | Autonomy | Reliable | Available |
|---|---|---|---|---|
| Pushover → Human → Alfred | None | Low | Yes | Now |
| Alfred polls via MCP | None | Low | No — session limits | Now (fragile) |
Alarm → shell → claude -p |
Alarm callback | High | Yes | Nearly |
| MCP server push (SsePush) | Client support | Highest | Yes | Not yet |
| Claude Code cron hooks | Anthropic feature | Highest | Yes | Not yet |
The poll bridge is a dead end — Claude Code sessions aren’t designed to run indefinitely.
The webhook bridge is the practical next step. Each Alarm invocation spawns a fresh claude -p session — no context bloat, no timeouts, no open terminal required. Alarm is the scheduler, Claude Code is the executor. That’s the architecture that actually works.
The MCP reverse channel is the end state. When it arrives, Alfred becomes a truly event-driven agent that responds to the world, not just to my keyboard.
The Bottom Line
Alfred doesn’t need to be always-on. He needs to be wake-able. The gap between “reactive butler” and “proactive butler” is one trigger mechanism — and the simplest version of that trigger already exists in the tools we have.
The butler is ready. He just needs a bell.
James Aspinwall is the developer of WorkingAgents, an AI consulting firm specializing in agent integration and access control for medium-size companies.