Sessões: estado, resumption e forking
Objetivos de aprendizagem
- Retomar sessões nomeadas com
--resume <nome-da-sessão>para continuar investigações entre dias de trabalho. - Usar
fork_sessionpara criar ramificações independentes a partir de uma baseline de análise compartilhada. - Decidir entre retomar a sessão (contexto anterior ainda válido) e começar sessão nova com resumo estruturado injetado (tool results antigos ficaram obsoletos).
- Informar o agente, ao retomar, sobre quais arquivos analisados mudaram — habilitando re-análise direcionada em vez de re-exploração completa.
Sessões e retomada nomeada
No Claude Code / Agent SDK, cada conversa é uma sessão com estado persistido (histórico, resultados de ferramentas, entendimento acumulado do codebase). Uma investigação longa — ex.: "mapear as dependências do fluxo de reembolso" — pode ser retomada dias depois com --resume apontando a sessão específica, sem repetir a exploração:
# Dia 1: investigação longa em uma sessão nomeada
claude "Mapeie as dependencias do fluxo de reembolso"
# Dia 3: retomar exatamente aquela investigação, com todo o contexto
claude --resume refund-flow-investigation \
"Continue de onde paramos: gere o relatorio de acoplamento"
Vantagem: o entendimento construído (arquivos lidos, arquitetura inferida, decisões tomadas) continua disponível. Custo/risco: o contexto retomado pode estar desatualizado em relação ao estado real do código — o tema da seção seguinte.
Retomar, avisar sobre mudanças, ou recomeçar?
O task statement 1.7 cobra três decisões distintas:
| Situação | Decisão correta |
|---|---|
| O contexto anterior continua majoritariamente válido (código não mudou, ou mudou pouco). | Retomar a sessão (--resume) e seguir o trabalho. |
| Alguns arquivos analisados mudaram desde a última sessão. | Retomar e informar explicitamente quais arquivos mudaram ("payment_service.py e refund_handler.py foram refatorados; re-analise-os antes de continuar") — re-análise direcionada, sem re-exploração completa. |
| Os tool results antigos estão amplamente obsoletos (refatoração grande, muito tempo passado, dados dinâmicos). | Começar sessão nova, injetando no prompt inicial um resumo estruturado das conclusões válidas (decisões, arquitetura, próximos passos) — mais confiável do que deixar o modelo raciocinar sobre conteúdo stale que ele ainda "acredita" ser verdade. |
Por que não retomar sempre? Tool results antigos no histórico continuam parecendo fatos para o modelo. Se o código mudou, o agente raciocina sobre uma foto velha — com confiança. Resumo estruturado numa sessão limpa carrega as conclusões sem carregar as evidências vencidas.
fork_session: explorar caminhos divergentes
Cenário do exam guide: você investiu uma sessão inteira analisando o codebase e agora quer comparar duas estratégias diferentes (ex.: duas abordagens de testes, ou duas rotas de refatoração) partindo da mesma baseline de análise. Retomar a mesma sessão duas vezes contaminaria um caminho com o outro. A solução é fork_session: cada retomada com fork cria uma ramificação independente — as duas herdam a baseline, mas evoluem isoladas, sem poluir a sessão original.
import anyio
from claude_agent_sdk import query, ClaudeAgentOptions
BASELINE_SESSION = "8f2c1e34-analise-do-codebase" # sessao com a analise pronta
async def explore(approach_prompt):
options = ClaudeAgentOptions(
resume=BASELINE_SESSION, # parte da baseline compartilhada...
fork_session=True, # ...mas em um branch independente
allowed_tools=["Read", "Grep", "Glob"],
)
result_text = []
async for message in query(prompt=approach_prompt, options=options):
result_text.append(str(message))
return "\n".join(result_text)
async def main():
plan_a = await explore(
"Partindo da analise ja feita, proponha uma estrategia de testes "
"baseada em testes de integracao por fluxo de negocio."
)
plan_b = await explore(
"Partindo da analise ja feita, proponha uma estrategia de testes "
"baseada em testes unitarios por modulo com mocks."
)
print("=== Abordagem A ===")
print(plan_a)
print("=== Abordagem B ===")
print(plan_b)
anyio.run(main)
flowchart TD
S[Sessão baseline
análise completa do codebase] -->|fork_session| A[Branch A
estratégia: integração]
S -->|fork_session| B[Branch B
estratégia: unit + mocks]
A --> CMP[Comparar propostas
e escolher]
B --> CMP
S -.->|sessão original
permanece intacta| S
Pegadinhas da prova
- Distrator típico: retomar a sessão após uma grande refatoração "porque o contexto acumulado é valioso". Se os tool results estão obsoletos, retomar propaga um retrato falso; o correto é sessão nova + resumo estruturado injetado.
- Distrator típico: o inverso — recomeçar do zero (re-explorar tudo) quando só dois arquivos mudaram. O correto é retomar e apontar os arquivos alterados para re-análise direcionada.
- Distrator típico: comparar duas abordagens retomando a mesma sessão duas vezes em sequência. A segunda exploração herda as conclusões da primeira (contaminação); use
fork_sessionpara branches independentes. - Distrator típico: refazer manualmente a análise inteira em duas sessões novas para comparar abordagens — joga fora a baseline compartilhada que o fork reaproveita de graça.
- Distrator típico: confiar que o agente "vai perceber" que os arquivos mudaram ao retomar. Ele não percebe: os tool results antigos continuam no histórico como se fossem atuais — avisar é responsabilidade de quem retoma.
Resumo em 5 linhas
- Sessões persistem o estado da investigação;
--resume <nome>retoma uma sessão específica entre dias de trabalho. - Contexto anterior válido → retomar; arquivos pontuais mudaram → retomar informando quais para re-análise direcionada.
- Tool results amplamente obsoletos → sessão nova com resumo estruturado injetado (conclusões sem evidências vencidas).
fork_sessioncria branches independentes a partir de uma baseline compartilhada — ideal para comparar abordagens divergentes sem contaminação.- O agente não detecta sozinho que o mundo mudou desde a última sessão: quem retoma precisa dizer o que mudou.
Documentação oficial
Questões de fixação
1. Você quer comparar duas estratégias de refatoração partindo da mesma análise de codebase feita ontem numa sessão longa. Qual é o mecanismo adequado?
Gabarito: C. Fork reaproveita a baseline e isola os caminhos. A contamina: a segunda exploração herda as conclusões da primeira na mesma linha de sessão. B desperdiça a análise já feita (tempo e tokens). D degrada o estado rico da sessão a texto colado, perdendo os artefatos de ferramenta e o mecanismo de sessão.
2. Desde a última sessão de investigação, apenas payment_service.py foi refatorado; o restante do código está igual. Qual é a melhor forma de continuar o trabalho?
Gabarito: B. Contexto majoritariamente válido + mudança pontual = retomar com aviso explícito para re-análise direcionada. A desperdiça toda a investigação por causa de um arquivo. C é falsa: os tool results antigos permanecem no histórico como se fossem atuais — o agente não percebe a mudança. D garante que o agente raciocine sobre uma versão obsoleta do arquivo.
3. A investigação anterior tem duas semanas e, desde então, o time reescreveu metade do módulo estudado. Você precisa continuar o trabalho. O que fazer?
Gabarito: D. Com tool results amplamente obsoletos, sessão nova + resumo estruturado é mais confiável: carrega as conclusões sem as evidências vencidas. A e B mantêm no contexto uma foto velha que o modelo trata como fato ("desconfie" é instrução probabilística sobre dados que parecem legítimos). C resolve outro problema (branches divergentes), não o de staleness — o fork herda o mesmo contexto obsoleto.
4. Qual comando retoma uma investigação específica iniciada em outro dia no Claude Code?
Gabarito: A. --resume com o identificador da sessão é o mecanismo documentado de retomada nomeada. B e D são flags inexistentes (distratores clássicos de flag inventada). C roda em modo não interativo uma nova conversa — o texto "continue a sessão anterior" não recupera estado algum, pois a nova sessão não tem acesso ao histórico da antiga.