← 2.1.10 Test inconclusive · runtime-test

Combo Test: Session-Aware Setup — runtime test

Hands-on runtime battle-test of Combo Test: Session-Aware Setup. Result: INCONCLUSIVE.

A setup hook receiving session_id can create session-scoped temporary state accessible across a session lifetime.

Test Setup

This test combined two features from Claude 2.1.10: the setup hook (fires on --init) and the session_id field passed to hooks. A bash hook script read the session_id, created a temporary directory at /tmp/claude-sessions/{session_id}/, and logged the setup trigger and working directory to setup.log.

What Happened

Running echo "hi" | claude --init -p invoked the setup hook. The hook received the session_id (UUID a5f6bfff-d19c-4b6d-b9c8-e71eb16a9661), created the session directory, and wrote a setup log showing trigger init and CWD /Users/ryanhunter/projects/claude/claude-feature-demos. The directory persisted and was readable after the hook exited.

Why It Matters

This pattern enables three practical scenarios: session-scoped temp files that clean up with the session, cross-tool state sharing (setup creates a known directory that later hooks can read), and centralized session activity logging. It shifts setup from global initialization to per-session workspace preparation.

Caveats

The test validated that the hook ran and state was created, but did not verify cleanup behavior after session end—directories persisted on disk, raising an open question about whether post-session cleanup is a feature or oversight. The session_id is a guaranteed unique UUID per session, suitable for use as a state key.

Primary source
⎘ 2.1.10/tests/combo-01-session-aware-setup/TEST-RESULTS.mdverbatim from the corpus

Combo Test: Session-Aware Setup

Workflow: Setup hook + session_id for session-specific state Status: VALIDATED ✅ Tested: 2026-01-16

Features Combined

  • Setup hook (2.1.10) - fires on --init
  • session_id in hook input - enables per-session state

Hypothesis

Setup hooks can create session-specific temporary state that persists for the session's lifetime.

Implementation

Hook: ~/.claude/hooks/setup-session-aware.sh

#!/bin/bash
INPUT=$(cat)
SESSION_ID=$(echo "$INPUT" | jq -r '.session_id')
TRIGGER=$(echo "$INPUT" | jq -r '.trigger')
CWD=$(echo "$INPUT" | jq -r '.cwd')

# Create session-specific temp dir
SESSION_DIR="/tmp/claude-sessions/$SESSION_ID"
mkdir -p "$SESSION_DIR"

# Log setup details
echo "Setup at $(date)" > "$SESSION_DIR/setup.log"
echo "Trigger: $TRIGGER" >> "$SESSION_DIR/setup.log"
echo "CWD: $CWD" >> "$SESSION_DIR/setup.log"

echo "{\"setup_dir\": \"$SESSION_DIR\", \"trigger\": \"$TRIGGER\"}"

Settings Configuration

"hooks": {
  "Setup": [{
    "hooks": [{
      "type": "command",
      "command": "bash ~/.claude/hooks/setup-session-aware.sh"
    }]
  }]
}

Test Results

Command

echo "hi" | claude --init -p

Result

Session directory created at /tmp/claude-sessions/{session_id}/:

/tmp/claude-sessions/a5f6bfff-d19c-4b6d-b9c8-e71eb16a9661/
└── setup.log

Contents of setup.log:

Setup at Fri Jan 16 22:02:52 PST 2026
Trigger: init
CWD: /Users/ryanhunter/projects/claude/claude-feature-demos

Use Cases Enabled

  1. Session-scoped temp files - Intermediate results that clean up with session
  2. Cross-tool state sharing - Setup creates dir, later hooks can read/write
  3. Session logging - Centralized session activity tracking
  4. Workspace preparation - Create working directories before session starts

Notes

  • session_id is a UUID, guaranteed unique per session
  • Directory can be passed to later hooks via env var or known path convention
  • Consider cleanup: directories persist after session ends (feature or bug?)
Evidence & receipt
◇ ed25519 receipt
idtest_4ce734fc359741a5f2371819
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sig9212d0fbafa885ff143eb89aa6e7a56bea33e865716f10e8a846095c6e69e1dceacbcdcf55507697f2c1ffbb47b999a1987350b5e57dc7d9da6baf3ead3e3f0d

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