DEV Community: Rishi Gulati

Syncing Claude Code and Codex sessions across machines with git

Rishi Gulati — Tue, 22 Sep 2026 03:58:04 +0000

I work across three laptops. Claude Code and Codex both keep every conversation on the machine that started it, which means the session where the agent finally understands your codebase is stuck wherever you happened to be sitting last Tuesday.

Copilot's answer is account-level cloud sync. I didn't want transcripts of my code sitting in a vendor's cloud, and I didn't want to run a server or pay for S3 either. The infrastructure I already own, trust, and use daily is a git remote. So I built repo-sessions: sessions sync through one private git repo (a "vault"), and the sync triggers ride the git push and pull you already do. Push on laptop A. On laptop B, pull, then claude --resume. The conversation is there.

This post is the story of building it, told mostly through three bugs. Each one looked like a small edge case and turned out to be structural.

Why you can't just copy the files

Claude Code stores each session as a JSONL file under ~/.claude/projects/<munged-path>/<session-uuid>.jsonl. The munged path is your project's absolute path with every character outside [A-Za-z0-9-] replaced by a dash:

export function mungeCurrent(absPath: string): string {
  return absPath.replace(/[^A-Za-z0-9-]/g, '-');
}

So /Users/rishi/dev/proj becomes -Users-rishi-dev-proj. On top of that, every single line of the transcript embeds your cwd, plus the session id, tool version, and git branch.

Two consequences. First, resume looks sessions up by the munged path of the directory you're standing in, so on another machine (different username, different clone location) the file is in a directory Claude Code will never compute. Second, even if you put the file in the right place, the embedded paths point at directories that don't exist there.

I verified all of this empirically before writing any real code, because none of it is documented. The method: start a session that establishes a codeword, hand-copy the transcript to a second location with paths rewritten, and try to resume. The negative control ran first: resuming on "machine B" without the rewrite says No conversation found, which is exactly the failure this tool exists to fix. With the rewrite, the resumed session recalled the codeword and reported machine B's path as its cwd.

The spike also surfaced something uncomfortable: the munge rule has drifted across Claude Code versions. The same directory on my machine had transcripts under both -AI-AI-ML and -AI-AI_ML, meaning some older build preserved underscores. So the locator scans all known rule variants instead of computing one directory name and trusting it. When you build on undocumented formats, you inherit their history too.

The pipeline

On push, every absolute path in the transcript becomes a token: ${CSS_PROJECT_ROOT}, ${CSS_HOME}, and the munged dirname (which shows up whenever tool output references ~/.claude/projects/...). On pull, tokens are rewritten for the local machine. Codex needs a third path surface, because its rollout files contain self-references to $CODEX_HOME.

The vault is deliberately boring: one private git repo, plain directories, one namespace per project keyed by a hash of the normalized origin URL. Any git UI can inspect it. Sync triggers are git hooks (pre-push sends sessions out, post-merge and post-checkout bring them in), and existing hooks are chain-loaded first with their stdin and argv intact, so your husky setup keeps working and its failures still abort the git operation. Mine never do: if the vault is unreachable, everything behaves as if the tool doesn't exist.

Bug one: Windows backslashes inside JSON

Symptom, found by dogfooding on my actual Windows laptop: a synced session opens, but only the last few turns render.

Cause: transcripts are JSON, and I was substituting paths into raw bytes. Splice C:\Users\rishi\dev\proj into a JSON string literal and you've written \U, which is not a valid escape sequence:

{"command":"ls C:\Users\rishi\dev\proj"}     <- unparseable line
{"command":"ls C:\\Users\\rishi\\dev\\proj"} <- what should be on disk

Claude Code fails to parse the corrupt lines, the parent-uuid chain linking turns together breaks, and the UI shows you whatever survived. So all transcript substitution now works on the JSON-escaped spellings: the tokenizer matches every spelling of a path (escaped, forward-slash, either drive-letter case, longest first so escaped forms are consumed before their shorter cousins), and rehydration emits the escaped form.

