S3 session roots work for Claude and Codex but nobody else. Adding Cursor (or any other single-file provider) means touching ~5 files and adding another case to 9 switch statements that already branch on agent type. That doesn't scale.
Today the S3 path is hardcoded: discoverClaudeS3 / discoverCodexS3 in the parser, agent-type switches in processS3Session, s3DiscoveredSessionID, statS3SourceObject, isS3AgentRootSegment, and the engine dispatch. Each new agent repeats the same boilerplate.
The building blocks for a generic approach are already there. s3PrefixScan is reusable, parseMaterializedS3Source is agent-agnostic, and most single-file providers (Cursor, Copilot, Gemini, Hermes, Codex forks, ...) would need zero sidecar handling.
Proposal:
- Add an optional S3 discovery interface to providers (scanner config, session ID derivation, stat, post-fetch hydrate). Provide a default implementation that covers the common single-file case.
- Replace the per-agent switches in
s3.go / s3_source.go / engine.go with interface dispatch.
- Claude and Codex keep custom implementations behind the interface (sidecars, fork reconciliation, index resolution).
- Any
FileBased provider with a single-file format can opt in by setting a capability flag, no new S3 code needed per agent.
~30 of the ~60 providers have single-file formats and could work with S3 out of the box. SQLite-backed and multi-file providers (Windsurf, Forge, RooCode, etc.) stay filesystem-only.
This would also unblock Cursor S3 support without adding yet another one-off scanner.
Happy to put up a PR for this.
S3 session roots work for Claude and Codex but nobody else. Adding Cursor (or any other single-file provider) means touching ~5 files and adding another case to 9 switch statements that already branch on agent type. That doesn't scale.
Today the S3 path is hardcoded:
discoverClaudeS3/discoverCodexS3in the parser, agent-type switches inprocessS3Session,s3DiscoveredSessionID,statS3SourceObject,isS3AgentRootSegment, and the engine dispatch. Each new agent repeats the same boilerplate.The building blocks for a generic approach are already there.
s3PrefixScanis reusable,parseMaterializedS3Sourceis agent-agnostic, and most single-file providers (Cursor, Copilot, Gemini, Hermes, Codex forks, ...) would need zero sidecar handling.Proposal:
s3.go/s3_source.go/engine.gowith interface dispatch.FileBasedprovider with a single-file format can opt in by setting a capability flag, no new S3 code needed per agent.~30 of the ~60 providers have single-file formats and could work with S3 out of the box. SQLite-backed and multi-file providers (Windsurf, Forge, RooCode, etc.) stay filesystem-only.
This would also unblock Cursor S3 support without adding yet another one-off scanner.
Happy to put up a PR for this.