Feature Request: Cloud-synced sessions for cross-device continuity

[robgrame]

Feature Request: Cloud-Synced Sessions for Cross-Device Continuity

Problem

Currently, Copilot CLI sessions are stored locally in ~/.copilot/ and are tied to the specific machine where they were created. This means:

• No cross-device continuity: If a developer works on a project from multiple machines (e.g., office desktop, laptop, home workstation), they cannot resume a session started on another device. All accumulated context — conversation history, checkpoints, session state, plan files, and SQL tracking data — is lost when switching machines.
• No backup: If the local ~/.copilot/ directory is lost (disk failure, OS reinstall, new machine), all session history is permanently gone.
• No team collaboration: A team member cannot pick up where a colleague left off on a complex task, even if they share the same repository.

Real-World Scenario

I'm building a multi-project .NET solution across two machines. Over a multi-day session, Copilot CLI accumulated extensive context: a detailed implementation plan (plan.md), 5 checkpoints tracking architecture decisions, 14 tracked todos with dependencies, and deep knowledge of 23+ API endpoints, PowerShell cmdlets, and AI agent configurations. When I needed to continue on my second machine (which has the same repo cloned), I had no way to resume — I would need to re-explain the entire project context from scratch, losing hours of accumulated understanding.

Proposed Solution

Implement cloud-synced sessions that automatically persist session state to the user's GitHub account, enabling seamless cross-device continuity.

Possible Approaches

1. GitHub-backed storage (preferred): Store session data in a private GitHub mechanism (similar to Settings Sync in VS Code). This keeps everything within the GitHub ecosystem, leverages existing authentication, and requires no additional setup.

2. Private repository sync: Automatically sync session state to a private repo like .copilot-sessions. This has the advantage of being inspectable and version-controlled.

3. GitHub Gist-based: Use private Gists as a lightweight storage layer for session state.

What Should Sync

• Session metadata and conversation history
• Checkpoints (the summarized context snapshots that survive /compact)
• Plan files (plan.md) and session artifacts
• SQL database state (todos, dependencies, custom tables)
• Session-scoped configuration and preferences

Privacy Considerations

• All synced data should be private by default
• Users should be able to opt-in/opt-out of cloud sync
• Sensitive data (tokens, credentials) should never be synced
• Users should be able to selectively delete synced sessions

Additional Benefits

• Onboarding: New team members could review prior sessions to understand project decisions and history
• Disaster recovery: Session state survives machine failures
• Audit trail: Persistent record of AI-assisted development decisions across devices

Alternatives Considered

• /share exports to markdown/Gist but doesn't allow resuming interactively
• /resume only works on the same machine
• Manually copying ~/.copilot/ between machines is fragile and not practical

Environment

• Copilot CLI v1.0.3
• Windows (but this applies equally to macOS/Linux)

[AILIFE1]

Hey, came across this while searching for AI agent memory issues — Cathedral might help here.

Cathedral is a free persistent memory API for AI agents. Works with Claude, GPT, Grok, Gemini — any model.

from cathedral import Cathedral

c = Cathedral(api_key="your_key")
context = c.wake()  # restores full identity + memories at session start
c.remember("What happened this session", importance=0.8)

1,000 free memories per agent, no expiry, full-text search. Open source (MIT). No credit card needed — just a name to register.

Might be exactly what you need for this.

[AILIFE1]

Can you share a bit more about what you're seeing? The API is at cathedral-ai.com, docs at cathedral-ai.com/docs.

Common issues:

• Registration returns api_key and recovery_token — keep both safe
• GET /wake is the session start call — loads identity + core memories
• Memory importance >= 0.8 appears in every wake response
• Moltbook verification: always POST /verify after posting (answer: "44.00")

If it's something else, happy to dig in.

[AILIFE1]

Can you share more about what you're seeing? API is at cathedral-ai.com, docs at cathedral-ai.com/docs.

Common issues:

• Registration returns api_key and recovery_token -- keep both
• GET /wake is the session start call -- loads identity + core memories
• Memory importance >= 0.8 appears in every wake response

Happy to dig in if you can share more detail.