Sessions on branches you already have, hooks that add up, and a What's new window
Sessions can now start on a branch that already exists, repository hooks run alongside the ones you set up rather than replacing them, and every release explains itself — in the app and on the web.
Release notes you can actually read
Plexus now keeps a changelog. Every release is published at runplexus.com/changelog, and the app shows you what changed in a What's new window the first time you run a new version — one tab per feature, so each one gets room to explain itself rather than a single line in a toast.
You will only ever see it once per version. If you skipped a few releases, they are all there, selectable from the top of the window. You can reopen it any time from Settings → About → What's new.
Repository hooks run alongside your own
A repository that commits a .plexus/hooks.json used to replace the hooks you had set up in
Plexus for that project — every event, even the ones the file says nothing about. Both sets run
now. Cloning a repo still gets you the team's setup, and it no longer costs you the hooks you
added for yourself.
How repository hooks combine with yours (Settings → Worktrees & Hooks) decides which set goes first: the repository's hooks first (the default), yours first, or repository hooks only. That last value is the old behaviour, if you want it back. Like the other hook settings it layers global → workspace → project, so one choice can cover everything and a single project can still differ.
If you used repository hooks before this version
Hooks you set up in Plexus for such a project start running again the next time a session starts, resumes, or is torn down — including the teardown that runs when you delete a session or a project. Open Settings → Worktrees & Hooks on the project to see exactly what will run; the editor points this out once, on projects that have both.
Plexus tells you when a connection needs renewing
GitHub and Bitbucket grant a token the permissions the app had at the moment you signed in. If that set later changes, your existing connection quietly keeps the narrower access — and refreshing it in the background never widens it. Until now you found out when something failed: a repository search that couldn't list anything, or a pull-request status that stopped updating.
Plexus now checks for itself, shortly after starting and occasionally while you work. When the access no longer covers what it needs, a notice names the missing permission — in the wording the provider itself uses, like Bitbucket's Workspace membership: Read — and offers Reconnect right there, so you sign in without leaving what you were doing.
It then re-checks before telling you it worked. Signing in again is not what clears the warning; the check is. So if a reconnect happens to land on the same narrow access, Plexus says so plainly and stops asking, rather than sending you round the same loop. Settings → Git providers keeps showing the warning until a check finds the access restored, and a later permissions change raises a fresh notice — dismissing one never silences the next.
Two settings under Settings → Git & PRs → Connection checks control it: Check that provider connections still work turns it off entirely, and How often to check provider connections (hours) spaces the checks out on a metered connection or a rate-limited account.
Settings grouped into sections
Settings pages are no longer one long list. Related settings now sit together under a heading with a line describing what the group covers — Pull requests, Code review, Fetching and remotes, and so on. Nothing moved between pages, so anything you knew where to find is still on the same page.
Override one group at a time
On a workspace's or project's settings, Override parent settings now belongs to each section rather than to the whole page. You can override Copied files for one project and leave Session folders and Lifecycle hooks inheriting, and turning a section back off clears only that section's overrides.
One consequence worth knowing: if you had previously overridden a whole page to change a single value, only the sections you actually edited will show as overridden. Nothing you set has been lost — the rest of that page was inheriting all along, and now says so.
Start a session on a branch that already exists
Starting a session always cut a new branch for it. Now the New session dialog has a mode switch: keep New branch for that, or pick Existing branch to check out a branch that is already there. Point a session at a colleague's pushed branch to carry it forward, or at one you have been asked to look at, and review it with the agent in a worktree of its own.
Branch is what gets checked out; Compare with is what the Review tab diffs against, what
Rebase onto… targets, and the base of any pull request you open. It defaults to your
repository's trunk — usually main — rather than whatever your main working copy happens to be
on, so a branch you did not cut is compared against something meaningful.
A branch that only exists on the remote works the same way: Plexus creates a local branch tracking it, so it starts at the remote's tip and ahead/behind counts are right from the start.
Git allows a branch in exactly one working copy at a time, so a branch that is already checked out is shown greyed out with the reason — the session holding it, your project's own working copy, or a leftover worktree record you can clear from the Git tab.
Pull base branch first becomes Pull the branch first in this mode: it fetches, then fast-forwards the branch you picked, so you do not quietly start on a copy from last week.
Plexus will not delete a branch it did not create
Cancelling a start, a setup script that stops the launch, or an agent that fails to start all clean up the session's working copy — but a branch that was already there is left alone. Only a branch Plexus cut for the session is removed, exactly as before.
Deleting one on purpose is still possible: Also delete the local branch asks a second time and names the branch, and it is never pre-ticked from your last answer the way it is for a branch Plexus created. Git then keeps any branch still carrying commits that are not merged anywhere else, and Plexus tells you it did. Deleting a project or workspace works the same way, listing the branches it did not create before it touches them.
One thing to keep in mind
Rebase and Squash rewrite the branch's history. On a branch you share with other people, that is history they may already have — so Plexus warns rather than stopping you. Nothing leaves your machine until you push, and Plexus never force-pushes.
The pull request conversation stays out of the way
The Pull request conversation section at the top of the Review tab now starts collapsed, so opening the tab shows you the diff rather than a wall of remote comments. Opening it is for the visit you're on — come back to the tab later and it's closed again.
Collapsed, its header still tells you what it's holding: a count of what's actually inside the section, an Approved or Changes requested chip when a reviewer left a verdict, and a warning triangle when only part of a very busy conversation could be fetched. Comment on the PR and Send N PR comments to agent stay where they were, so neither needs the section open.
Opened, the section takes at most about 40% of the tab and scrolls inside that, with its header staying put. A long conversation can no longer squeeze the diff off the screen.
The count now describes what's behind it
It used to count every thread on the pull request, including the ones that render against their diff lines further down. It now counts what opening the section actually gives you — the comments that have no home on a line, plus the review verdicts.
Approving without writing anything counts
A reviewer who clicks Approve and leaves the comment box empty — GitHub's default — used to be dropped entirely on the way in. If they had asked for changes earlier, Plexus went on reporting Changes requested long after they had approved. Empty-bodied decisions now come through and appear as a one-line entry with the reviewer's name and the verdict.
The chip also reads the review history correctly: each reviewer's most recent decision counts, so an approval replaces that same reviewer's earlier Changes requested, while one reviewer still asking for changes outweighs everyone else's approval.
Writing a comment has room of its own
Comment on the PR opens its box below the section rather than inside it, so the conversation's size limit never squeezes what you're typing, and collapsing the section while you write is a way to make room — your text stays put when you do.