[Feature Request] Autonomous Messages After SessionStart Hook (startup/resume/clear)

Summary

Request the ability for Claude to send autonomous messages immediately after SessionStart hooks complete, for all session lifecycle events (startup/resume/clear), before the user types their first prompt.

Problem Statement

Currently, SessionStart hooks can inject context into Claude's memory across all three lifecycle events, but Claude cannot send messages proactively. This creates a critical gap:

1. ✅ SessionStart hook loads critical instructions (MANDATORY_RULES, project setup, etc.) on startup, resume, OR clear
2. ✅ Context is injected into Claude's memory via additionalContext
3. ❌ User receives no confirmation that rules were loaded/reloaded
4. ❌ User must type something first to get confirmation
5. ⚠️ By the time Claude responds, work has already started based on those rules

The Critical Issue: Users need confirmation that Claude understood critical instructions BEFORE typing anything, not AFTER work has already begun.

This applies to ALL session states:

• New session (startup): Did my mandatory rules load?
• Resumed session (resume): Are my rules still active after the break?
• Cleared session (clear): Did context reset reload my rules correctly?

Real User Scenario

A developer (Peter) has strict architectural rules, security policies, and coding standards in MANDATORY_AI_RULES.md:

Current Broken Flow:

# Morning: Start session
$ claude-code
[SessionStart hook runs, loads rules... silence]
Peter types: "Add user authentication"
Claude: "Hi Peter! I've read your rules. [starts implementing auth]"
❌ Peter gets confirmation AFTER Claude already started work

# Afternoon: Resume after lunch
$ claude-code
[SessionStart:resume hook runs... silence]
Peter types: "Continue with auth"
Claude: [Assumes rules still active, but Peter can't be sure]
❌ No confirmation rules survived the resume

# Evening: Clear context for fresh start
Peter: /clear
[SessionStart:clear hook runs... silence]
Peter types: "Refactor user module"
Claude: [Works with reloaded rules, no confirmation]
❌ Peter doesn't know if rules reloaded correctly

Desired Flow:

# Morning: Start session
$ claude-code
✅ MANDATORY_RULES loaded. Ready to work!
[Peter sees confirmation immediately]

# Afternoon: Resume after lunch
$ claude-code
✅ Session resumed - MANDATORY_RULES active
[Peter knows rules survived]

# Evening: Clear context
Peter: /clear
✅ Context reset - MANDATORY_RULES reloaded
[Peter knows fresh start includes rules]

Current Workaround Limitations

Attempted Solution 1: stderr output

echo "Rules loaded!" >&2

Problem: stderr from hooks isn't displayed to users in the CLI interface

Attempted Solution 2: Strict CLAUDE.md instructions

IF SessionStart hook detected, MUST greet first in response

Problem: Still requires user to type something first - confirmation comes too late

Attempted Solution 3: stdout formatting

Problem: Goes to Claude's context, not user's screen

Proposed Solution

Add a new field to SessionStart hook output schema that works for all matchers:

{
  "hookSpecificOutput": {
    "hookEventName": "SessionStart",
    "additionalContext": "string",
    "autonomousMessage": "string"  // NEW: Triggers immediate Claude response
  }
}

Behavior: If autonomousMessage is present, Claude sends that message to the user immediately after hook completes, regardless of session source (startup/resume/clear).

Example Hook Implementation

#!/bin/bash
# session_init.sh - Works for all three matchers

RULES_FILE="/path/to/MANDATORY_AI_RULES.md"

# Inject rules into Claude's context
cat "$RULES_FILE"

# Determine which lifecycle event triggered this
case "$SOURCE" in
  startup)
    MESSAGE="✅ MANDATORY_RULES loaded. Ready to work!"
    ;;
  resume)
    MESSAGE="✅ Session resumed - MANDATORY_RULES active"
    ;;
  clear)
    MESSAGE="✅ Context reset - MANDATORY_RULES reloaded"
    ;;
