Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 

Repository files navigation

fairway

Tools for concurrent Claude Code sessions — hooks that keep parallel agents aware of each other, and warn at the moment one is about to step on another session's changes.

The problem

If you run several Claude Code windows at once, you already know the failure mode: two sessions co-authoring one repo, one of them runs git add -A or a merge, and an hour of a peer's uncommitted work is contaminated or gone. Analysis of a hundred-odd real sessions over two weeks produced the finding fairway is built on:

Parallelism is not causing the failures. It is amplifying their blast radius.

  Terminal 1 (feature work)             Terminal 2 (same checkout)
  ┌────────────────────────┐            ┌────────────────────────┐
  │ Claude A               │            │ Claude B               │
  │ editing src/auth/*.ts  │            │ about to `git merge`   │
  │ 3 files uncommitted    │            │                        │
  │                        │  ◀──────   │  ⚠ warned BEFORE the   │
  │                        │  fairway   │    merge — names the   │
  │                        │  hook      │    peer and the paths  │
  └────────────────────────┘            └────────────────────────┘

Prior similar issues in other projects, all open:

The solution

Live interrupts, derived from your own usage: fairway insights reads your session history, finds your antipatterns, and turns them into rules. For example:

  • On git add -A or an unapproved git resetdeny, with the reason: the sweep stages files the commit message will never describe. A peer's work at worst, wrong git blame forever at best
  • On merge / rebase / checkout over a dirty tree — check for other live sessions in the repo, and warn, naming the peer and the uncommitted paths that might be theirs
  • On writing a numbered file (issues/NN-*.md) — check the number isn't already taken by another session, and deny with the next free number
  • On an oversized tool result — warn that it will be silently re-read on every subsequent turn, and to write it to a file instead

The ruleset stays deliberately short — every rule traces to an incident that actually happened.

How it works

One dependency-free Go binary, two roles:

Subcommand Role Can it block?
fairway hook pretooluse Involuntary, deterministic guardrails on every tool call Yes — but almost never does
fairway insights Reads your own session transcripts and derives your patterns, so the rules are tuned to how you actually fail

The rules are diagnosis-driven: insights scans the same local JSONL transcripts Anthropic's /insights reads, measures where your turns are actually wasted, and those measured values become the thresholds — instead of one generic ruleset for everyone.

The hook sits on every tool call, so it's built to be unnoticeable: ~5ms end-to-end on the ordinary path (mostly process spawn — the check itself is sub-millisecond), and the heavier peer lookup (~20–30ms) runs only after a cheap match has already flagged a hazardous command. Ordinary tool calls never pay it.

A real intervention

This fired during real work, not a demo — one session preparing a merge while a second session held uncommitted files in the same checkout:

fairway shared-checkout warning (not a block): you are about to run `git merge`
while this repo has 3 uncommitted path(s) AND 1 other live session(s) working
in it: <peer> (idle 0s). Some of that work may belong to the other session.
Confirm none of it is theirs — or say so to the user — before rewriting the
working tree.

The agent stopped, checked the claim, and reported to the human before continuing — without ever having been told the protocol existed. That's the product: the warning arrives before the destructive operation, addressed to the party with its hand on the lever.

Related projects

  • claude-peers-mcp — let your Claude Code instances discover each other and send messages that arrive instantly
  • cross-claude-mcp — a message bus across Claude, ChatGPT and Gemini
  • claude-code-hooks — a library of ready-made hooks plus an installable marketplace: safety, cost, observability
  • Anthropic's /insights — retrospective analysis of your own session history, free and in-product
  • fairway (this project) — reads your own history to find where you lose turns, then enforces the result at the moment you act

The others are pipes, reports, or one-size-fits-all rules. Fairway is the loop closed: measured diagnosis becomes live enforcement.

Why "fairway"

A fairway is the safe route through a hazardous space: in a harbour, the marked channel deep enough to navigate; in golf, the mown strip you're aiming for.

Status

Early and in daily use by its author — the rules are being tuned against a live multi-session workflow before the code is published here. This README is the front door while that happens.

Rules are plain Go and adding your own will be the point. In the meantime, if you have an antipattern that's cost you real work — yours or your agent's — open an issue: the catalogue of what's worth catching is as much the product as the code.

FAQ

Why not just one window? Genuinely parallel work across independent projects is fine and costs nothing — that's most multi-window use. Fairway targets the case that looks identical from inside a window but isn't: two sessions co-authoring one deliverable.

Isn't this what hooks toolkits do? Hook collections like claude-code-hooks ship the same static rules to everyone; analyzers like Anthropic's own /insights diagnose your usage and stop at a report. Fairway closes the loop: your measured patterns become live enforcement.

Isn't this what peer-messaging tools do? No — those are pipes (claude-peers-mcp, cross-claude-mcp). They let sessions talk when someone asks them to. Fairway never asks: the hook fires whether or not the agent thought to check, which is the whole point — the failures happen precisely when nobody thought to look.

About

Tools for concurrent Claude Code sessions — hooks that keep parallel agents from stepping on each other's changes

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors