Repository navigation
Description
Problem
When resuming a session with claude --resume <session-id>, the CLI creates a new JSONL file and starts streaming only new messages. There's no built-in way to get historical messages from the previous session through the CLI's stdout stream.
This forces developers integrating Claude Code to implement complex workarounds:
- Manually parse JSONL files from
~/.claude/projects/ - Load historical messages before starting the CLI process
- Merge historical and streaming data with different parsing logic
- Handle deduplication and synchronization issues
Current Workaround
Currently, integrations must:
- Read and parse
.jsonlfiles directly from the filesystem - Implement custom JSONL parsers to extract historical messages
- Load history separately before starting the CLI process
- Maintain two different data pipelines (file-based for history, stream-based for new messages)
- Handle potential format inconsistencies between parsed files and streamed output
This approach has several issues:
- Duplicate parsing logic for files vs stream
- Risk of format inconsistencies
- Complex state management
- No guarantee that file format won't change
- Requires filesystem access permissions
Proposed Solution
Add an --include-history flag that streams historical messages before entering interactive mode:
claude --resume <session-id> --output-format json --include-historyExpected behavior:
- First, output all historical messages from the resumed session in chronological order
- Clearly mark the boundary between historical and new messages using one of these approaches:
- Add an
"isHistorical": truefield to historical message entries - Output a special delimiter entry like
{"type": "history_delimiter"}after all historical messages - Include metadata in each entry indicating its source (e.g.,
"source": "history"vs"source": "live")
- Add an
- Then seamlessly transition to streaming new messages in real-time
- Use the same JSON format structure for both historical and new messages
Benefits
- Unified data source: All messages come from stdout, no file parsing needed
- Consistent format: Same parsing logic for all messages
- Clear boundaries: Developers can easily distinguish historical from new messages
- Simplified integration: Remove need for filesystem access and custom parsers
- Future-proof: CLI handles any format changes internally
- Better performance: No need to read potentially large JSONL files
Related Issue
This request is related to anthropics/claude-code-sdk-python#109, where we initially requested similar functionality for the Python SDK. However, this feature would be better implemented at the CLI level, making it available to all SDKs and integrations.
Use Cases
- Chat UI applications that need to display conversation history
- Session analysis tools
- Debugging tools that need full conversation context
🤖 Generated with Claude Code
Activity
coygeek commentedon Aug 24, 2025
Hey, this is a really well-thought-out feature request. I've been building some tooling around the SDK myself and ran into the exact same issue. Having to build a separate file parser just to load the history is definitely a pain point, especially since the local file format could change in the future. A unified stream from stdout would be a huge improvement for developers.
While we wait for the team to hopefully implement something like your
--include-historyflag, I've been using a workaround that combines locating the transcript file with launching the process. It's not perfect, and it still has the filesystem dependency you mentioned, but it might be a bit more structured than what you're doing now.Based on the documentation, we know a few key things:
SessionStarthook receives atranscript_pathin its JSON inputThis means the path is predictable if you have the session ID. The integration script that's launching
claudecan construct the path to the transcript file itself, read it, stream the history, and then immediately start streaming the live output from theclaudesubprocess.Here’s a rough sketch of how that might look in a Python script:
This still has the downsides of relying on the file format, but it centralizes the logic in one place before you kick off the live stream. Your main application logic can just consume this unified stream.
Anyway, just wanted to share my approach in case it helps. I'm definitely giving a +1 to your feature request. It would make building robust integrations so much easier. Cheers
github-actions commentedon Dec 7, 2025
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
github-actions commentedon Jan 7, 2026
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
github-actions commentedon Jan 14, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.