grite vs GitHub Issues
Hosted issue tracker, tied to a GitHub repository
GitHub Issues is excellent at one thing: collecting reports from the public. Grite is excellent at a different thing: running the internal task graph offline, across multiple agents, with the issues physically inside the repo. Many teams use both.
| Feature | grite | GitHub Issues | Edge |
|---|---|---|---|
| Storage model | Append-only event log in refs/grite/wal | Hosted relational database on GitHub | grite |
| License | MIT, source on GitHub | Proprietary hosted service | grite |
| Offline support | Every operation works offline | Read-only via gh CLI cache, writes need network | grite |
| Sync mechanism | git fetch / git push (CRDT merge) | GitHub REST/GraphQL API | grite |
| CLI surface | Native; --json on every command | gh CLI (separate tool, wraps the API) | grite |
| Public inbound surface | None by design | Excellent — anyone with a GH account | GitHub Issues |
| AI-agent affordance | AGENTS.md auto-generated; memory labels | Generic API access via gh / REST | grite |
| Multi-agent merge | Deterministic CRDT, never conflicts | API rate limits, last-write-wins | grite |
| Audit / provenance | Optional Ed25519, content-addressed WAL | Server-side audit log | grite |
| Hosting requirement | Any git remote works (or none) | Requires github.com | grite |
| Web UI | None — CLI and export only | Mature web UI with attachments | GitHub Issues |
| Ecosystem integrations | Anything that can shell out | Massive — Actions, Apps, marketplace | GitHub Issues |
Pick grite when
- ▸You want issues to be offline-first and travel with the repo when you clone
- ▸You want CRDT merge semantics so parallel agents never produce conflicts
- ▸You want a tamper-evident, optionally Ed25519-signed audit trail
- ▸You want a CLI-first workflow with --json on every command
- ▸You are tired of GitHub being a network dependency for "where am I in the work"
Pick GitHub Issues when
- ▸You need a public-facing inbound surface that non-contributors can use without installing anything
- ▸You depend on GitHub Projects, Actions integrations, or the Issues web UI for triage
- ▸Your workflow is fundamentally web-first and the CLI is not where decisions happen
Both can be right
Many teams keep GitHub Issues for what it is great at and adopt grite for the internal queue, agent memory, or offline-first work. The export formats make it cheap to move issues either direction.