I went the opposite way, and I think it's worth mentioning the cost of that choice. My conversation doesn't carry over. Only what a session explicitly recorded does. This includes decisions, open questions, verified items, and what's left to do. Anything that wasn't recorded is gone, and that's a real loss, not just a small part of the process.

I went with this approach because the transcript doesn't go into a file; it goes into another live session, which messes up its flow. We've already talked about this a bit when we were discussing "how to make reading Markdown cheaper." My answer was different: don't bring it over at all. The next session doesn't need to know how we got there—it just needs to know what we decided and what we've actually verified.

I don't think we've talked about this in this thread yet. Portability is all about a session that's already wrapped up. I often have two sessions open at the same time. One is building an endpoint, and the other is the screen that calls it. They need to ask each other before both build on different assumptions. Moving the transcript around won't fix this. What's needed is a message, not a copy.

I made a small open-source layer for this: a mailbox and a "walkie-talkie" for sessions in the clients you've already opened - https://github.com/automatis-tools/agents-can-communicate. It doesn't transfer memory and doesn't detect discrepancies on its own. The session has to check for those things.

I have made simple macos app to export my claude sessions to markdown(plus ordinal jsonl) and i just continuously sync it to dropbox.

i do the same for apple notes and imessage. so very portable

https://apps.apple.com/us/app/exporter-notes-to-markdown/id6...

Love this. Easily the most annoying thing about modern Agent development across Claude, Codex, etc. One nit: You don't auto-discover "archived" chats from Codex. They have to be unarchived and the app restarted before being found.

I was thinking about doing this. If we treat ChatGPT like your local llm server, you basically open up a browser session, intercept all traffic and stick a local OpenAI compatible rest server that mutilates your input upstream through the ChatGPT ui, and then intercepts downstream and pushes it out your server.

API call to server

Then

Server leverages chrome plugin to send your llm call through the plugin , through the ui, wait for response , intercept, repackage and reroute it back out as a server response.

Then that $20 sub stretches to all uses cases for a developer.

This is awesome! You solve an immediate need of mine for:

https://github.com/gitsense/chat/tree/readme-scale-knowledge

Since I only support Pi natively, your solution will make it possible for codex/claude/etc. users to discover their conversations in my app. Will definitely include this as workaround for making codex, claude and other sessions available for discovery.

Ola

this is awesome! i’ve been working on a tool for cross-harness integration tests - https://dynobox.xyz - and one of the hardest parts has been writing adapters for each harness since their transcript formats are all so different.

really excited to check out txcript… a shared translation layer could make my life sooo much easier!

Any word on when you'll add support for antigravity? I often switch between harnesses and models and subscriptions, both for work and personal stuff, this is an awesome idea. One thing I do that I don't think you have support for is running sessions on different machines. Do you have support for, or do you plan on adding support for, syncing across machines?

This is good, I like it!! I've been mostly working with Claude and Chatgpt for separate stuff, however sometimes one of them is stuck and I could definitely use this to start a session with the other one and see if it figures it out.

Have you tested to see if there was any degradation happening when switching from one model to the other ? I mean some must be inevitable (maybe not!), but how much?

Good idea. I’m working on something similar, but for regular AI chats: https://www.vinaa.ai/. Portability and organization are just as important for these conversations, since they become a personal knowledge base you may want to revisit years later.

I use recall https://github.com/viggy28/recall for the following reasons:

1. It's tightly integrated with Pi 2. Creates context automatically from sessions 3. No external dependencies - sqlite and numpy

Very cool! I created something similar (with the same name), but in 2 tools. One to share skills (skillsync) and another to share context (contextsync).

I like to create a design with one model, sync it to another and iterate on it, then potentially go to another to apply/implement.

This looks nice! I tried to tackle the same problem with https://usecontinuo.dev (writing my own translation layer) - but Skillsync looks much more powerful.

If I were you I would look into maybe like analyzing sessions across harnesses? I’m not sure, some way to leverage this shared schema work that is not syncing

Because syncing is trivially solved by just telling the agent to keep a work journal in markdown

This resonates with an adjacent problem I’ve been exploring: durable project provenance rather than live-session portability. I’m building PromptSourceCode for Codex Desktop; it preserves the human requests, corrections, and attachments as readable local history alongside the project: https://github.com/ironwood-lang/prompt-source-code. It deliberately doesn’t try to translate or resume sessions across agents. Does Skillsync expose stable session and turn identifiers that an external audit history could reference after translation?

This is really cool, especially in a world where you're using Claude as a workhorse, but want to be able to bring the entire session context into Codex so you can draft communications with full context but without Claude-isms. (You can train Claude to spawn e.g. a Codex session, but Codex wouldn't know what to ask for from the broader context, beyond the prompt Claude gives it.)

And shipping sessions to colleagues is critical as well. My team relies heavily on a homegrown /resume skill that forces the harness to read every part of a Claude Code JSONL into context, letting us merge colleagues' sessions into our own.

What I thought this might be from the title, though, is a separate but related problem. The more semi-technical people in a company who start to use agentic systems, the more likely they are to create a vital playbook as a "skill" - but one not designed for easy tracking in a repository, that relies on local state, references their name, references other skills and rules that they've developed for their own work, etc. Cleaning these, figuring out what should be promoted across a team, figuring out when someone makes an update whether that's something that deserves human review, syncing across people who haven't used git/pull requests before - it's a big challenge that's highly context-dependent. If skills are the place where guardrails exist, "who watches the watchmen?"

There's an interesting duality here, because a colleague being able to ship a session where they iterated on such a skill, to a colleague who can understand the context of their change, is incredibly valuable. But it still relies on a human in the loop, and doesn't scale as a result. I think there's a really interesting design space here.

the shit they let into YC these days bruh

kudos making the core open source. if you didnt do it, i wouldve. good luck

[dead]

[dead]