ForkMesh is a complete code forge that lives on machines you and your community control — not on one company's servers. This page is the whole catalog: hosting, collaboration, AI agents, CI, chat, money, and the apps that tie it together. All of it works today.
The core bet: a repository should survive any single machine, company, or account. ForkMesh keeps real Git mirrors on real desktops and coordinates them through a routing layer that never becomes permanent repository storage.
Actively mirrored repositories live on independently operated nodes and refresh while their configured synchronization is healthy. External stubs are clearly labeled until a mirror accepts them; private replicas are opaque client-encrypted archives.
Read the blog post →The Worker stores signed discovery and generalized health metadata, not packfiles. Repository bytes stream from a selected independent origin over ordinary HTTPS.
Read the blog post →
git clone https://forkmesh.com/owner/repo uses normal
Smart HTTP while the Worker selects a fresh, healthy,
integrity-verified mirror behind the unchanged public URL.
Packs stream over HTTPS from the selected read-only gateway. The Worker proxies the response but never retains it as Worker or D1 repository storage.
Read the blog post →When an eligible, healthy, integrity-matching mirror exists, ForkMesh can fail over behind the same public URL. Sticky routing keeps one clone exchange on one mirror.
Read the blog post →Fallback serving is checked against integrity pins attested by the source of truth, so a mirror can prove it's handing you the same history the author published.
Read the blog post →Reported mirrors can be grouped by a signed repository root commit, independent of the local name each host chose.
Read the blog post →One command turns any Linux box or VM into a mirror node. The installer registers its account, syncs its repositories, and starts serving — no GUI required.
Read the blog post →The network page shows recently verified public nodes, generalized mirror health, and only optional telemetry each operator chose to publish.
Read the blog post →Bounded heartbeats, expiry, and live probes reduce stale presence while allowing the deliberately minimal real-time layer to lag.
Read the blog post →Collaboration records aren't rows in someone else's database. They are signed events committed into the repository itself — verifiable anywhere, hosted everywhere.
Nodes and people are identified by local Ed25519 keys. Profiles, catalog records, and every collaboration event carry a signature you can check yourself.
Read the blog post →Every issue open, comment, edit, and close is a signed event. Authorship is verifiable no matter which node — or which mirror — served you the data.
Read the blog post →PRs are signed patch submissions. Anyone can propose a change to any repository in the mesh and the maintainer can verify exactly who sent what.
Read the blog post →Issues, pull requests, discussions, and release notes are files committed to the repository. Clone the repo and you own the whole project history — code and conversation alike.
Read the blog post →Visitors can file issues and pull requests from the website even while the owner is offline. Signed submissions wait in an inbox; the owner reviews, commits, and the mesh syncs back.
Read the blog post →Pull requests can ride a live branch (diffs derived straight from the head ref) or carry a stored patch for cross-node and offline submissions — both merge the same way.
Read the blog post →Patches embed binary content, so images, fonts, and other assets survive the trip and merge cleanly — with a proper placeholder and badge in the diff view.
Read the blog post →A tracker that grows with the project — from a quick TODO to a milestone-driven roadmap — without leaving the mesh.
Open and closed states, priorities, assignees, and custom fields — all stored as signed events in the repository and browsable on the web.
Read the blog post →Drag issues across columns to plan work visually, right inside the desktop app.
Read the blog post →Group issues into milestones and watch live progress bars fill as work lands.
Read the blog post →Built-in burnup charts show scope and completion over time, so you can see a release converging (or not) at a glance.
Read the blog post →A prompt-style quick-add box captures an issue in one line — and can hand it straight to an AI agent as it's filed.
Read the blog post →Merge a pull request and its linked issue closes itself. One checkbox syncs the merge straight to main.
Read the blog post →Review with rich diffs, real mergeability checks, and an AI reviewer that doesn't just comment — it fixes.
Syntax-aware diffs with side-by-side image comparison and clear badges for binary changes — in the app and on the web.
Read the blog post →Every PR is checked with a true three-way merge against the live base branch, so "can merge" means it will actually merge.
Read the blog post →Inline comment threads, emoji reactions, and Markdown everywhere — signed like every other event.
Read the blog post →One click asks an AI reviewer for findings, each anchored to the exact lines as a mini-diff suggestion. Apply a single quick-fix or fix everything at once.
Read the blog post →
When a merge conflicts, hand the conflict to an agent that edits
the files in place and reports back — no manual
<<<<<<< spelunking.
Merge from the desktop client with the branch view, the PR view, or straight from an agent's completed session.
Read the blog post →Open an issue, hand it to an agent, get a pull request. ForkMesh treats AI coding agents as first-class contributors — with real sandboxed worktrees, live transcripts, and a native terminal.
From the issue detail, the quick-add box, or even the website's new-issue form: one click sends the issue to Claude Code or Codex, which works the issue and opens a PR when it's done.
Read the blog post →Each session runs on its own branch in its own worktree, so agents never trample your working tree — and finished work arrives as a reviewable pull request automatically.
Read the blog post →Run as many agents as you like across your issues at once, with live activity indicators showing who's working right now.
Read the blog post →Pick any conversation back up where it left off — sessions persist, survive restarts, and keep their full context.
Read the blog post →Agent sessions render as a live, structured transcript — tool calls, diffs, and results as cards, with a raw-output toggle for the curious.
Read the blog post →When an agent needs a decision, it asks — and the transcript shows an interactive multiple-choice card. Click an answer and the agent continues.
Read the blog post →A real VT100 terminal widget renders agent and workflow output with full color and emoji — not a flat log viewer.
Read the blog post →
The desktop app speaks the Claude Code IDE protocol: run
claude in a repo and it connects to ForkMesh for diff
views and selection context, just like an editor extension.
See your Claude 5-hour and weekly usage right in the app, updated every minute, so you always know how much agent runway is left.
Read the blog post →Replace the built-in agent workflow with your own preamble in Settings — your rules govern every session.
Read the blog post →Push, build, tag, publish — the whole delivery loop runs on the mesh.
Real workflows run on push, with the latest live log always one click away and full runs rendered in the native terminal.
Read the blog post →Workflow outputs are collected per run and browsable from the repository's Artifacts tab.
Read the blog post →Browse tags, mark the current release, and cut new releases in seconds — release notes live in the repository like everything else.
Read the blog post →Release binaries live in a content-addressed store keyed by SHA-256 — keeping the Git history lean while downloads stay verifiable end-to-end.
Read the blog post →
curl … | sh installs the desktop or headless node
with SHA-256-verified binaries — and a matching one-line
uninstaller when you need it.
Per-repository quality and security views keep checks, advisories, and repository health next to the code they describe.
Read the blog post →Contribution and activity insights per repository — see where the energy is going.
Read the blog post →Talk next to the code — encrypted before it ever leaves your machine.
Default rooms use a relay-derived AES-256-GCM shared key. They are authenticated and encrypted on the wire, but relay-readable; up to 500 persisted frames remain for 7 days.
Read the blog post →Message any node operator directly over the same relay-readable authenticated shared-key transport as rooms.
Read the blog post →Encrypted vaults for the things that don't belong in a repo: notes, credentials, plans. Documents live inside authenticated ciphertext, and every unlock is recorded in an access log the creator can audit.
Read the blog post →Longer-form threaded conversations per repository — signed, synced, and browsable like issues.
Read the blog post →Join the conversation from the browser too — the website speaks the same room protocol as the desktop app.
Read the blog post →A native Qt app that is a full forge: seventeen repository views from Code to Settings, plus the workflow tools you'd normally need three other apps for.
Code, Commits, Issues, Agents, Pull requests, Discussions, Actions, Security, Quality, Insights, Branches, Worktrees, Releases, Mirror nodes, Artifacts, Shortcuts, and Settings — every view one click apart.
Read the blog post →Stage, commit, branch, and manage multiple worktrees from the app — including the worktrees your agents are working in.
Read the blog post →Dictate issues, comments, and prompts with built-in Whisper speech recognition — transcribed locally, streamed live as you speak.
Read the blog post →Capture any region of the screen, annotate it with built-in drawing tools, and drop it straight into an issue, PR, or chat.
Read the blog post →A proper Markdown editor with preview for issues, PRs, discussions, and chat — plus emoji reactions and cross-references that link issues, PRs, and commits together.
Read the blog post →Repos, invites, and addresses render as QR codes for instant scannable handoff to a phone.
Read the blog post →Shortcuts for every major view and arrow-key navigation across tables keep your hands on the keyboard.
Read the blog post →Fork any repository in the mesh and choose exactly where the copy lands in your working tree.
Read the blog post →A crash handler, a UI stall watchdog, network backoff, and a network activity log keep long-running nodes healthy — and tell you exactly what happened when something hiccups.
Read the blog post →Community incentives are transparent and non-custodial. ForkMesh does not hold or control user funds; for community members it stores only an optional public payout address, while wallet keys and transfer approval remain on their owners’ devices. The first instance operator’s separate community-pool signer stays encrypted in that operator’s local Qt client. User-owned funds, the community-funded public pool, pending allocations, and completed on-chain transfers are separate states.
Enter the world immediately as a guest. Registration uses an email, password, and email verification; optional public identity and device fields remain configurable.
Read the blog post →Registered nodes can publish a generalized profile and public repositories. Optional platform, device, status, and activity fields follow the owner’s visibility controls.
Read the blog post →Publish a Solana address and accept donations with on-chain confirmation. Contributors sign direct transfers from their own wallet; ForkMesh never creates or stores a deposit key.
Read the blog post →Contribute directly from a self-custodial wallet, then choose an immediate split across the current eligible nodes or fund the transparent pool for later randomized incentives.
Read the blog post →Legacy Worker-custodied bounty funding is frozen for migration. New bounty flows require an owner-controlled external wallet, program, or multisig and independently verified public transfers.
Read the blog post →The production mainnet-beta community pool may reward eligible, integrity-verified nodes through the first instance owner’s local signer. Test networks require explicit development configuration; selection and payment are never guaranteed.
Join or fund the reward program →The mesh follows you: a phone app, a full web experience, and an extension for your editor.
Explore any published repository — files, commits, rich diffs, issues, and PRs — straight from forkmesh.com, streamed live from its host. No clone, no account required.
Read the blog post →
forkmesh.com/owner/repo takes you straight to the
repository. During an origin outage, the same link can keep
working when an eligible, healthy, integrity-matching mirror is
online.
Carry the mesh in your pocket: browse repositories, follow activity, chat, and get notifications from a native mobile app.
Read the blog post →ForkMesh issues in your editor's sidebar — with one-click "start with Claude Code" or "start with Codex" on every issue. Works in VS Code, Cursor, Windsurf, and friends.
Read the blog post →Searchable documentation covering encrypted mirrors, direct-HTTPS routing, cloning, and the collaboration protocol.
Read the blog post →A public status page, a blog, and a human-readable changelog keep the network's story out in the open.
Read the blog post →Everything above serves the same idea: your code, your conversations, and your community should never depend on one company staying online — or staying friendly.