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.
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
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!
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.
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.
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.
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.
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
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 do the same for apple notes and imessage. so very portable
https://apps.apple.com/us/app/exporter-notes-to-markdown/id6...
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.
really excited to check out txcript… a shared translation layer could make my life sooo much easier!
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.
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.
you can use that internally for this
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.
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.
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.
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.
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?
Because syncing is trivially solved by just telling the agent to keep a work journal in markdown
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.
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.
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.
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.
the mind meld thing sounds interesting, it sounds like git merge but for the transcripts
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