Inspiration
AI changed how code gets written. It didn't touch what happens after: someone still has to name the branch, write the commit, push, and open the PR by hand. That handoff is repetitive and easy to get wrong. Branch → PR should work like muscle memory, not a form you fill in from scratch every time.
What it does
RepoFox reads your repository and proposes the branch name, commit message, and PR details before you ask. You get a real suggestion to edit or confirm, not a blank box.
It runs in the terminal, VS Code, and Cursor, so the shipping step stays where you're already working. The record it creates isn't locked to one editor.
The unlock: Snapshot Engine
RepoFox doesn't stop at generating commit messages. Every protected Git operation writes a local receipt and a local recovery snapshot. You can inspect a receipt later. You can restore an eligible snapshot without touching the original receipt or deleting remote history. Recovery is explicit and repeatable, not a silent background process.
How it works
- Trigger a Branch → PR workflow.
- RepoFox grounds a branch, commit, and PR proposal in your repo's actual context.
- You review, edit, or confirm each step.
- RepoFox writes the executed operations and snapshots to Git metadata.
- Pull up the same receipt from CLI, VS Code, or Cursor. Restore a local snapshot if you need to.
Built with Codex and GPT-5.6
RepoFox already existed before Build Week. During OpenAI Build Week, I used Codex with GPT-5.6 to build the repo-scoped workflow ledger, the CLI's status/history/restore commands, shared adapters for VS Code and Cursor, and the restore logic for completed receipts. Codex sped up implementation, tests, release docs, and the end-to-end audit. BUILT_WITH_CODEX.md in the repo draws the line between this Build Week work and the earlier baseline.
Challenges I ran into
Generating Git text was never the hard part. Keeping automation trustworthy once it crosses Git boundaries was. RepoFox separates the proposed action from your approval, logs what actually happened, and treats recovery as a core feature, not a bolt-on.
Accomplishments that I'm proud of
I'm proud of shipping a repository-scoped workflow ledger that survives across editors. A commit made from the terminal shows up as the same receipt in VS Code and Cursor. That sounds obvious until you try to build it: three different extension hosts, one shared source of truth, zero drift.
Recovery works without touching remote history. Snapshot, inspect, restore, all local, all explicit. No developer has to trust a black box with their git history.
I wrote BUILT_WITH_CODEX.md and kept it honest. Every line built during Build Week is separated from the pre-existing baseline. No inflated scope, no hiding what Codex did versus what already existed.
What I learned
The hard problem in dev tooling isn't generation, it's trust after the automation crosses a boundary it can't undo. Anyone can generate a commit message. Nobody trusts a tool that silently rewrites git state. The moment I treated "what happened" as a first-class artifact, separate from "what we're suggesting," the product got harder to build and easier to trust.
Multi-surface consistency is a distributed systems problem wearing a developer-tools costume. CLI, VS Code, and Cursor each have their own execution context. Keeping one receipt format across all three forced me to design the ledger before the UI, not after.
What's next for RepoFox
RepoFox becomes the shipping layer the same way Stripe became the payments layer: Cursor owns writing code, CodeRabbit owns reviewing it, RepoFox owns getting it from done to merged.
Near-term: JetBrains and Vim support, a CLI-first workflow engine in Rust so the core logic isn't locked to one runtime, and MCP support so agents like Claude Code and Codex can trigger RepoFox directly instead of shelling out to raw git.
Mid-term: Team Profiles — a .repofox/profile.yml that encodes a team's real commit and branch conventions, learned from git history and enforced as hard gates before push. Public, forkable, versioned. That's the network effect: once a company's profile becomes the reference standard other teams extend from, RepoFox stops being a tool people install and becomes infrastructure people build on.
Everything stays local-first and OSS at the core. Paid tiers buy convenience, not features — self-hosting the full stack should always work.
Log in or sign up for Devpost to join the conversation.