Local-first export of your own Claude conversations, project docs, and memory to Markdown.

What it does

Schrödinger-Sync exports data from your own Claude account on your own Windows session into local Markdown. The output can be searched directly, versioned, backed up, or ingested by a local memory system such as MemPalace.

Current provider support is deliberately narrow:

Provider	Status	Current method
Claude	supported	Claude Desktop cookie store + real Chrome/CDP
ChatGPT	planned	not implemented
Gemini	planned	not implemented
Copilot	planned	not implemented

Provider rows marked planned are roadmap items, not partial support.

Why it exists

Conversation state is split across web, desktop, IDE, and local tooling. Schrödinger-Sync provides a local export layer so continuity does not depend on manually copying context between those surfaces.

The project favors inspectable local files over a hosted sync service. There is no telemetry and no third-party storage path in the current implementation.

Security boundary

This tool handles an authenticated browser secret. Treat that as credential-adjacent code and read SECURITY.md before running it.

Current implementation facts:

• it reads the Claude Desktop cookie store under the current Windows user;
• it queries and decrypts only the sessionKey cookie row needed for the session;
• the raw AES master key and decrypted plaintext buffer are zeroed after their last read, while the returned sessionKey string remains in memory for the active session by design;
• the secret is registered with the output redactor before use;
• Chrome is launched visibly (headless=false) because the login path must clear the real browser challenge;
• application-controlled network requests are constrained to claude.ai, with regression tests around that boundary;
• exported content is written locally.

Those controls reduce risk; they do not turn credential handling into a zero-risk operation. The threat model, test boundaries, temporary cookie-copy footprint, and memory caveats are documented in SECURITY.md.

How the current Claude path works

Claude Desktop profile
    -> read Local State + Cookies as the current Windows user
    -> decrypt the sessionKey row
    -> launch a visible, dedicated Chrome profile
    -> inject sessionKey into that browser session
    -> let the browser clear the claude.ai challenge
    -> perform same-origin API requests
    -> write conversations / project docs / memory to local Markdown

Claude Desktop must have been installed, opened, and logged into at least once. Harvesting needs access to its cookie database; if Desktop is holding that database locked, close Desktop before the harvest cycle. The daemon modes include process gating around this constraint.

Install

Download SchroedingerSyncSetup.exe and SHA256SUMS from the latest release.

Releases are currently unsigned, so Windows SmartScreen may warn. To inspect the downloaded file hash in PowerShell:

Get-FileHash .\SchroedingerSyncSetup.exe -Algorithm SHA256

Compare the reported value with the corresponding entry in SHA256SUMS from the same release.

Build from source:

go build -trimpath -ldflags "-s -w" -o schroedinger-sync.exe .

Commands

schroedinger-sync.exe smoke          auth/export smoke test
schroedinger-sync.exe harvest        full export
schroedinger-sync.exe probe          API/surface discovery diagnostics
schroedinger-sync.exe watch          continuous sync loop
schroedinger-sync.exe supervise      sync loop gated by active work surfaces
schroedinger-sync.exe tray           sync loop with system-tray UI
schroedinger-sync.exe install-task   register per-user logon startup
schroedinger-sync.exe uninstall-task remove logon startup
schroedinger-sync.exe cleanup-temp   remove this tool's known temporary leftovers

watch, supervise, and tray share the incremental sync engine and persisted sync state. See the source and changelog for exact lifecycle behavior rather than assuming they are Windows services: they run in the interactive user session because DPAPI and visible Chrome both depend on that session.

Output and integrity

Exports are local Markdown under the configured output directory. Since v2.2.0, successful writes also record SHA-256 values in .content-hashes.json.

That manifest is currently write-side integrity metadata. End-to-end read-back verification from a separate ingest/store is a separate roadmap item; the README does not treat the manifest alone as proof that another system stored the same bytes.

Testing

go test ./...

The suite includes regression tests around security-sensitive behavior such as secret redaction and selected architectural invariants. SECURITY.md states what those tests do and, importantly, what they do not prove.

Current scope

The project is actively evolving. The strongest-supported path today is Windows + Claude Desktop + local Markdown export. Multi-provider support, stronger at-rest protection, additional integrity verification, signing, and enterprise features remain future work until they exist in code and releases.

Licensing

The open-source core is GNU AGPLv3. A separate commercial licence is available for organizations that need proprietary embedding or redistribution without the AGPL copyleft requirements.

External contributions are covered by the Contributor License Agreement. See CONTRIBUTING.md for the contribution path and SECURITY.md for vulnerability reporting and the detailed threat model.