200 Sessões do Claude Code Com Nome ‘Untitled’ e Ninguém Sabe o Que É? Um Hook Resolve

Abre o histórico de sessões do Claude Code de qualquer dev do seu time. Vai lá, eu espero.

O que você vai encontrar? Uma lista de 50, 100, 200 sessões chamadas “Untitled”. Ou pior: “fix bug”, “teste”, “coisa do joao”, “asdff”. Agora tenta descobrir quem estava trabalhando no que, quando, e por quê. Boa sorte.

Isso não é um problema de ferramenta. É um problema de governance. E em software houses com 10, 20, 50 devs usando Claude Code diariamente, esse problema escala de forma brutal. Quando um dev sai de férias e você precisa continuar o trabalho dele, quando o tech lead quer entender o que o time produziu na sprint, quando você precisa auditar quanto tempo foi gasto em cada projeto — sessões sem nome são um buraco negro de informação.

Na v2.1.94, o Claude Code adicionou uma feature que parece pequena mas resolve um problema real: sessionTitle no hook UserPromptSubmit — a capacidade de nomear sessões automaticamente, sem nenhuma intervenção humana, toda vez que um dev envia um prompt.

O que é o sessionTitle hook

Antes dessa feature, existiam três formas de nomear uma sessão no Claude Code:

1. -n/--name na CLI (v2.1.76) — você passa o nome ao iniciar: claude -n "auth-refactor". Funciona, mas depende do dev lembrar de fazer isso. Spoiler: ninguém lembra.
2. /rename no chat (v2.1.75) — você renomeia manualmente durante a sessão. Mesmo problema: depende de disciplina individual.
3. Auto-naming from plans (v2.1.83) — o Claude gera um nome automático quando você usa o modo Plan. Melhor, mas só funciona com plans.

O sessionTitle hook é a quarta via — e a única que é 100% automática e customizável. Funciona assim: você configura um hook no evento UserPromptSubmit que retorna um campo sessionTitle no output JSON. Toda vez que qualquer dev envia um prompt, o hook roda, analisa o contexto, e define o título da sessão.

O dev não precisa fazer nada. Não precisa lembrar de nada. O nome aparece automaticamente.

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/caminho/para/naming-hook.sh"
          }
        ]
      }
    ]
  }
}

O hook recebe o prompt do usuário via stdin e retorna:

{
  "hookSpecificOutput": {
    "hookEventName": "UserPromptSubmit",
    "sessionTitle": "erp-fix/auth-JIRA-1234"
  }
}

Pronto. Sessão nomeada. Zero fricção.

Como implementar na prática

Aqui está onde a coisa fica interessante para software houses. O hook é um script shell (ou Python, ou Node — qualquer coisa que rode no terminal). Isso significa que você pode extrair informação de qualquer lugar para compor o nome da sessão.

Exemplo 1: Projeto + Branch + Ticket

O caso de uso mais comum. O script lê o branch atual do git e extrai o número do ticket:

#!/bin/bash
# naming-hook.sh

# Lê o prompt do usuário (recebido via stdin)
INPUT=$(cat)

# Pega o nome do projeto (pasta atual)
PROJECT=$(basename "$CLAUDE_PROJECT_DIR")

# Pega o branch atual
BRANCH=$(git -C "$CLAUDE_PROJECT_DIR" rev-parse --abbrev-ref HEAD 2>/dev/null || echo "no-branch")

# Extrai ticket do branch (ex: feature/JIRA-1234-auth -> JIRA-1234)
TICKET=$(echo "$BRANCH" | grep -oP '[A-Z]+-\d+' || echo "")

# Compõe o título
if [ -n "$TICKET" ]; then
  TITLE="$PROJECT | $BRANCH | $TICKET"
else
  TITLE="$PROJECT | $BRANCH"
fi

# Retorna JSON com sessionTitle
jq -n --arg title "$TITLE" '{
  "hookSpecificOutput": {
    "hookEventName": "UserPromptSubmit",
    "sessionTitle": $title
  }
}'

exit 0

Resultado: em vez de “Untitled”, a sessão aparece como “erp-api | feature/JIRA-1234-auth | JIRA-1234”.

Exemplo 2: Classificação automática por tipo de trabalho

Para quem quer ir além — usar o conteúdo do prompt para categorizar:

#!/bin/bash
INPUT=$(cat)
PROMPT=$(echo "$INPUT" | jq -r '.prompt')
PROJECT=$(basename "$CLAUDE_PROJECT_DIR")

# Classifica pelo conteúdo do prompt
if echo "$PROMPT" | grep -qi "fix\|bug\|erro\|broken"; then
  TYPE="BugFix"
elif echo "$PROMPT" | grep -qi "test\|spec\|jest\|vitest"; then
  TYPE="Testing"
elif echo "$PROMPT" | grep -qi "refactor\|clean\|melhora"; then
  TYPE="Refactor"
elif echo "$PROMPT" | grep -qi "feature\|implement\|cria\|adiciona"; then
  TYPE="Feature"
else
  TYPE="Dev"
fi

TITLE="[$TYPE] $PROJECT"