Same family, same week: Windows git's autocrlf rewrote LF vault files to CRLF on checkout, which read as phantom content changes in synced memory files (fix: * -text in the vault plus EOL-insensitive comparison). And git's default 1 MiB http.postBuffer was rejecting multi-megabyte transcript pushes over https with an opaque HTTP 400, so background pushes failed silently, the worst possible failure mode for a sync tool.

The lesson so far: the same content has more byte representations across machines than you think. I thought I'd learned it. The next bug was the same lesson with teeth.

Bug two: the session that quoted its own sync metadata

A month in, one session started reading as permanently diverged on every pull, on both machines, even when I knew nothing had changed. Naturally it was the session where I was using Claude to debug this tool.

Here's the mechanism. Tokenization is machine-relative: my Mac's tokenizer knows the Mac's paths. But this transcript quoted my Windows machine's path spellings as ordinary message text, pasted terminal output, a munged dirname like C--Users-rishi-..., chunks of a metadata file. When the Mac pushed, those strings went into the vault verbatim, because to the Mac they're not paths, just text. The Windows machine's tokenizer would have collapsed them. So no tokenization the Mac can ever perform reproduces the vault bytes, the hashes disagree forever, and the sync layer concludes the session has diverged.

Then it got worse. The reconcile command finds the common prefix of the two copies at the byte level. The first quoted spelling appeared around line 62, so it found a false fork point there and spliced everything after it back on as a "divergent tail". Each run of the repair grew the transcript: 471 lines, then 881, then 1701, with some turns duplicated eight times. Watching a repair command make the patient worse is a special feeling.

The fix has two parts. Every push now records that device's path context (project root, home, tool data dir) in the vault index. And comparisons never touch raw bytes: both sides get folded through the tokenizer under every device context the vault has seen, in a deterministic order.

export function canonForCompare(adapter: Adapter, content: string, ctxs: PathCtx[], opts?: SubstOpts): string {
  let out = adapter.stripVolatile ? adapter.stripVolatile(content) : content;
  for (const c of ctxs) out = adapter.tokenize(out, c, opts);
  return out;
}

Tokens are inert under further tokenization, so the fold is a projection, applying it twice equals applying it once. That property is a unit test, straight from the incident:

const once = canonForCompare(claudeAdapter, fromA, ctxs, { json: true });
const twice = canonForCompare(claudeAdapter, once, ctxs, { json: true });
expect(once).not.toBe(fromA); // the fold genuinely collapses foreign spellings
expect(twice).toBe(once);     // and it is a projection

Just as important: the normal form is compare-only. The vault always stores the writer's own tokenization and installs always rehydrate the raw stored bytes. Comparison logic can evolve without ever rewriting anyone's data.

Bug three: the tool edits the transcript behind your back

Weeks later, false divergence came back, and this time the transcript quoted no foreign paths at all.

It turned out Claude Code appends a title-refresh record ({"type":"ai-title",...}) roughly every turn, on whichever machine is currently live. Two honest copies of the same conversation end up with different numbers of these records at different positions. Content-wise one copy was a clean prefix of the other, just behind. Byte-wise, diverged.

So the normal form grew a second axis: before the path fold, adapters can strip records the tool rewrites non-deterministically. The strip is parse-confirmed, only a line whose top-level JSON type is ai-title is dropped, so a turn that quotes such a record as data survives. Which mattered immediately, because the debugging session quoted them constantly.

The general lesson landed harder than either bug alone: a compare normal form has to normalize every axis of benign nondeterminism, and every new record type the vendor ships can reintroduce this bug class. That's the treadmill you're on when you build against undocumented formats. My concession to it is a doctor command that verifies drift the only way that can't lie: by actually resuming a session and checking the tool responds.

The rules that survived

Three principles came out of this intact and now gate every feature:

