v0.1.1

Packaging only. bin/session-baton is byte-identical to 0.1.0 apart from the version string.

session-baton is now on npm, so if you already have Node you can skip the clone:

$ npm install -g session-baton
$ npx session-baton doctor          # or try it without installing anything

The two channels are not the same thing. npm serves tagged releases; the git clone tracks the
tip of main, which is the only thing SECURITY.md
supports — there are no backports, so an npm install is a pinned one by definition. The clone also stays
the channel the tool is designed around: make install symlinks, which is why git pull updates in
place and --version can name the exact commit you are running. From a tarball there is no commit to
name, so --version prints the version alone (it already behaved that way — see build_sha).

Also in this release:

• os is pinned to darwin/linux, so npm refuses the install on native Windows rather than putting a
  command on your PATH that cannot work. WSL reports linux and is unaffected.
• CI now fails when VERSION in the script and version in package.json disagree. The number is
  stated in two places now and nothing else makes them move together — a drift would only surface as a
  bug report quoting a version that never shipped.

Nothing about the tool changed. No new flags, no behaviour changes, no node_modules, and no install
script: the npm package is the same dependency-free bash script, delivered a second way.

v0.1.0

First release.

Your session is on the laptop you are about to close. session-baton moves it to a machine you keep switched on at home, over your own SSH: the code including what you have not committed, the agent's transcript, and an exclusive "baton" saying which machine is now in charge. Drive it from your phone while you are out; take brings it back and you resume where you stopped.

$ session-baton pass --remote-control
🎽 baton passed to 'home-mac'.

$ session-baton take
🎽 baton taken by laptop. Resume here with:
claude --resume 9f3c…

What is in it

• pass, take, adopt, baton, doctor, over two transports. git pushes a branch to your existing origin; rsync copies the working tree machine to machine, so nothing reaches a git host. Pin rsync when origin is production.
• Exclusive ownership through a remote lock, so a session is never live on both machines at once.
• The peer's resumed session starts with --permission-mode auto. Nobody is sitting at the machine the baton lands on, and a session that halts on the first "can I run this?" is indistinguishable, from the phone driving it, from one that never arrived. The peer probes its own agent's --help before adding the flag, because passing it blind kills a detached launch invisibly.
• --clone, plus a pre-flight check that the peer has the repo at all, so a hand-off to a machine that never cloned the project is refused before anything moves rather than after the baton is gone.
• Optional context sync, deliberately excluding config the agent executes.
• Claude Code slash commands under examples/, READMEs in 11 languages.

No daemon, no relay, no vendor cloud, no account. One bash script; bash 3.2+, git, ssh, scp.

On the security posture

The realistic failure modes are data loss, code execution on the peer, and credential exposure, so the peer is treated as hostile even though it is yours. Its inputs are validated, its destructive suggestions are bounded, and deletion under ambiguity is refused rather than guessed.

docs/HARDENING.md publishes the adversarial review rounds behind that: what each one found, including regressions introduced by earlier fixes, and the gaps still open. A security tool that hides its known gaps is worse than one that names them.

Treat it as alpha. Your data is inherently recoverable (git history plus your local transcripts), but read the residual limitations before pointing it at a repo you would be upset to lose.

Tested

313 unit and 545 end-to-end tests. CI runs shellcheck, macOS and Ubuntu, plus a real Apple openrsync against GNU rsync 3.4 over an ssh hop, in both initiator and peer roles.

Every behavioural protection is mutation-verified: the protection is broken in a copy and a named test is required to fail. A fix whose test still passes with the protection deleted is not a fix.