Which Nightly Job Wrote This Commit? Threading a Correlation Key Through Claude Code's Readable Session Names

Stamping the key into commits

When Claude Code makes a commit inside the repository, I want the correlation key attached to that commit message automatically. A prepare-commit-msg hook does this.

#!/usr/bin/env bash
# .git/hooks/prepare-commit-msg
# If CC_SESSION_NAME is set, append it to the commit message as a trailer.
set -euo pipefail
MSG_FILE="$1"
 
[ -n "${CC_SESSION_NAME:-}" ] || exit 0
 
# Do not write the same trailer twice (stay idempotent).
if grep -q "^Session-Name: ${CC_SESSION_NAME}$" "$MSG_FILE"; then
  exit 0
fi
 
printf '\nSession-Name: %s\n' "$CC_SESSION_NAME" >> "$MSG_FILE"

A Session-Name: line is read as a Git trailer — the same trailing-metadata mechanism as Signed-off-by:. The advantage is that it can be extracted mechanically, separately from the message body.

The commit message changes like this, before and after.

Before:

Update changelog for release

After:

Update changelog for 2.4.0 release
 
Session-Name: wallpaper-zen-changelog-draft-20260706-a1b2c3d4

It looks like one extra line, but that line erases the next morning's fifteen minutes.

Walking from a commit straight to its log

With the key present in all three places, tracing is just a walk. Given a commit SHA, this script pulls the correlation key from the trailer and shows the tail of the matching log.

#!/usr/bin/env bash
# trace.sh <commit-sha> — walk from a commit to its session and log
set -euo pipefail
SHA="$1"
 
# Pull the correlation key out of the trailer
KEY="$(git log -1 --format='%(trailers:key=Session-Name,valueonly)' "$SHA" | head -1)"
if [ -z "$KEY" ]; then
  echo "No session-name trailer on this commit: $SHA"
  exit 1
fi
 
# Extract the 8-digit date to locate the log. Grab the date with a regex so
# that hyphens in the app or task name do not break the parsing.
DATE_JST="$(printf '%s' "$KEY" | grep -oE '[0-9]{8}' | head -1)"
LOG="$HOME/nightly-logs/${DATE_JST}/${KEY}.log"
 
echo "Session name: $KEY"
echo "Log: $LOG"
echo "----"
if [ -f "$LOG" ]; then
  tail -n 20 "$LOG"
else
  echo "Log not found (retention window may have passed)"
fi

Type trace.sh a3f9c21 and the tail of the run that wrote that commit appears at once. The reverse direction uses the same key: spot a suspicious run in the logs, then git log --grep="Session-Name: <key>" pulls up every commit that session touched. Being able to move both ways, not just one, is the whole payoff of making the key a shared heading.

How much shorter it got

I timed "how long until I identify the source of a suspicious commit" three times, before and after.

When twelve sessions run in the same late-night window, matching on timestamps alone is effectively unreliable. Threading a single correlation key turned the morning investigation from searching into opening.

Where I stumbled

The design paid off cleanly, but two spots caught me for sure.

The first was the timezone. I got lazy at first and wrote date +%Y%m%d, so runs after 11 p.m. drifted their key date to the next day and split the log folder in two. For unattended overnight runs, anything that handles a date must state TZ=Asia/Tokyo explicitly. This is not unique to the correlation key — I have hit the same trap on log dates — so I now add it reflexively.

The second was key collision. Back when I built the key only from app, task, and date, running the same task for the same app manually as a retry collided with the nightly file name and nearly overwrote a log. The short random value at the end is not decoration; it is insurance that reliably separates runs made under the same minute and the same conditions. Four bytes proved plenty in practice.

One more small caution: the prepare-commit-msg hook runs before the commit is actually created, so any separate script that runs with --no-verify drops the trailer. On the unattended side, it is safest to decide up front never to use --no-verify.

Which approach to choose

There are alternatives to the commit trailer for where you stamp the correlation. You can write it directly into the commit body, or push it into a separate metadata file. I prefer the trailer approach. The reasons are that it extracts mechanically without hurting the readability of the message body, and that you can walk both directions using nothing but standard git log features. No external tools, no database.

That said, inspection-style tasks that never create a commit — the kind that only check a config and send a notification — have no commit, so the trailer cannot be used. In that case, put the correlation key as the first line of the notification message, and you can walk from the notification to the log. The stamping site differs, but the principle stays the same: thread one key through several records.

Readable session names, on their own, only make the screen slightly more pleasant. But once you redesign that name into a correlation key for your own operations, the traceability of unattended runs changes outright. For me it was a quiet but real step toward being able to trust those nightly jobs.

If you want to try it, start by changing tonight's run log file name into a correlation key and dropping in a single prepare-commit-msg hook. That alone means the next time you wonder "which run wrote this," the answer comes back with one grep.

Thank you for reading. I am still refining my own setup, and I would be glad to keep improving the transparency of unattended runs alongside you.