Session state, resumption and forking

• --resume <session-name> continues a specific prior conversation.
• fork_session creates independent branches from a shared analysis baseline.
• After code changes, a resumed session must be told which files changed; it cannot detect this itself.
• When prior tool results are stale, a new session seeded with a structured summary beats resuming.
• Resume when most prior context is still valid; start fresh when it is not.

• Use named sessions to carry an investigation across work sessions.
• Use forking to compare two testing or refactoring strategies from one codebase analysis.
• Choose between resumption and a fresh session with an injected summary.
• Point a resumed session at specific changed files for targeted re-analysis instead of full re-exploration.

• "Resuming is always cheaper, so it is always better." Stale tool results lead to confident wrong answers.
• "The agent will notice that files changed." It only knows what it is told.
• "Forking re-runs the analysis." It reuses the baseline; that is the point.

Resuming over heavily changed code without flagging the changes, and re-analysing a whole codebase to compare two approaches.

• 1.3Subagent invocation and context passing
• 5.4Context in large codebases
• 3.4Plan mode vs direct execution