Signal-Triggered Prompts for Automated Monitoring

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

Claude Code currently requires manual user input to trigger any LLM interaction. There's no way to have external processes, timers, or system events trigger Claude to execute prompts automatically. This limitation prevents:

• Scheduled monitoring without manual intervention
• Event-driven responses to system events (backup completion, build failures, alerts)
• Timer-based callbacks ("check this in 10 minutes" workflows)
• Integration with existing automation tools (cron, monitoring systems, CI/CD)

After searching existing issues, this feature appears unique. Related issues (#4785, #2794, #9949) request scheduled/cron execution to start new Claude sessions, not trigger prompts in running sessions. The hooks system only reacts to Claude's own events, not external signals. This proposal uniquely addresses signal-based triggering of a persistent Claude session.

Proposed Solution

1. Signal Handler Registration

Register handlers for SIGUSR1, SIGUSR2 in the CLI process that execute pre-configured prompts on signal receipt:

bash# Send SIGUSR1 to trigger a pre-configured prompt
kill -SIGUSR1 <claude-code-pid>

1. Configuration File

yaml# ~/.claude/triggers.yaml
signals:
  SIGUSR1:
    prompt: "Check backup logs and report status"
    context: "Continue from current conversation"
  SIGUSR2:
    prompt: "Review recent git commits"
    context: "New session"

1. Built-in Scheduler (Optional)

bash# Set up a scheduled check
claude-code schedule add \
  --cron "0 12 * * *" \
  --prompt "Check PostgreSQL backup logs"

# List scheduled prompts
claude-code schedule list

# Remove scheduled prompt
claude-code schedule remove <id>

Alternative Solutions

Watch Mode

bash   claude-code watch --file /var/log/backup.log --on-change "Analyze new entries"

• Pros: Direct file monitoring, immediate response
• Cons: Resource intensive, limited to file changes

HTTP Endpoint

claude-code server --port 8080
   curl -X POST localhost:8080/trigger -d '{"prompt": "Check logs"}'

• Pros: Network accessible, RESTful interface
• Cons: Security considerations, additional complexity

Named Pipes/FIFO

mkfifo /tmp/claude-trigger
echo "Check backup status" > /tmp/claude-trigger

• Pros: Simple IPC mechanism, no network exposure
• Cons: Platform-specific implementation details

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

Example 1: PostgreSQL Backup Monitoring

Current workflow: Set phone reminder → Manually check at 12:05 PM → Type prompt to Claude
With signals:

bash# One-time cron setup
echo "5 12 * * * kill -SIGUSR1 $(pgrep claude-code)" | crontab -

Configuration

signals:
  SIGUSR1:
    prompt: "Check /var/log/scottools/psqlsn.log for today's backup. Report if scottools and km0 backed up successfully."

Example 2: Build System Integration

bash# In CI/CD pipeline
make build
if [ $? -ne 0 ]; then
  kill -SIGUSR2 $CLAUDE_PID  # Trigger Claude to analyze build failure
fi

Example 3: System Monitoring

bash# Monitoring script
if [ $(df /data | awk '{print $5}' | tail -1 | sed 's/%//') -gt 90 ]; then
  kill -SIGUSR1 $CLAUDE_PID  # "Check disk usage and suggest cleanup"
fi

Example 4: Timer-Based Follow-ups

bash# User tells Claude: "remind me to check the restore in 10 minutes"
# Claude creates: (sleep 600 && kill -SIGUSR1 $$) &

Additional Context

Technical Considerations

• Signal handling during active LLM responses (queue vs interrupt)
• Security: Validate signals from same user (uid check)
• Token limits for automated prompts (configurable max_tokens)
• Logging of automated triggers for audit/debugging
• Session management (continue conversation vs new session)

Community Interest

The Claude Code community has shown strong demand for automation:

• #2794 received 34+ positive reactions for scheduled actions
• #4785 requests cron-like functionality
• Multiple issues (#3447, #4903, #4992) seek better event-driven workflows

Prior Art

• GitHub CLI webhook forwarding
• SystemD timer units with ExecStartPost
• tmux/screen session automation
• LSP servers responding to file system events