← 2.1.2 Test tested · runtime-test

agent_type in SessionStart Hook — runtime test

Hands-on runtime battle-test of agent_type in SessionStart Hook. Result: PASS.

The agent_type field in SessionStart Hook is conditionally populated when a valid agent is specified via --agent, enabling hook logic to route, audit, or log based on the requested agent.

How It Works

SessionStart hooks receive an input JSON object that now includes an agent_type field if the session launched with --agent <agent-name>. The field contains the agent name string (e.g., "Explore", "test-agent-type"). When no agent is specified, the field is omitted entirely. This conditional presence allows hook scripts to detect and respond to agent-targeted sessions without requiring out-of-band configuration.

Test Setup and Results

A SessionStart hook was registered to capture raw input JSON during session startup. Five execution paths were tested:

  1. No agent flag: agent_type absent.
  2. Custom agent: claude --agent test-agent-type populated agent_type with the string "test-agent-type". PASS.
  3. Built-in agent: claude --agent Explore populated agent_type with "Explore". PASS.
  4. Invalid agent: claude --agent nonexistent-agent silently omitted agent_type; no error raised.
  5. Print mode with agent: SessionStart hook did not fire in -p mode when --agent was specified, suggesting mode-specific behavior differences.

The feature populates correctly for valid agents and fails safely (silent omission) for invalid ones.

Implications

Hook authors can now implement agent-aware routing: log Explore sessions differently than batch runs, gate certain automations to specific agents, or track which agents trigger which hooks in practice. The conditional field design avoids schema bloat in non-agent sessions while remaining backward-compatible.

Caveat

The -p print mode interaction remains untested and may represent a bug or intended behavior; further testing should clarify whether SessionStart hooks should fire in print mode at all.

Primary source
⎘ 2.1.2/tests/01-agent-type-hook/TEST-RESULTS.mdverbatim from the corpus

Test Results: agent_type in SessionStart Hook

Feature: Added agent_type to SessionStart hook input, populated if --agent is specified

Tested: 2026-01-16 Version: 2.1.2 features on 2.1.9

Test Setup

Created SessionStart hook that captures input JSON:

#!/bin/bash
cat > /tmp/agent-type-test/raw-input.json
echo '{}'

Registered in .claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/capture-hook.sh"
          }
        ]
      }
    ]
  }
}

Test Results

Test 1: Without --agent flag

Command: claude (interactive) Result: agent_type field NOT PRESENT

{
  "session_id": "205d1255-de10-4f28-b6cc-cd2b5dd95636",
  "hook_event_name": "SessionStart",
  "source": "startup"
  // No agent_type field
}

Test 2: With custom agent

Command: claude --agent test-agent-type Result: PASS - agent_type = "test-agent-type"

{
  "session_id": "3fe5949c-fbb2-429c-a639-08cf5ed6b34c",
  "hook_event_name": "SessionStart",
  "source": "startup",
  "agent_type": "test-agent-type"
}

Test 3: With built-in agent

Command: claude --agent Explore Result: PASS - agent_type = "Explore"

{
  "agent_type": "Explore",
  ...
}

Test 4: With non-existent agent

Command: claude --agent nonexistent-agent Result: agent_type field NOT PRESENT (silent failure)

The session starts but behaves as if no agent was specified. No error thrown.

Test 5: With -p print mode

Command: claude -p --agent test-agent-type "..." Result: INCONCLUSIVE - SessionStart hook did NOT fire in -p mode with --agent

However, -p WITHOUT --agent DID fire SessionStart. This might be a bug or intentional behavior difference.

Key Findings

  1. agent_type is conditional - Only present when valid --agent is specified
  2. Silent failure for invalid agents - Non-existent agents don't error, just omit the field
  3. Works with both custom and built-in agents - Explore, Plan, etc. all populate the field
  4. -p mode behaves differently - SessionStart may not fire consistently with --agent in print mode

JSON Schema

When --agent is specified with a valid agent:

{
  "session_id": "uuid",
  "transcript_path": "/path/to/transcript.jsonl",
  "cwd": "/current/working/directory",
  "hook_event_name": "SessionStart",
  "source": "startup|resume|clear|compact",
  "agent_type": "agent-name"  // ONLY present with valid --agent
}

Status: PASS

Feature works as documented. The agent_type field is populated when --agent is specified with a valid agent name.

Evidence & receipt
◇ ed25519 receipt
idtest_c8456e5844842b0c9985f3c4
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sig123ce9361b6a634c881546aa1ce15eb49abb6f80ffeb959e85199d1a3e027158cfad5057a39310f09879f289b44e28cf205e609ff30a5d645259b3118fc97e0e

Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.

Connected