Open in Editor

Reading a diff only gets you so far — sooner or later you need to see the callers, run the tests, and put your cursor on the actual code. Open in Editor closes that gap: from any file or line in PR Flow's review view, one click (or one keypress) opens your local editor at that exact spot. And when you want the code itself, PR Flow fetches and checks out the PR's branch for you — no provider-specific ref incantations to remember.

Map a repository

Open in Editor is opt-in per repository: PR Flow never touches your filesystem for a repo you haven't mapped.

• From Settings: go to Settings → Repositories, pick a repository (the list is pre-filled from the PRs on your board), and choose its local folder.
• From a review: the first time you hit the Editor button on an unmapped repo, a small setup card offers to map it right there — choose the folder and the buttons go live without leaving the review.

PR Flow validates the mapping before saving it: the folder must exist, be the root of a git repository, and have a git remote that actually points at the mapped repository. A mismatched remote is refused outright — opening files from the wrong checkout would be confidently wrong.

Tip: map a dedicated review clone rather than your day-to-day working tree. Checkout sync always refuses to touch uncommitted work, and a clean clone keeps that friction-free.

Choose your editor

In Settings → Repositories you pick where files open:

• VS Code — uses the standard code command.
• JetBrains — uses the IDE's shell launcher (idea, webstorm, pycharm, ...).
• Custom — any command template with {file}, {line}, and {dir} placeholders, for Sublime, Zed, Neovim, or anything else. The command runs directly, never through a shell.

Jump from the diff

With a repository mapped, the review view grows editor affordances everywhere you'd want them:

• an Editor button on every file header opens that file;
• a hover button on every diff line opens the file at that exact line;
• the O shortcut opens whatever file or finding the keyboard focus is on (remappable in Settings → Shortcuts, listed in the in-review cheatsheet).

Renamed files are handled gracefully: if the new path doesn't exist in your checkout yet, PR Flow opens the pre-rename path and says so. Your review state — staged comments, verdict, focus — stays exactly where you left it; the editor hop is an aside, not an exit.

Sync the PR branch locally

A chip in the review header shows where your local checkout stands: at PR head, behind, dirty, or needing attention. When you're behind, hitting Sync shows exactly what will happen — the ref to fetch, the remote, the branch name, and the folder — and does nothing until you confirm.

• Works across GitHub, GitLab, Gerrit, and Azure DevOps — PR Flow knows each provider's ref scheme so you don't have to.
• Checkout lands on a normal local branch (like pr/1284, or change/1284/5 for a Gerrit patchset).
• Uncommitted changes are never touched: a dirty working tree is refused with a clear message, always.
• Branches are never force-updated: an existing branch is fast-forwarded when possible and refused with an explanation when it has diverged.
• Every fetch and checkout is recorded in Settings → Logs, alongside PR Flow's other write actions.

For team admins

Open in editor is a managed feature: a team administrator can lock it on or off for every seat from the team admin console, like any other managed feature. It ships enabled — and stays inert until someone explicitly maps a repository.