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 agree that the next session wants conclusions, not the whole transcript. What I've seen working with people on this is that a summary only has what the summarizer prompt asked for, and what they need from an old session changes depending on what they're doing when they go back to it. With the full session still around, they can just ask it again.
Porting is also cheap, since it's just a format conversion. Getting a new session back up to speed from notes usually isn't.
Concurrent sessions is a separate problem, and I agree that a message is the right shape there. Where portability helps is that different harnesses are good at different things, so you can start a task in one and move it to another that's better at the next part, without starting over.
Cool! Over here we mean portability in a different sense: being able to continue a session in another agent as if the entire conversation history was there the whole time. You should not get locked into one agent simply because you built up a conversation history + memory with that agent
Also curious, do you further process the synced files on dropbox at all? how are you using them today?
In my experience 95% of the session transcript I don't care about.
But there are some that I want to keep and maybe come back one month later.
Usually it's not even engineering-related. Maybe doing some research on visas, relocation.
But sometime also doing project research and sometime I want to come back to the same topic 2 month later(because new things came up) and I want my new agent to go and read prior conversation.
Yeah understandable, with skillsync you can choose for it to proactively tell you about past work that's related to what you're doing or just access all your past sessions via mcp. It's like being a musician that has the record button on the whole time for when the crazy idea strikes
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'll add support for this. On another note, if you know what the issue is, our core is open and I would love for you to contribute: https://github.com/skillsynchq/txcript
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.
The only thing that seems to be missing is synching but I have a workaround for that but it won't be near realtime. For example, Pi changes are usually a second or less behind the Pi session log.
With txcript, it will probably be 5 seconds which is fine since the use case will mostly revolve around discovery, organizing and inspection.
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!
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.
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?
Nars here, one of the co-founders. With longer sessions, the receiving agent sometimes decides to compact it. But the whole transcript still exists and is accessible
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 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 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
We do that, and it's really the point of the portability work. Once every harness's sessions live in one schema, you can manage and search all of them in one place.
The markdown journal is a fair way to do it, and a popular one. It has a couple of limits though.
A journal comes out of a prompt, so it records one way of looking at the session. Whatever that prompt didn't ask about is gone, and you usually find out which detail you needed much later. But the raw session still has it.
Being able to unify the schema lets you do things notes can't. You can continue a teammate's session on your own machine, or pick up a claude.ai conversation in Claude Code or Codex. The new agent gets the transcript: all the decisions in the trajectory, not a summary of it.
To say what the author said in another way- thats a garbage approach and completely misses the point. Sure, you can completely destroy the session by distilling it into a markdown- but thats like explaining what you did yesterday, vs having an immutable log of what you did yesterday.
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.
Yes the name is a giveaway, that's how we started out. We wanted to make it easy for non-technical people to collaborate with technical ones. git pull does bring in some friction here. Skillsync can be used as a shared skills library out of the box. Once someone updates a skill, it hot-reloads and make the latest version available to everyone instantly
Curious about your /resume skill. You said merge, so are you pulling a colleague's session into one you already have open? We only do the other direction today, where you reopen their session and continue from it. I'd love to know which one your team reaches for more.
Yea, it's Claude Code only, but it runs some Python to turn the JSONL into markdown (importantly, with full tool inputs/outputs) then instructs the session to load every single line of that markdown, which Claude Code will do in chunks.
Certainly we're often resuming the session directly as a handoff, and it works for that, albeit with some context overhead for the markdown reads (though arguably we could just put the JSONL in the session folder and resume it natively). But if both you and a colleague have done independent investigation on the same project, it also makes "mind melds" possible, including their temporary scripts and unmerged changes - just begin the resumption within one's own session.
keeping tool_results help the agent figure out what is being referred too. But, as you said we also faced the problem of context overhead from reading markdown that's why we made continue into a cli command instead.
the mind meld thing sounds interesting, it sounds like git merge but for the transcripts
> 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
This is interesting, I've noticed some teams where the power users (usually the ones creating most of the skills) ship an additional skill to help users update their existing skills. This 'update' skill asks them questions to understand the user's context before actually updaing the skill
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?
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.
That's a clever idea, and a different direction from where we are right now. Today it only goes one way, from chat into your coding agent.
The case I hit all the time is that an idea strikes on my commute, so I pull out my phone and start brainstorming in the Claude app. By the time I'm home I've done the research and chased down the tangents in that conversation. I open my laptop, use Skillsync to continue it in Claude Code, and start on the implementation.
How would they know? Only if you use a coding harness, but one could write their own harness with less obvious system prompts.
I’m not encouraging one do this. I mostly route between the free models on OpenRouter and OpenCode free models, and I mostly write simple apps where I can casually oversee even a small model and get awesome results.
But if you are out there spending 200 dollars a month, consider a few hacks, because that’s just overpriced. We are developers after all, they aren’t supposed to be able to trick us :)
Edit:
Piracy, with the above , would look like a universal server that routes between all provider UIs. That means the end user doesn’t even give a shit which provider it goes to, serious token usage, serious theft.
Someone could make this , I suppose. In a way, commodification is a clean solution to the inevitable theft. It’s better it just be so darn cheap and ubiquitous.
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 agree that the next session wants conclusions, not the whole transcript. What I've seen working with people on this is that a summary only has what the summarizer prompt asked for, and what they need from an old session changes depending on what they're doing when they go back to it. With the full session still around, they can just ask it again.
Porting is also cheap, since it's just a format conversion. Getting a new session back up to speed from notes usually isn't.
Concurrent sessions is a separate problem, and I agree that a message is the right shape there. Where portability helps is that different harnesses are good at different things, so you can start a task in one and move it to another that's better at the next part, without starting over.
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...
Cool! Over here we mean portability in a different sense: being able to continue a session in another agent as if the entire conversation history was there the whole time. You should not get locked into one agent simply because you built up a conversation history + memory with that agent
Also curious, do you further process the synced files on dropbox at all? how are you using them today?
I don't do much with most of the sessions.
In my experience 95% of the session transcript I don't care about.
But there are some that I want to keep and maybe come back one month later.
Usually it's not even engineering-related. Maybe doing some research on visas, relocation.
But sometime also doing project research and sometime I want to come back to the same topic 2 month later(because new things came up) and I want my new agent to go and read prior conversation.
Yeah understandable, with skillsync you can choose for it to proactively tell you about past work that's related to what you're doing or just access all your past sessions via mcp. It's like being a musician that has the record button on the whole time for when the crazy idea strikes
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'll add support for this. On another note, if you know what the issue is, our core is open and I would love for you to contribute: https://github.com/skillsynchq/txcript
Definitely. Issue filed: https://github.com/skillsynchq/txcript/issues/52 Will test locally and implement the fix now.
PRs up!
Already merge #53, thanks for the assist.
it's interesting to know that archived sessions are stored different as opposed to the codex cli and desktop app session.
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.
we publish a npm package of our core library too: https://github.com/skillsynchq/txcript
you can use that internally for this
Unfortunately I won't be able to use the npm as I need it for synching which is managed by https://github.com/gitsense/gsc-cli/tree/staging
The only thing that seems to be missing is synching but I have a workaround for that but it won't be near realtime. For example, Pi changes are usually a second or less behind the Pi session log.
With txcript, it will probably be 5 seconds which is fine since the use case will mostly revolve around discovery, organizing and inspection.
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!
Thank you! let us know if you don’t see your harness / feel free to raise a pr
check out Nvidia's version: https://github.com/NVIDIA/NeMo-Fabric
will do! thanks!
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
Interesting, I love pi too!
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.
Fun fact, skillsync works with all kinds of chats :)
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?
Nars here, one of the co-founders. With longer sessions, the receiving agent sometimes decides to compact it. But the whole transcript still exists and is accessible
that's good to know, will try skillsync out when I get the chance!
In some cases, harnesses try to obfuscate reasoning, but almost everything goes through.
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.
Curious why you didn’t bundle them?
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 looks nice! I tried to tackle the same problem with https://usecontinuo.dev (writing my own translation layer) - but Skillsync looks much more powerful.
Yeah I like how you have controls on how much of the conversation you want to bring into the next session!
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
We do that, and it's really the point of the portability work. Once every harness's sessions live in one schema, you can manage and search all of them in one place.
The markdown journal is a fair way to do it, and a popular one. It has a couple of limits though.
A journal comes out of a prompt, so it records one way of looking at the session. Whatever that prompt didn't ask about is gone, and you usually find out which detail you needed much later. But the raw session still has it.
Being able to unify the schema lets you do things notes can't. You can continue a teammate's session on your own machine, or pick up a claude.ai conversation in Claude Code or Codex. The new agent gets the transcript: all the decisions in the trajectory, not a summary of it.
btw we also have an agent in the mac app that lets you analyze your sessions in all kinds of ways
To say what the author said in another way- thats a garbage approach and completely misses the point. Sure, you can completely destroy the session by distilling it into a markdown- but thats like explaining what you did yesterday, vs having an immutable log of what you did yesterday.
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.
Yes the name is a giveaway, that's how we started out. We wanted to make it easy for non-technical people to collaborate with technical ones. git pull does bring in some friction here. Skillsync can be used as a shared skills library out of the box. Once someone updates a skill, it hot-reloads and make the latest version available to everyone instantly
Curious about your /resume skill. You said merge, so are you pulling a colleague's session into one you already have open? We only do the other direction today, where you reopen their session and continue from it. I'd love to know which one your team reaches for more.
Yea, it's Claude Code only, but it runs some Python to turn the JSONL into markdown (importantly, with full tool inputs/outputs) then instructs the session to load every single line of that markdown, which Claude Code will do in chunks.
Certainly we're often resuming the session directly as a handoff, and it works for that, albeit with some context overhead for the markdown reads (though arguably we could just put the JSONL in the session folder and resume it natively). But if both you and a colleague have done independent investigation on the same project, it also makes "mind melds" possible, including their temporary scripts and unmerged changes - just begin the resumption within one's own session.
keeping tool_results help the agent figure out what is being referred too. But, as you said we also faced the problem of context overhead from reading markdown that's why we made continue into a cli command instead.
the mind meld thing sounds interesting, it sounds like git merge but for the transcripts
> 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
This is interesting, I've noticed some teams where the power users (usually the ones creating most of the skills) ship an additional skill to help users update their existing skills. This 'update' skill asks them questions to understand the user's context before actually updaing the skill
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?
Yes you can also ssh into your machines and sync all of those sessions too. Check out the + icon on the left side bar on the desktop app!
we do support antigravity!
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.
That's a clever idea, and a different direction from where we are right now. Today it only goes one way, from chat into your coding agent.
The case I hit all the time is that an idea strikes on my commute, so I pull out my phone and start brainstorming in the Claude app. By the time I'm home I've done the research and chased down the tangents in that conversation. I open my laptop, use Skillsync to continue it in Claude Code, and start on the implementation.
Good way to be banned
isn't that what they did to opencode? when they were using the subs by reverse engineering their APIs
How would they know? Only if you use a coding harness, but one could write their own harness with less obvious system prompts.
I’m not encouraging one do this. I mostly route between the free models on OpenRouter and OpenCode free models, and I mostly write simple apps where I can casually oversee even a small model and get awesome results.
But if you are out there spending 200 dollars a month, consider a few hacks, because that’s just overpriced. We are developers after all, they aren’t supposed to be able to trick us :)
Edit:
Piracy, with the above , would look like a universal server that routes between all provider UIs. That means the end user doesn’t even give a shit which provider it goes to, serious token usage, serious theft.
Someone could make this , I suppose. In a way, commodification is a clean solution to the inevitable theft. It’s better it just be so darn cheap and ubiquitous.
the shit they let into YC these days bruh
I suspect its about the people not just the pitch. The team seems experienced and have shipped useful products. Good luck to them
ok
kudos making the core open source. if you didnt do it, i wouldve. good luck
Hahaa thanks :)
[dead]
[dead]