Transcripts are append-only. Prefix means fast-forward, divergence means conflict copies, and chat rebase splices tails back into one transcript ("meanwhile, on the other laptop", which is the truth). Nothing is ever silently dropped. Rewind is a fork from vault history, never an in-place truncation, because other devices would just push the "missing" turns right back. Deleted sessions restore from vault history, since the vault is git and every synced state is a commit.

Never write another tool's database. Codex indexes sessions in SQLite alongside the rollout files. I don't touch it. Drop a rewritten rollout into the date tree and the index heals itself on first resume. Slightly worse UX (the interactive picker lists a synced session only after you've resumed it by id once), massively better failure modes.

Degrade to invisible. Vault unreachable, tool not set up, repo not enabled: every hook exits quietly and the coding tools behave exactly as if repo-sessions were never installed.

What it looks like now

npm i -g repo-sessions
chat setup   # once per machine: creates or reuses your private vault
chat init    # once per repo: from here git push/pull carry your sessions

Then work normally. Sessions and per-project memory follow the repo. chat list, chat resume <name>, chat rebase when you got ahead of yourself on two machines at once, chat restore when you deleted something you shouldn't have.

(The binary is named chat. macOS ships a pppd utility from the dial-up era at /usr/sbin/chat, and a shell opened before the install will happily run that one instead, which blocks on stdin and looks exactly like "the tool does nothing". hash -r. Ask me how I know.)

It's MIT licensed, TypeScript with zero runtime dependencies, 61 hermetic tests running on a 3-OS CI matrix, and dogfooded daily across three machines, including a 400k-token session that resumed cross-OS with an accurate recap. One honest caveat: transcripts contain whatever your session saw. The vault must be private (setup refuses public GitHub vaults), pushes run a gitleaks-style secret scan, and there's a per-session ignore file, but you should treat the vault the way you treat .env.

What I'd tell you to steal

Byte equality is the wrong identity for synced content. You need equality up to every writer's encoding, and you should expect the set of writers to grow.
If synced content can quote your own sync metadata back at you, it eventually will. Any session about the tool itself is a self-referential input, and dogfooding guarantees those exist.
Normalize at compare time, never at rest. A compare-only normal form can evolve freely because it never rewrites stored data.
When there are no docs, a codeword and a negative control settle in one evening what speculation never will.

Repo: https://github.com/firish/repo-sessions

If you try it, the failure modes I haven't found yet are the ones I most want to hear about.

Claude Code in Visual Studio: now it drives the debugger, catches flaky tests, and reads library source

Rishi Gulati — Wed, 08 Jul 2026 18:41:05 +0000

Claude Code has this nice thing where it plugs into your editor. On VS Code or a JetBrains IDE, its edits open as a diff you accept or reject, it reads your compiler errors, and it knows what you have selected. On Visual Studio you get none of that. You copy and paste into a terminal like it is 2022. There is an open issue asking for Visual Studio support with a few hundred upvotes and no ETA, so I built the Visual Studio side myself.

It is a native VS 2026 extension. The important thing to say up front is what it is not: it is not another agent. The claude CLI does all the thinking. My extension is the IDE half of Claude Code's integration protocol, which I had to reverse-engineer off the wire since it is undocumented. It makes zero model calls of its own. It is a bridge.

The first thing you get is the diff gate. When Claude wants to change a file, the change opens in Visual Studio's own diff viewer, and approving there is the only step. No second yes/no prompt in the terminal. You can reject with a note, and it reconsiders.

That part was the plan. The part I did not expect is what became possible once the IDE half existed. Because I control the Visual Studio side, I could hand the agent things the CLI can never reach on its own. The one I keep coming back to is the debugger.

Watching the code run, instead of reading it

Here is a scoring function that returns the wrong total. Nothing in the source reads as wrong. The final number is just off. A fresh Claude session, with no idea what the bug was, was asked to check it, and it drove the Visual Studio debugger to find it in about ninety seconds.

It set a breakpoint at the top of the loop, started the session, and stepped through round by round, watching a combo counter. Here is the trace it kept, for the input {5, 3, 0, 4, 2, 0, 6}:

The bug is that the combo multiplier never resets on a zero round. if (points > 0) and else if (points < 0) both miss points == 0, so the streak carries across a zero and inflates the score. You cannot see that by reading the code. It only shows up when you watch the counter stay put across the round it should have cleared. That is the whole difference between reading code and debugging it, and the agent got to do the second one.

Reading runtime state is always on. Driving the debugger, actually stepping and setting breakpoints and running your code, is opt-in behind a toggle in the panel that resets every session, because it runs your program under the model's control.

It grew past stepping

Once the drive loop worked, the rest followed. Claude can now:

Attach to a process that is already running. A hosted web service or a desktop app, not just an F5 launch. It lists the processes, attaches, arms a first-chance exception, triggers the request itself with curl, and stops at the throw site inside the handler instead of the generic catch that swallowed it into a bland 500.
Untangle a deadlock. A deadlocked program never hits a breakpoint, so a breakpoint is useless. Claude pauses the hung process, reads each stuck thread's wait chain, and reconstructs the exact A -> B -> C -> A lock cycle, correctly ignoring the threads that are merely idle or busy.

And the one I am most proud of, because Visual Studio's own UI cannot even set it through an automation API: data breakpoints. Point Claude at a field and it stops the instant that field is written, or records every value the field takes, in order. It can watch conditionally (break only when the value goes below zero) and watch several fields at once.

I built a little fixture where an order's total is mutated through four different pricing methods and comes out negative, with no single line to breakpoint. Claude armed a plain watch, a conditional watch, and a second watch at once:

The conditional watch broke exactly on the write that corrupted the total, and the plain watch recorded the full timeline:

#	value (cents)	written by
1-3	0 → 30000 → 42000 → 54000	`AddItems`	three line items
4	54000 → 48600	`ApplyBulkDiscount`	10% off
5	48600 → 52488	`ApplyTax`	+8% tax
6	52488 → -47512	`ApplyLoyaltyCredit`	the corruption

Getting that to work was the hardest part of the whole project. There is no EnvDTE surface for it, so it rides a small Concord debug-engine component that ships with the extension and arms the breakpoint from inside the engine, then streams the changes back out over file IPC.

Catching a flaky test red-handed

dotnet test runs your tests. What it cannot do is stop inside a failing one in the debugger, or reproduce an intermittent failure on purpose and pause on it. So I wired Visual Studio's Test Explorer engine to the same debug session.

The signature move is catching a heisenbug. Point it at a flaky test and it loops the test under the debugger with break-on-thrown armed, lets the passing runs finish, and stops on the first failing run, paused at the throw with the exception live in the frame:

The honest twist in that run: when it read the frame, it found there were no captured locals at all, and the throw came straight out of an if (Random.Shared.Next(3) == 0) branch. The test was not exposing a product bug. The test itself was nondeterministic because it branched on an unseeded RNG. A re-run loop would have given you a different red line every time and never told you that. Being paused inside the exact failing run did.

Getting real per-test results out of the engine took a trick too. Its result callback is an internal interface you cannot implement in normal C#, so the extension emits a type that implements it at runtime with Reflection.Emit.

Reading code the way the compiler does

The last piece is less flashy but I use it constantly. Instead of grepping text for "where is this used," Claude asks Visual Studio's compiler (Roslyn) for the resolved answer: find-all-references, go-to-definition, find-implementations, and call and type hierarchies, resolved through interfaces, overrides, and overloads. It catches the cases text search gets wrong, like an explicit interface implementation or a virtual dispatch a grep can never tie back to the interface.

Tool	What it caught that a text search misses
find-implementations	`Triangle`'s explicit `IShape.Area`, which `.Area()` or `: IShape` never ties back to the interface
type-hierarchy	`Circle` and `Square` reach `IShape` transitively through `ShapeBase`; grep on `: IShape` finds only the two direct implementers
call-hierarchy	the interface-dispatched callers of `IShape.Area`, back to `Main`, that a search on the concrete `Circle.Area` would miss
go-to-definition	the right `Describe` overload at a call site, not all three declarations
decompile	the real body of `Enumerable.Sum` from the library, with `Math.Sqrt` falling back to SourceLink

It also does the one thing reading your repo fundamentally cannot: it decompiles the body of a method that lives in a referenced DLL. Point it at a framework or NuGet call and it hands back the real C#, the way Go-To-Definition does, and for core .NET types it fetches the actual runtime source over SourceLink.

How it hangs together

If you like the plumbing: the extension starts a localhost WebSocket server, writes a lockfile, and launches claude already connected. The diff, diagnostics, and selection tools ride Claude Code's IDE protocol directly. The debugger, the test runner, and the semantic tools ride two extra MCP servers the CLI reaches through a tiny stdio shim, because that channel is the open plugin door where the model actually sees the tools. Everything runs in-process against the live Visual Studio services, on the UI thread where it has to be. The CLI does all the agent work; the extension never calls a model.

The honest part

Visual Studio 2026 only for now. A 2022 backfill is possible if people want it.
The integration protocol is undocumented and could change on any CLI update, so I pin and smoke-test against a known-good version.
The debugger, test, and data-breakpoint features are .NET-focused.
It is free, MIT, and not affiliated with Anthropic. "Claude" and "Claude Code" are Anthropic's.

If you write C# and use Claude Code, I would genuinely like to know how it holds up on a real codebase.

Marketplace: Claude Code for Visual Studio
Source and docs: github.com/firish/claude_code_vs

The deep-dives (the full debugger tool list, the test loop, the semantic surface) are in the repo's docs/ folder if you want to see how far each piece goes.

I brought Claude Code to Visual Studio, then handed it the debugger

Rishi Gulati — Tue, 23 Jun 2026 19:00:23 +0000

Update: this extension has grown well past what this post covers. It now has a debugger Claude can drive, data breakpoints, test integration, and Roslyn code navigation. The current, fuller walkthrough is here: I brought Claude Code to Visual Studio, and gave it a debugger it can drive.

Plenty of times I've run a C# project in VS Code instead of Visual Studio, not because I like it better, but because that's where Claude could show me its edits in a real diff before I accept or reject. There's already an open request for something similar on GitHub with a stack of upvotes and no answer yet. So, I built the missing half myself.

It started as a diff window. I wanted Claude's edits to show up in the real Visual Studio diff instead of a yes/no prompt in a terminal. That worked, and so, I moved to the next biggest inconvenience, letting the Claude CLI read the compiler errors and warnings, the lint problems, and the rest of the build output directly, instead of copy-pasting them in. This was the v1 of my project.

The next biggest problem (and opportunity) came when I found myself using the debugger, and adding console logs and then hand-feeding those values to the Claude CLI to get it to debug a tricky issue with the correct context. So I started building a bridge between Visual Studio's debugger automation and the CLI. A few weeks later Claude was setting breakpoints in my files, stepping through them, watching variables mutate at different frames, and telling me where a bug was hiding that it would have probably skimmed past while reading my code.

Quick disclaimer first. This is an unofficial community project, not affiliated with Anthropic. It's open source, it targets Visual Studio 2026, and it needs the Claude Code CLI installed. The Anthropic CLI is the hero doing the actual model work. My extension is the IDE sidekick supporting it.

The run that made me excited

Check out this scoring function. Each round scores points, and a run of scoring rounds builds a combo multiplier. The first hit counts once, the second in a row counts double, and so on. A round that scores nothing should break the run and reset the combo.

It compiles. It runs. It prints the wrong number. Give it the rounds {5, 3, 0, 4, 2, 0, 6} and it returns 61, when the answer is 25. Nothing in the source looks wrong. No IDE warnings.

I opened a fresh Claude session that had never seen the file. Then I asked it to find what was tripping up.

It stepped through the rounds one at a time, reading the combo and the running total at each stop.

This is the trace it built as it went:

round	points	combo after	total	expected
0	5	1	5	5
1	3	2	11	11
2	0	2	11	11
3	4	3	23	15
4	2	4	31	19
5	0	4	31	19
6	6	5	61	25

Round 2 is the tell. The points are 0, so the combo should drop back to nothing. It stays at 2. Same at round 5. The run never resets, so every later round gets multiplied by a number that's too big and the total climbs to 61.

Then it pointed at the cause:

The zero case falls through both branches. The code handles points greater than zero and points less than zero, and a plain zero matches neither, so the combo never resets.

The bug is invisible in the output. The only way to catch it is to watch the combo fail to reset while the program runs, which is what a person does with a debugger (or a bunch of tracing statements), and what the agent did here. It didn't read the bug. It watched it. Start to finish, about a minute and a half.

Then it wrote the fix, and the fix opened where I would want it. Not as text in a terminal, but in Visual Studio's own diff viewer, with Accept and Reject right there.

The everyday part it rides on

That diff is the part I had been leaning on for weeks before any of the debugger work, and it's still what I use most. Every change Claude proposes opens as a real diff in the editor you already trust. You read it and click Accept or Reject. There's no second confirmation waiting back in the terminal.

The reject is the part I like. You don't just say no, you say why, in a sentence.

That note goes straight back to the CLI, and Claude picks it up and tries again with your correction instead of taking another blind swing.

It reads your build too. Errors and warnings from the Error List, C# and C++, reach the model directly, so it can see what's broken without you pasting anything in. And there's a docked panel that keeps the session honest: what you've accepted and rejected, tokens and cost, and a line for how much the agent has been inspecting the debugger versus driving it. The switch that lets it drive lives here as well, off until you turn it on.

Why this took real work

The obvious approach doesn't work, and that's most of the story.

Claude Code talks to an IDE over a small local protocol: a lockfile plus a localhost WebSocket speaking MCP. The catch is that the CLI is picky about which of the IDE's tools it actually shows the model. It hands over diagnostics and runs the rest itself. So I could register a new "read the debugger" tool and the model would never be allowed to touch it.

The debugger gets to Claude two other ways.

The first is a hook. Send a prompt while you're paused at a breakpoint and a hook fires, reads the break state out of Visual Studio, and drops it into the context before the model sees your message. No tool call. Claude starts the turn already knowing where you're stopped and what every local holds.

The second is a separate MCP server, the kind you register yourself for a project. Those aren't filtered, so any tool they expose, the model can call. The extension runs a small one for the debugger and registers it on launch. The work happens inside Visual Studio. A shim just shuttles messages to it.

Reading state was pretty easy. Driving the debugger was the part that kept getting errors. "Step over" isn't a question with an instant answer. You issue it, then you have to wait for the program to stop again before the result means anything. Block the UI thread to wait and you freeze the IDE. The solution is to implement the step such that it goes out without blocking the main UI thread, the extension listens for the debugger's mode-change event, holds the request, and finishes it when the next break lands. From the model's side it's one clean call that returns the new state. Underneath it's an event handshake that keeps the editor responsive.

Driving is also off by default. Reading runtime state is always on, since it can't break anything. Continue, step, breakpoints, starting and stopping a session: all of that sits behind the checkbox in the panel, and it resets every time you restart Visual Studio. Letting an agent run your code is a real decision, so its off by default.

What's next

A few things on the list:

Test driven debugging. Run the suite, and when a test fails, set a breakpoint at the failure, start debugging that test, and drive to the fault on its own.
(Work in progress) Break on thrown. Stop the instant a chosen exception is thrown, at the throw site, not wherever it gets swallowed.
CPU and memory. Point the .NET diagnostics tools at the running process and surface the hot methods and the heaviest allocations.

Try it

It's on the Visual Studio Marketplace, and the source is on GitHub. You need Visual Studio 2026 and the Claude Code CLI.

Marketplace: https://marketplace.visualstudio.com/items?itemName=firish.bridgev1
Source and docs: https://github.com/firish/claude_code_vs

If you work in Visual Studio and you've wanted Claude Code there, give it a try and tell me what breaks.