jq -n --arg title "$TITLE" '{
  "hookSpecificOutput": {
    "hookEventName": "UserPromptSubmit",
    "sessionTitle": $title
  }
}'
exit 0

Resultado: “[BugFix] erp-api” ou “[Feature] dashboard-v2”. Agora quando o tech lead olha o histórico, ele sabe instantaneamente o que cada sessão era.

Exemplo 3: Timestamp + Dev (para auditoria)

#!/bin/bash
INPUT=$(cat)
PROJECT=$(basename "$CLAUDE_PROJECT_DIR")
DEV=$(whoami)
DATE=$(date +%Y-%m-%d)

TITLE="$DATE | $DEV | $PROJECT"

jq -n --arg title "$TITLE" '{
  "hookSpecificOutput": {
    "hookEventName": "UserPromptSubmit",
    "sessionTitle": $title
  }
}'
exit 0

Resultado: “2026-04-10 | joao.silva | erp-api”. Rastreabilidade total.

Por que isso importa para sua Software House

Vou ser direto: session naming parece uma feature cosmética. Mas na escala de uma software house, é uma feature de governance.

Pense nos cenários reais:

1. Continuidade de trabalho

Dev saiu de férias no meio de uma feature. O substituto abre o Claude Code e vê 47 sessões “Untitled”. Quanto tempo ele perde até encontrar a sessão certa? Com naming automático, ele busca pelo ticket: “JIRA-1234” — encontrou em 2 segundos.

2. Auditoria de produtividade

O CTO quer saber: quanto do tempo do time está sendo gasto em bugs vs features novas? Com sessões nomeadas por tipo ([BugFix], [Feature], [Refactor]), você tem essa visibilidade sem precisar de nenhuma ferramenta extra.

3. Compliance e rastreabilidade

Para software houses que trabalham com clientes regulados (financeiro, saúde, governo), rastrear o que foi feito, quando e por quem não é opcional. O hook sessionTitle com timestamp + dev + projeto cria um audit trail automático.

4. Onboarding

Dev novo entra no time. Em vez de aprender “como a gente nomeia sessões aqui”, o hook já está configurado no .claude/settings.json do projeto. Ele clona o repo, abre o Claude Code, e todas as sessões já saem nomeadas no padrão da empresa. Zero explicação necessária.

Os números sustentam essa importância. Segundo a pesquisa do Pragmatic Engineer com 15.000 desenvolvedores, Claude Code é a ferramenta de AI coding mais usada, com 46% de aprovação. A adoção chega a 75% em empresas pequenas — exatamente o perfil de software houses. E com 78% das organizações globais usando AI tools diariamente, a questão não é mais se o time vai usar Claude Code. É se você vai ter visibilidade sobre como eles usam.

O ecossistema de hooks está amadurecendo

O sessionTitle não existe isolado. Ele faz parte de um ecossistema de hooks que cresceu significativamente nas últimas versões. Hoje o Claude Code oferece 25 eventos de hook — desde SessionStart até WorktreeCreate, passando por PreToolUse, Stop, ConfigChange, FileChanged e mais.

E o mais relevante para software houses: hooks podem ser de três tipos:

1. Command hooks — scripts shell determinísticos (como o sessionTitle)
2. Prompt hooks — usam um modelo Claude (Haiku por padrão) para decisões que exigem julgamento
3. Agent hooks — subagentes com acesso a ferramentas para verificações complexas

Isso significa que você pode construir um sistema completo de governance com hooks: nomear sessões automaticamente (sessionTitle), validar comandos antes da execução (PreToolUse), bloquear edits em arquivos protegidos, rodar testes antes de permitir que o Claude pare (Stop hook), e auditar tudo num log centralizado.

Tudo configurável via JSON. Tudo versionável no git. Tudo replicável entre projetos.

O que eu penso

Na minha experiência com 300+ software houses, o problema de governance com ferramentas de IA é real e está crescendo. Não porque as ferramentas são ruins — pelo contrário, são tão boas que todo mundo quer usar. O problema é que sem padronização, cada dev usa do seu jeito, e a empresa perde visibilidade.

O sessionTitle hook é um exemplo perfeito de como o Claude Code está evoluindo de “ferramenta para dev individual” para “plataforma para times”. Não é uma feature que faz o Claude escrever código melhor. É uma feature que faz a empresa funcionar melhor quando 20 devs estão usando Claude Code simultaneamente.

E o investimento é mínimo. Um script de 15 linhas no settings.json do projeto. Cinco minutos de setup. E a partir daí, toda sessão de todo dev sai nomeada automaticamente com projeto, branch e ticket. Sem treinamento. Sem manual. Sem depender da disciplina de ninguém.

Se você está esperando a feature “perfeita” para começar a implementar governance de IA na sua software house, está esperando errado. Governance se constrói com features pequenas, bem configuradas, que funcionam sem fricção. O sessionTitle hook é exatamente isso.

Se você quer implementar esse nível de automação e governance com IA na sua software house, o caminho começa com um settings.json bem configurado. O resto o Claude Code faz.

Sou Thulio, mentoro 300+ SHs desde 2016.