KI-Coding-Sessions ueber mehrere Rechner synchronisieren
Ein Entwickler beschreibt die Herausforderung, mit Agenten wie Claude Code, Codex CLI, Cursor und Gemini CLI auf mehreren Maschinen zu arbeiten, da jeder Agent seinen Verlauf lokal und in eigenem Format speichert.
I work across more than one machine, and I switch between coding agents depending on the task: Claude Code, Codex CLI, Cursor, Gemini CLI. The models keep getting better, but the context is still nailed to one laptop.
Every agent stores its history differently, and locally:
Copying the project folder is not enough, because session files live outside it. Copy them to a new machine and the paths may not match either. So "continue where I left off" turns into manual file archaeology.
I built AIAssets to fix that for my own workflow.
AIAssets is a self-hosted hub. On each machine it scans the session files of the agents it supports, indexes them, and syncs the index and session data bidirectionally through the hub on a 60-second poll. Session titles are preserved, so you can find the thread you were in. Over that index it also gives you search, share, and backup.
Self-hosting is a deliberate choice: transcripts contain source code, internal URLs, and sometimes commands with credentials in them. I did not want a third-party service holding all of that.
The README lists 10 agents with read/write support, including Claude Code, Codex, Cursor, and Gemini CLI. It is early software, so the limits matter more than the feature list:
1. Project path mapping. A session is tied to a working directory. If machine A uses /Users/me/code/foo and machine B uses D:\code\foo, restoring on B can show the session but fail to resume because the cwd does not exist. Should the hub rewrite paths, or store a logical project ID? I lean toward the latter, but it is not shipped.
2. Divergent branches. The same session continued on two machines creates two files. Last-write-wins loses one side. A real merge of JSONL transcripts is harder than it sounds, and I would rather not fake it.
3. Size and transport. Sessions can get large. Polling the full hub every 60 seconds is fine on a LAN and wasteful over a metered connection. Incremental transfer is on the list.
If you run more than one machine or more than one agent, I would rather hear which part breaks first than get a star. Issues with your setup — OS, agents, where the sessions live — are more useful than "doesn't work".