This was generated by AI during triage.
Idea
Mine the local Claude Code transcripts under ~/.claude/projects/<encoded-path>/<sessionId>.jsonl (already discoverable via ClaudeSessionService) to surface cross-session knowledge inside CodeShellManager.
Proposed analytics
- Token usage over time — daily / weekly trend of input + output (+ cache read/write) tokens, total and per project.
- Tool-use breakdown — which tools are invoked most (Read, Edit, Bash, Grep, Agent, MCP tools, …), counts and trends.
- Project usage — how much time / how many turns / how many tokens each working folder has consumed.
- Cost estimate — derive an estimated $ figure from the token counts and current model pricing (configurable).
- Session leaderboard — longest sessions, biggest single turns, sessions with most retries / errors.
These could live in a new "Insights" / "History" panel (modal or sidebar pane), with simple charts and a filterable per-project / per-day table.
Indexing for search
- Parse each
.jsonl once and store the human-readable text (user prompts + assistant text + tool inputs/outputs) into the existing FTS5 SQLite database owned by SearchService — likely a new virtual table claude_history keyed by (session_id, project_path, ts).
- Then global search hits would surface matches from old Claude conversations alongside terminal output and project notes (
SearchResultType.ClaudeMessage or similar).
- Incremental refresh: watch mtimes; only re-parse files newer than last scan. Background job at startup + periodic, or on-demand.
Open questions
- Storage budget — these transcripts can be huge; we may want to only index text fields and skip large embedded tool outputs over a threshold.
- Privacy / portability — keep everything local; no upload. Probably want a setting to disable indexing entirely.
- Time-zone handling for the per-day chart.
Relevant pointers in the codebase
src/CodeShellManager/Services/ClaudeSessionService.cs — already maps WorkingFolder → ~/.claude/projects/<dir> and finds the latest session id; the same path-encoding logic is the entry point for the scanner.
src/CodeShellManager/Services/SearchService.cs — owns the FTS5 schema and project_notes; new claude_history table would live here alongside the existing ones.
src/CodeShellManager/Terminal/OutputIndexer.cs — pattern for async, channel-fed batched SQLite writes; the importer could borrow this shape.
Idea
Mine the local Claude Code transcripts under
~/.claude/projects/<encoded-path>/<sessionId>.jsonl(already discoverable viaClaudeSessionService) to surface cross-session knowledge inside CodeShellManager.Proposed analytics
These could live in a new "Insights" / "History" panel (modal or sidebar pane), with simple charts and a filterable per-project / per-day table.
Indexing for search
.jsonlonce and store the human-readable text (user prompts + assistant text + tool inputs/outputs) into the existing FTS5 SQLite database owned bySearchService— likely a new virtual tableclaude_historykeyed by(session_id, project_path, ts).SearchResultType.ClaudeMessageor similar).Open questions
Relevant pointers in the codebase
src/CodeShellManager/Services/ClaudeSessionService.cs— already mapsWorkingFolder→~/.claude/projects/<dir>and finds the latest session id; the same path-encoding logic is the entry point for the scanner.src/CodeShellManager/Services/SearchService.cs— owns the FTS5 schema andproject_notes; newclaude_historytable would live here alongside the existing ones.src/CodeShellManager/Terminal/OutputIndexer.cs— pattern for async, channel-fed batched SQLite writes; the importer could borrow this shape.