FredrinA ticket in local git mode still gets its own branch, its own worktree and its own Worker. Only the last two steps change: Review shows a local diff instead of a pull request, and Ship is a local squash-merge instead of a GitHub merge. Merging still auto-completes the ticket and moves it to Completed. Only the signal differs.
Everything that needs a remote is what you give up: no pull request, no CI status flowing back onto the card, and no push. Those are progressive enhancements, not prerequisites.
Starting without a GitHub account
First run asks how Fredrin should ship your work before it asks for anything else. Pick Local git and the GitHub App permissions step and the gh CLI check are removed outright rather than skipped, so neither ever runs.
After that, Add a project gives you two GitHub-free ways in:
- Open a folder: a checkout you already have on this machine. Fredrin takes the project name from the folder. If the repo turns out to have a remote, that is stated rather than blocked; local mode works fine on it.
- New project: Fredrin creates the repository with
git init, aREADME.md, a.gitignoreand a stubAGENTS.md, then a singlechore: initial commit.
New project never writes into a folder that already holds something. A missing folder is created, an empty one is used in place, and anything else is refused by name. If a step fails partway, it rolls back, so retrying is never blocked by the previous attempt.
The board you land on is not empty: the first ticket asks what you are building and fills in AGENTS.md and CONTEXT.md for you. It sits in Backlog and does not run until you press Build.
Reviewing and shipping
Review is the same job it always is (read the diff and decide), except that the diff is local, computed against the base branch in your own repository.
Ship squash-merges the ticket branch onto the base branch in your real checkout. Because there is no pull request to close and no "revert this merge" button, the pre-flight is deliberately conservative: it never stashes, resets or discards anything. If it cannot merge cleanly it refuses and names the reason, most actionable first:
| It says | What to do |
|---|---|
| The branch does not exist | The ticket's branch was deleted; re-run the ticket |
| Nothing to merge | The Worker made no commits on that branch |
| Conflicts | Resolve them yourself, then Ship again |
| Uncommitted changes in your checkout | Commit or clean your working tree first |
| The base branch is checked out in another worktree | Close that worktree; git will not check the branch out twice |
Connecting GitHub later
Asking for GitHub is the switch. Turn Local git mode off in Settings → Git and a Publish to GitHub pre-flight appears underneath it. That is the one way to promote a local project, and it is a pre-flight rather than a button: it names each check and prints the exact git it will run before you press it. Nothing has left your machine at that point; the flip only says what you want.
It tests ancestry, not emptiness, so an already-half-pushed repo is resumable and a repo whose history a push would destroy is not waved through:
| Destination | What happens |
|---|---|
| No commits | Push straight in |
| Remote is behind local | Fast-forward push |
| Remote is ahead of local | Pull first, so the push is not rejected |
| Diverged, but with a shared history | Merge, then push |
| Unrelated histories | Refused. No force, no override |
The reconcile is a merge, never a rebase: ticket branches are cut off local commits, and rewriting their SHAs would strand every in-flight ticket. A merge that conflicts is unwound and the paths are named, so the tree you come back to is the one you left.
Only the default branch is pushed. Ticket branches stay local, so a ticket already in Review finishes as a local diff, and tickets started after the flip open pull requests. Your GitHub account is linked to your existing workspace, never signed in as a second user.
Publishing runs on the machine holding the repository, and nowhere else.
If you do not see these options
Local git mode is offered per platform, so the first-run fork and the New project cell appear only when your Fredrin deployment enables it and you are on the desktop app. Open a folder needs less, because any desktop build has it, so a two-cell strip instead of three means the shell is older, not that the feature is off.