Summary
The original product scope (ideas/03-loopctl.md) lists Gemini CLI as a supported data source alongside Claude Code and Codex CLI. It is not yet implemented.
Why it's deferred rather than built now
Per the Phase 1 config/integrations plan, Gemini CLI's on-disk session format is architecturally close enough to Claude Code's (~/.gemini/tmp/<project_hash>/chats/*.jsonl — a per-project directory containing per-session JSONL files) that it should fit the existing Discoverer/Parser/Tailer interfaces directly, with no new dependency.
However, the exact field names (sessionId vs session_id, per-turn token field names, message array shape) were reconstructed from documentation and third-party reverse-engineering writeups, not confirmed against a real file on disk. Implementing a parser against unverified field names risks silently mis-parsing real sessions (wrong costs, dropped events) in a way that's hard to detect without a real Gemini CLI installation to test against.
What's needed before implementation
- Verification spike: install Gemini CLI, run one real session, inspect the actual bytes written to
~/.gemini/tmp/<hash>/chats/*.jsonl, and confirm the real field names.
- Implement
internal/source/gemini.go (Discoverer) and internal/parser/gemini.go (Parser), following the exact pattern of internal/source/codex.go / internal/parser/codex.go.
- Wire into
Collector.discoverers in internal/source/collector.go, gated by a sources.gemini: auto|disabled config key (add to internal/config/config.go's SourcesConfig and the config init template).
- Add unit tests mirroring
internal/parser/codex_test.go and internal/source/discovery_test.go.
Effort estimate
Comparable to the existing Codex discoverer + parser (~75 + ~130 lines) plus the verification spike. Low-moderate schema stability risk since Gemini CLI is a maintained Google product with public docs.
Why this is a good issue for a contributor
This is fully scoped, follows an existing pattern in the codebase twice over (Claude, Codex), and just needs someone with Gemini CLI installed to do the verification spike and confirm field names before writing the parser.
Summary
The original product scope (
ideas/03-loopctl.md) lists Gemini CLI as a supported data source alongside Claude Code and Codex CLI. It is not yet implemented.Why it's deferred rather than built now
Per the Phase 1 config/integrations plan, Gemini CLI's on-disk session format is architecturally close enough to Claude Code's (
~/.gemini/tmp/<project_hash>/chats/*.jsonl— a per-project directory containing per-session JSONL files) that it should fit the existingDiscoverer/Parser/Tailerinterfaces directly, with no new dependency.However, the exact field names (
sessionIdvssession_id, per-turn token field names, message array shape) were reconstructed from documentation and third-party reverse-engineering writeups, not confirmed against a real file on disk. Implementing a parser against unverified field names risks silently mis-parsing real sessions (wrong costs, dropped events) in a way that's hard to detect without a real Gemini CLI installation to test against.What's needed before implementation
~/.gemini/tmp/<hash>/chats/*.jsonl, and confirm the real field names.internal/source/gemini.go(Discoverer) andinternal/parser/gemini.go(Parser), following the exact pattern ofinternal/source/codex.go/internal/parser/codex.go.Collector.discoverersininternal/source/collector.go, gated by asources.gemini: auto|disabledconfig key (add tointernal/config/config.go'sSourcesConfigand theconfig inittemplate).internal/parser/codex_test.goandinternal/source/discovery_test.go.Effort estimate
Comparable to the existing Codex discoverer + parser (~75 + ~130 lines) plus the verification spike. Low-moderate schema stability risk since Gemini CLI is a maintained Google product with public docs.
Why this is a good issue for a contributor
This is fully scoped, follows an existing pattern in the codebase twice over (Claude, Codex), and just needs someone with Gemini CLI installed to do the verification spike and confirm field names before writing the parser.