Toolpath

The problem

Every coding agent writes its own undocumented session log. Claude Code keeps rotating JSONL chains, Codex writes rollout files, Gemini has chat directories, Copilot an event stream. The session that produced a change is locked inside the harness that ran it, and that harness can change its format at any time.

One format for everyone's tools

Toolpath is the open session format: every harness's sessions in one portable schema that records who changed what, why, what they tried that didn't work, and what it cost.

One schema means tooling stops being per-agent. A cost dashboard, a review surface, a search index, an archive: build it once against the format and it works with sessions from every supported harness. And when the next agent ships, one new parser brings it into every tool you already have.

Parse in, project out

Toolpath is open and versioned: the schema is published, and a document that validates today will validate tomorrow. Harness formats are neither. They are undocumented, proprietary, and change without notice. So Toolpath treats them as boundaries around a stable center, and everything it does is one of three moves across that boundary:

• Parse in. A session crosses the boundary once and becomes a stable document you can keep, query, and share.
• Project out. A document becomes the on-disk layout a target harness expects. Any writable harness, not just the one the session started in.
• Resume. A projection followed by a handoff: Toolpath writes the session where the harness looks for it, then starts the harness on it.

Three core objects

Steps form a DAG via parent references. Dead ends are implicit: steps not in the ancestry of path.head.

Supported harnesses

• Claude Code
• Gemini CLI
• Codex CLI
• Copilot CLI (preview)
• opencode
• Pi
• Cursor IDE

Parsing captures the full session: prompts, tool calls, reasoning, file changes, sub-agent work, token usage. Projecting writes a session the harness accepts as its own, so it resumes natively. Where a harness's log genuinely doesn't record something, the gap is documented in the format notes rather than papered over.

Git history and GitHub pull requests parse into the same schema, so a session, the PR it became, and the release that shipped it can share one graph.

What Toolpath adds

Minimal example

A valid Toolpath document can be tiny:

{
  "graph": { "id": "graph-step-001" },
  "paths": [
    {
      "path": { "id": "path-step-001", "head": "step-001" },
      "steps": [
        {
          "step": {
            "id": "step-001",
            "actor": "human:alex",
            "timestamp": "2026-01-29T10:00:00Z"
          },
          "change": {
            "src/main.rs": {
              "raw": "@@ -12,1 +12,1 @@\n-    println!(\"Hello world\");\n+    println!(\"Hello, world!\");"
            }
          }
        }
      ]
    }
  ]
}

No parents (it's the first step). No meta. One file, one perspective. Every document is a Graph at the root — single-step documents like this one are a Graph holding one Path holding one Step.

Quick start

# Install
cargo install path-cli

# Archive every agent session on this machine (all harnesses, incremental)
path p cache sync

# Query across all of them with a jq filter, whichever agent produced them
path query 'map(select(.dead_end))'
path query 'map(select(.step.actor | startswith("agent:")))'

# Share a session, then resume it in the original harness or a different one
path share
path resume https://pathbase.dev/alex/pathstash/path-pr-42 --harness codex

# Derive provenance from git history and visualize it
path p import git --repo . --branch main --no-cache | path p render dot | dot -Tpng -o graph.png