esac

# Output autonomous message (proposed feature)
echo "{\"autonomousMessage\": \"$MESSAGE\"}"

Alternative Design

Add a displayMessage field that shows directly in the UI without going through Claude:

{
  "hookSpecificOutput": {
    "hookEventName": "SessionStart",
    "additionalContext": "string",
    "displayMessage": "string"  // NEW: Shows in UI immediately
  }
}

Use Cases by Lifecycle Event

1. Startup - Critical Rules Confirmation

{
  "autonomousMessage": "✅ MANDATORY_RULES loaded (8 architectural patterns, 12 security policies)"
}

2. Resume - Continuity Assurance

{
  "autonomousMessage": "✅ Welcome back! Session resumed with your project rules active."
}

3. Clear - Fresh Start Validation

{
  "autonomousMessage": "✅ Context cleared and MANDATORY_RULES reloaded for fresh start"
}

4. Environment Validation (Any Matcher)

{
  "autonomousMessage": "⚠️ Warning: Database connection failed. Check .env configuration."
}

5. Project Health (Startup/Resume)

{
  "autonomousMessage": "ℹ️ 3 failing tests detected since last session. Run `npm test` to review."
}

Expected Behavior

Current Flow (All Matchers):

1. User action (start/resume/clear) → SessionStart hook runs → Context injected → Silence → User types prompt → Claude responds (with confirmation + answer)

Proposed Flow (All Matchers):

1. User action (start/resume/clear) → SessionStart hook runs → Context injected → Claude sends autonomous message → User sees confirmation → User types prompt → Claude responds (just the answer)

Technical Considerations

• Request-Response Architecture: Requires Claude Code to support "push" message flow after hooks
• Session State: Autonomous message fires once per lifecycle event (not on every message)
• Matcher Support: Must work for all three matchers: startup, resume, clear
• Input Schema: SessionStart hooks already receive "source": "startup|resume|clear" - leverage this
• Error Handling: If hook fails, no autonomous message (fail gracefully)

Benefits

1. User Confidence: Immediate feedback across ALL session states
2. Continuity Assurance: Users know rules survived resume/clear operations
3. Token Efficiency: No need to re-confirm rules in every first response
4. Better UX: Professional tools show state transitions (IDEs, databases, terminals)
5. Error Detection: Catch hook failures immediately, not after typing
6. Mental Model: Clear boundary between "loading" and "ready" states

Real-World Analogy

Modern development tools provide proactive status:

• IDEs: "Indexing complete", "Workspace ready", "Project reopened"
• Databases: "Connected to postgres://...", "Schema loaded"
• Terminals: "Environment activated: python3.11-venv"
• Docker: "Container started", "Health check passed"

Claude Code should do the same: "Rules loaded", "Session resumed", "Context reset"

Alternatives Considered

1. ❌ stderr output - Not displayed to users
2. ❌ Strict CLAUDE.md rules - Still requires user prompt first (our current workaround)
3. ❌ stdout formatting - Goes to Claude's context, not user's screen
4. ❌ External notification tools - Breaks the integrated experience
5. ❌ Manual /status command - Requires user action (defeats purpose)

Conclusion

In 2025, users expect intelligent tools to proactively communicate readiness across all lifecycle states. This isn't just about startup - it's about:

• Starting fresh: "Rules loaded, ready to work"
• Coming back: "Welcome back, rules still active"
• Resetting context: "Fresh start, rules reloaded"

This isn't about adding complexity - it's about matching modern UX expectations for professional development tools where confidence in system state is critical.

Users with strict coding standards, security policies, or architectural rules must know Claude understood them before starting any work - whether that's a new session, a resumed session, or a cleared session.

---

Related Issues: #3328, #4318 (SessionStart implementation)
Current Workaround: Strict CLAUDE.md instruction to greet on first response (suboptimal - still requires user prompt)
SessionStart Matchers: startup, resume, clear (all three need this feature)