Spool: turning local coding agent sessions into shareable, resumable pages
Store, share, and resume AI coding sessions.
At a glance
- What is it?
- Spool indexes Claude Code, Codex CLI, Gemini CLI, OpenCode and Pi sessions on your machine, then publishes selected records to a hosted Hub as a durable URL that others can read or resume. The design is local-first and the default for two providers is public, which is the first thing to understand before you run it.
- Who is it for?
- Adopt Spool if you already work in Claude Code or Codex CLI and want a URL that a teammate can open without installing anything, then continue locally with spool resume <session-url>. Do not adopt it if your sessions routinely contain client data, internal hostnames or pasted secrets, or if you depend on Gemini CLI, OpenCode or Pi and need native continuation, which the README does not claim.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 50 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Spool fills between a screenshot and a git repo
A coding agent session is real work, but it lives in a provider-specific store on one machine. Screenshots lose the tool calls. A recap loses the diff. Git keeps the code and drops the reasoning that produced it, and the README is explicit that Spool does not try to replace source control: "Git remains authoritative for code." What Spool publishes is the agent work and its context, not the repository.
The intended reader is someone who needs to understand what an agent did and then continue it. The README describes the reading path as moving "from Summary to conversation, tool activity, files, and diff before continuing the work in their own agent." A reader can open the URL without installing Spool. That is the whole proposition: a durable page that carries the session, plus a way to pick the work back up in the original agent format.
Who it is for, concretely: people running Claude Code or Codex CLI who want to hand off a session, and teams that want a shared namespace for that work. The README marks the project as early stage, and the provider support is uneven by design, which shapes almost every decision below.
Local index, hosted Hub: where the data actually goes
Spool splits into two halves. The local half is packages/core, described as "Local Session ingestion, organization, SQLite, and full-text search." It reads session records from five providers: Claude Code, Codex CLI, Gemini CLI, OpenCode and Pi. The README calls this "Local preparation", meaning collection and organization happen before you decide anything.
The hosted half is apps/backend, described as the "Hub, identity, Teams, publication, and media API on Cloudflare." Sharing is the action that moves selected records there. The README states plainly that "Nothing leaves the machine until the author confirms the Share flow started by spool or spool share." That is a confirmation gate, not a background sync.
Two packages sit between the two halves. packages/redact handles "Sensitive-data detection shared by publishing surfaces", and packages/session-kit holds the "Browser-safe Session model, canonical records, views, and diffs." The word browser-safe matters: the same session model has to render in the web reader, so it cannot carry anything the local store holds but the page should not show. The README also mentions share-kit, which produces "Curated .spool documents, templates, and export primitives", a format distinct from the raw provider record.
The share flow, and the visibility defaults you should read twice
Installation is a single command from the project's own domain:
curl -fsSL https://spool.new/install.sh | sh
The README says to open a new terminal afterwards, then use spool from any project. Bare spool does the most: it refreshes the local index, signs in through the browser if needed, and selects the latest session in the current project. From there it shows what will be shared, scans for sensitive values, confirms visibility, publishes, and returns a URL. The explicit form is spool share <session-uuid> when you want to pick a session or pass options.
Now the part that deserves attention. The README's early-stage note says Claude Code and Codex CLI shares are "Public by default and can appear in Explore and search", while Gemini CLI, OpenCode and Pi shares "remain Link-only until Discovery supports them." The confirmation screen states the Project owner and the initial visibility before upload, so the default is disclosed, but it is still a default that publishes.
Project scoping changes the outcome. The example spool share --project paperboy/spool --public publishes under a Team-owned Project while keeping the session Public. Omit --public with a Team Project and the README says it "fails closed to Team-only." That asymmetry is deliberate and worth internalising: for a Team Project, the safe case is the default and public is the opt-in.
Resume, Fork and Withdraw are three different promises
Resume is the feature that separates Spool from a session viewer. The command is spool resume <session-url>. According to the README, it "creates a new provider-native Session and preserves its relationship to the source," and "The shared source is never modified." Native resume currently works for Claude Code and Codex CLI only. The README does not claim it for Gemini CLI, OpenCode or Pi, so treat continuation there as unverified.
Withdraw is narrower than it sounds. It makes the current hosted copy return 410 Gone. A personal author can later share the same session again. A Team-owned withdrawal performed by an Owner or Admin is permanent and, in the README's words, "cannot be revived by another member." Those two paths behave differently, and the difference is not reversible by asking nicely.
The Team model adds a transfer of control that is easy to miss. Publishing into a Team Project "transfers control of the hosted asset to the Team." A Team Project keeps Team ownership whether the session is Team-only, Link-only or Public. So the visibility label and the ownership label are independent: a Public session inside a Team Project is still a Team asset, and Owners and Admins can change its disclosure later. If you want to keep personal control of a session, do not publish it into a Team Project.
What the repository layout tells you about maintenance
The Share stack is a pnpm monorepo: apps/cli, apps/web, apps/backend, plus packages/core, packages/redact, packages/session-kit, packages/session-view and packages/share-kit. The README lists separate typecheck and test targets per workspace (@spool-lab/cli, @spool/backend, @spool/web) and a build step for the web app. Development setup is two commands, pnpm install followed by pnpm run rebuild:native:node, which implies a native module that has to be rebuilt against the local Node version.
That native rebuild is the first thing that will break for a contributor. It also hints at where the SQLite and full-text search work lives. The release cadence visible in the metadata is fast: three releases (0.8.3, 0.8.4, 0.8.5) within roughly two days in late July 2026. Fast patch releases at a 0.x version mean you should pin, and the README does not describe an upgrade path, a migration story for the local SQLite index, or a compatibility policy between CLI versions and the Hub.
The licence situation needs care. The README's License section says MIT, but the repository metadata reports NOASSERTION, and the trademark section states that "Spool" and the Spool logo are trademarks of TypeSafe Limited, with the MIT License covering "the source code only" and not granting permission to use the name or logo. If you fork and redistribute, the code is permissively licensed but the branding is not. That is a factual constraint, not legal advice; check LICENSE yourself.
What Spool is not, and the closest alternative approach
The clearest limitation is provider coverage. Public-by-default publishing and native resume apply to Claude Code and Codex CLI. Everything else is Link-only and, per the README, has no native continuation. If your work happens in Gemini CLI, OpenCode or Pi, you get a readable page and nothing more.
The second limitation is the redaction boundary. packages/redact performs "Sensitive-data detection", and the share flow "scans for sensitive values". Detection is not proof. A session that contains a pasted credential in an unusual format, a customer name, or an internal hostname that does not match a detector pattern can still pass the scan and, for Claude Code and Codex CLI, land Public by default. The README does not publish detector coverage or false-negative rates, so there is no number to lean on. If your sessions routinely contain client data, the correct move is a Team Project without --public, which fails closed to Team-only, rather than trusting the scan.
The third limitation is the hosted dependency. Reading requires the Hub to serve the URL, and the backend is a Cloudflare-hosted API. Local-first describes where the session is captured, not a guarantee that a shared page survives without the service. Withdraw makes a hosted copy return 410 Gone, which is a server-side behaviour, so the page's lifetime is tied to the Hub.
The obvious alternative is a general-purpose session viewer or transcript exporter: tools that read the provider's own JSONL or history files and render them locally or commit them to a repository. The difference in approach is that a viewer stops at display. It does not create a hosted URL, it does not model Projects, Teams and visibility, and it does not materialize a new provider-native session from a link. Spool's cost for those three things is the upload step and the account. If you only need to read your own past sessions, the local index in packages/core plus a viewer is enough and Spool's Hub adds risk without adding value.
Who should run spool, and the first thing to check
Run it if you are in Claude Code or Codex CLI, you want a handoff that a colleague can open in a browser, and you accept that the shared copy lives on someone else's infrastructure. The command sequence is short: install with the curl script, cd into the project, run spool, read the confirmation, and share. The reader needs nothing installed. If they do have the CLI, spool resume <session-url> gives them a new local session with lineage back to the source.
Do not run it if your sessions are the sensitive part of your work. The public default for the two best-supported providers is the design, not an accident, and the redaction scan is a filter rather than a guarantee. Do not run it for Gemini CLI, OpenCode or Pi if continuation is what you need. And do not publish into a Team Project casually: control of the hosted asset moves to the Team, and a Team-owned withdrawal by an Owner or Admin is permanent.
The first thing to verify on your own machine is the confirmation screen. The README says it states both the Project owner and the initial visibility before upload. Run spool once on a scratch project, watch what it selects, and confirm that the visibility line matches what you expect for that provider. If you are sharing anything beyond a personal demo, pass --project with a Team namespace and leave --public off, so the flow fails closed to Team-only.
Editorial conclusion
Adopt Spool if you already work in Claude Code or Codex CLI and want a URL that a teammate can open without installing anything, then continue locally with spool resume <session-url>. Do not adopt it if your sessions routinely contain client data, internal hostnames or pasted secrets, or if you depend on Gemini CLI, OpenCode or Pi and need native continuation, which the README does not claim. Before your first share, run spool on a throwaway project and read the confirmation screen: it names the Project owner and the initial visibility, and for Claude Code and Codex CLI that visibility is Public unless you pass --project with a Team namespace and omit --public.
Community notes