Plexus changelog

v1.3.1 — Bitbucket's new SSH address

2026-10-29T00:00:00Z

Bitbucket is moving git over SSH to a new address. This release makes sure Plexus keeps up with the move, and offers to update your projects for you.

Bitbucket's new SSH address

Bitbucket is moving git over SSH from bitbucket.org to ssh.bitbucket.org. From 12 November 2026, Bitbucket will block SSH on bitbucket.org during scheduled windows that get longer each week, and on 10 December 2026 it stops for good. Remotes that use HTTPS are not affected.

Plexus now recognises SSH remotes on ssh.bitbucket.org as Bitbucket. Pull requests, CI status, Open on Bitbucket and cross-device sync keep working after you switch a project over, and a project you have switched still matches the same project on a machine that hasn't switched yet. SSH remotes on altssh.bitbucket.org and GitHub's ssh.github.com are recognised too.

Updating your projects

When a project still has an SSH remote on bitbucket.org, Plexus shows a notice: Bitbucket is moving SSH to ssh.bitbucket.org, with Review and Not now.

Review lists each remote that needs to change, with its current address and its new one. A checkbox, ticked by default, also adds Bitbucket's published host keys for ssh.bitbucket.org to your known_hosts file. Without them, ssh stops to ask whether you trust the new host the first time it connects, and Plexus's background fetches and the commands your agents run have no way to answer. Nothing is changed until you click Update.

Not now puts the notice away. It comes back the next time you open Plexus, for as long as a project still uses the old address.

Plexus never edits your ~/.ssh/config. If the old address comes from there, through a Host alias, or from a git insteadOf rule, or if a Host bitbucket.org block picks your key, the dialog shows you the exact line to change instead. If your SSH config already sends bitbucket.org to ssh.bitbucket.org, Plexus leaves those remotes alone.

From 12 November, if a fetch or push fails because a remote still uses the old address, the error tells you that Bitbucket is phasing out SSH on bitbucket.org and how to fix the remote.

v1.3.0 — The Stack map

2026-10-19T00:00:00Z

Stacks get a new home. Every session now shows its state as a small chip, a stacked session gets a Stack panel that draws the whole stack as a map with a merge button underneath, and a stack on GitHub becomes one of GitHub's own stacked pull requests. Syncing now works around your uncommitted changes, conflicts go to the session's own agent, and there are no more Retry buttons.

The Stack map

A stacked session's context bar now has a Stack pill, such as Stack 2 of 3. Click it to open the Stack panel beside the session. The panel draws the stack from top to bottom, with your base branch at the bottom. For each layer it shows the pull request's number and title, the session's name and its state, plus three facts: the checks, the review and whether the branch is synced. The layer you have open is highlighted. If it needs you, a banner says why and gives you the one thing to do about it.

A session that isn't stacked but has an open pull request gets a pill with the PR number. It opens the same panel for that one pull request.

Moving between layers

⌥↑ and ⌥↓ (Alt+↑ and Alt+↓ on Windows and Linux) open the session one layer up or down the stack, with its panel. They work even while the agent terminal has focus, and you can rebind them under Settings → Shortcuts.

In a narrow window the panel opens over the session instead of beside it. In a split view, each pane has its own panel.

Merging a stack

The merge button at the foot of the Stack panel merges the layer you have open and everything below it. Its label tells you how far it goes: Merge on the bottom layer, Merge 2 on the second and Merge stack on the top. Merge up to here in a stacked session's ⋯ menu does the same thing. Until every layer it would merge is ready, the button is disabled and names what it is waiting for, such as Waiting for checks on #128.

Every merge asks once. A short confirmation lists the pull requests, the branch they go into, whether GitHub merges them together or Plexus merges them one at a time, whether the branch requires a merge queue, what moves next, and the merge method. While the merge runs, the rows read Merging and the panel shows its progress with a Pause button. A progress strip in the context bar, GitHub is merging 2 or Merging 1 of 3, keeps it in view from any session of the project. When it's done, one notification says what merged.

This replaces Land stack… and the Land queue panel on the project dashboard.

A state on every row

Every session now shows its state as a chip in the sidebar, on both dashboards, in split-view panes and in the context bar. The states are Behind, Syncing, Waiting for agent, Agent resolving, Checks running, Needs review, Ready to merge, Merging, In merge queue and Merged. When something is stuck, an amber Needs you chip gives the reason. A session with nothing to report shows no chip.

Each Needs you state comes with one action, such as Resolve with agent, Ask agent to commit, Open checks, Open on Bitbucket or Sync now. You'll find it on the chip, and as a button in the context bar. The sidebar's need you count includes these, and counts each session once.

No more Retry

When a sync or a merge stops on something that needs you, fixing the cause is enough. Once the checks pass, the conflict is resolved, the pull request is reopened or the agent has finished, Plexus notices and carries on by itself. A merge that stopped on a closed pull request waits until it is reopened or taken out.

Notifications are fewer, too. You get one when something needs you and you aren't looking at that session, when Bitbucket needs you to add a pull request to its merge queue, when a merge finishes, and when an error needs you. Everything else now shows on the row itself.

Stack on…

You can now stack a session that already exists. Choose Stack on… in its ⋯ menu and pick the session it should sit on. The picker explains what will happen: the session syncs onto the one you pick, and its pull request will target that session's branch. It only lists sessions it can actually be stacked on.

New session on top… is now called New stacked session….

Stacks on GitHub

On GitHub, a stack's open pull requests now become one of GitHub's own stacked pull requests. This happens automatically when there are two or more of them, one on top of the other. GitHub then shows the stack itself, and the Stack panel's header reads GitHub stack. Where GitHub shows the stack, Plexus leaves its own stack list out of the pull request descriptions. A stack of yours that branches usually isn't grouped, because GitHub's stacks are a straight line, so the description list still covers it.

Merging from a GitHub stack takes one step: GitHub merges the pull requests you chose together, through its merge queue when the branch requires one, and retargets the rest itself. If you stacked pull requests on GitHub yourself and each one belongs to a session in the project, Plexus nests those sessions to match.

You can turn this off with Create stacks on GitHub under Settings → Git ▸ Stacks.

Bitbucket's merge queue

When a Bitbucket branch requires its merge queue, Plexus now goes through the queue and never merges past it. Bitbucket doesn't let other apps add to the queue, so that one click is yours. The row reads Needs you: add to merge queue, names the queue (and says if it is paused), and offers Open on Bitbucket. Once Bitbucket reports the pull request queued, the row reads In queue, then Merged, and merging carries on.

If other sessions are stacked on that pull request, Plexus first asks Bitbucket to keep its branch after the merge. That way the pull requests above it can move onto your main branch before the branch is deleted.

Syncing around your work

Restacking is now called syncing, and it no longer stops for uncommitted changes. Plexus syncs around them and leaves your uncommitted files exactly as they are. It only stops if your edits touch a file the sync has to change. Then nothing is changed and, by default, the session's agent is asked to commit or stash its work so the sync can run.

When a sync conflicts, Plexus undoes it and, by default, hands the conflict to the session's own agent. The hand-off now always arrives: if the agent is in the middle of a turn, it gets the conflict when the turn ends. Each conflict is handed over once. If the agent can't resolve it, the row says so rather than asking again.

A sync that you or the agent finished by hand is now recorded and pushed. After that, the next sync no longer replays commits the parent session has since rewritten. A push that failed is tried again. When GitHub has already rebased a branch the same way, Plexus takes GitHub's version instead of stopping on a refused push.

Merge in order

The land queue for pull requests that don't depend on each other is now Merge in order. Choose Add to Merge in order in a session's ⋯ menu, open any of those sessions to see the numbered list in its Stack panel, drag rows into the order you want and click Merge 3. Plexus merges them one after another, syncing the next one onto your main branch when it needs it and waiting for its checks. If anything needs you, it waits and carries on once it's fixed. The list only merges when you click its own merge button, and on the dashboards each of its rows shows its place, such as 1 of 3.

Stacks settings

The Stacked PRs settings are now called Stacks, under Settings → Git ▸ Stacks. They use the new words, such as Sync stacked sessions and Push after syncing.

When a sync conflicts replaces the two conflict settings, one for restacking and one for landing. It covers conflicts both while syncing and while merging, and defaults to Hand it to the session's agent. For conflicts while merging that is a change, because the landing setting used to ask first. If you had set either old setting to stop, or the landing one to ask first, updating keeps your choice.
Create stacks on GitHub is new, and on by default.

Stacks & ordered merging

What a plan called stacked pull requests with a land queue is now called Stacks & ordered merging. It is still the same part of a plan, and it is still one of the seven things a plan unlocks. Everything in this release that links, syncs or merges for you is part of it: Stack on…, GitHub stacks, the merge buttons, Merge in order, Sync now, Resolve with agent and Ask agent to commit.

Nothing that worked without a plan has moved behind one. The state chips, the Stack pill and the Stack panel's map are free for everyone, as are Unstack, Remove from Merge in order and every action that only opens something.

v1.2.1 — Status that keeps up with Claude Code

2026-10-16T00:00:00Z

The activity dot and the blue ring now keep up with how Claude Code works today: workflows stay on the ring until they finish, the dot follows Esc and approved prompts by itself, and only the prompts that need you turn it amber.

Workflows keep the ring lit until they finish

A Claude Code workflow now lights the blue ring for its whole run, through the gaps between its phases, and counts as one item. Before, the ring went dark a few seconds after a workflow started, and a session could tell you it needed your input while the workflow was still running. Now the session stays quiet until the workflow, and any other delegated work, has finished, and then tells you once.

Hover the dot to see what is running, for example "Waiting for input — 1 workflow (4 agents), 2 subagents running · 1 background shell". A workflow is listed once, with the number of its agents that are still running.

The ring now covers the same work Claude Code itself counts as keeping a session busy: background subagents, workflows, agent-team teammates and cloud sessions. Claude Code now runs subagents in the background by default, so you will see the ring more often than before. Background shell commands and monitors don't light the ring, because a dev server left running would keep it lit for hours, but the tooltip still mentions them. The delegating counts on a collapsed project, in the workspace switcher and on the dashboards now count background tasks, and a workflow counts once.

The dot follows Esc and approved prompts

Press Esc to interrupt a turn and the dot turns amber within a few seconds. Before, it stayed green until your next prompt. Approve a permission prompt and the dot goes back to green while the agent carries on, instead of staying amber until the turn ends.

Plexus now also checks the dot against Claude Code's own record of what each session is doing, and corrects it when the two disagree. Hooks are still the instant signal, and that record never overrides a hook that reported something more recently. With older versions of Claude Code, Plexus picks up the same two moments from the session's conversation instead.

Forking a conversation with /fork or /branch no longer stops the dot from updating.

Check activity hooks… in a session's ⋯ menu now shows more: what Claude Code's own record says about the session and how recently it was updated, what last moved the dot and why, and what is running in the background, by kind.

Only prompts that need you turn the dot amber

Claude Code sends some notifications only to keep you informed, for example when a background agent finishes, when a sign-in succeeds, or about a usage limit. These no longer turn a working session to Needs you, and no longer alert you. Permission prompts, Claude Code's reminder that it is waiting for your input, and questions from a tool still turn the dot amber, as before.

One Plexus per data folder

If you open Plexus while it is already running, the second copy now tells you Plexus is already running and closes. Before, it started anyway and marked the sessions running in the first copy as stopped, even though their agents were still running. Restarting Plexus to install an update still works: the new copy waits a few seconds for the old one to close.

v1.2.0 — Plnnrly in the Toolchain

2026-10-15T00:00:00Z

A Plnnrly project can now sit in your Toolchain next to your code: its backlog, its board and its sprints in a tab, and any work item a click away from a session that is linked to it.

Plnnrly in the Toolchain

If your team plans its work in Plnnrly, a Plnnrly project can now be worked inside Plexus the way a GitHub repository's issues can — its backlog, its board, its sprints and every work item in it — and any work item can start a session that stays linked to it. Everything goes from your machine straight to your own Plnnrly organization; nothing about it passes through us.

Connect your organization

A new Integrations page in Settings holds your connections to services that are not git hosts. Under Plnnrly, choose Add Plnnrly organization, type the organization's address — its name, its plnnrly.com address or its own domain — and press Continue. Then Sign in with Plnnrly in your browser — the only way to connect, so there is no token to create, paste or rotate. Connecting needs a Plnnrly role that may manage API tokens, the same as creating one. Connect as many organizations as you work in; each row has Reconnect and Disconnect, and every sign-in is kept in your operating system's keychain.

A Plnnrly tab

On the Toolchain, a new Work management section has a Plnnrly card: pick the organization and the project, press Attach, and a Plnnrly · project tab appears on the strip. It has the views Plnnrly has — Backlog, Active sprint and All work for a project that runs in sprints, Board and All work for one that doesn't — with a search and filters for status, assignee, label, priority and type, and New work item.

Open a work item to change its title, description, fields and status, and to comment. The status menu offers only the moves the project's workflow allows, and the board does the same: drag a card to a column the workflow doesn't allow and it snaps back and says why. Descriptions keep their formatting and their mentions when you edit them. Reordering cards within a column works where your Plnnrly organization supports it. In a sprints project you can Start sprint, Complete sprint — choosing where the unfinished work goes — and move work items between sprints and the backlog.

Start a session from a work item

Every work item has Start session. The session is named after it — OPTH-186 The work item's title — so its branch is too, the agent can be handed the work item as its first prompt, and the session carries a Work item sidebar with the item beside the agent, editable, exactly like a GitHub issue's.

Part of your issue tracker in Plexus

The Plnnrly tab and its sidebar are part of your issue tracker inside Plexus — the sixth thing a plan unlocks, not a seventh — and need the same plan or seat as the Issues tab. Connecting an organization, attaching a project and the link a session carries are free.

v1.1.0 — New windows and split view

2026-10-15T00:00:00Z

Plexus is no longer one window, and no longer one session at a time. Put an agent on your second monitor, keep a dev server's terminal beside your editor, or put several sessions side by side in a split view and watch them all work.

Open in new window

A session, a project, a single terminal or the dashboard can now open in a window of its own. A session's window holds the whole session: the agent, the Review, Explorer and Git tabs, and its terminals. A project's window holds the project view, with its dashboard, Git client and terminals. These windows are kept plain, with just the session or project name along the top and the view below it (a terminal's window shows the terminal and where it belongs), because the main window already has the sidebar.

There are several ways to open one:

The window button in a session's or project's header, next to the close button.
Open in new window in a session's or project's ⋯ menu, in the sidebar or on a dashboard row.
Ctrl+Shift+N (Cmd+Shift+N on macOS) with a session or project selected. You can rebind it under Settings → Shortcuts.
In Ctrl+K search, Ctrl+Enter (Cmd on macOS) opens the highlighted session or project in a new window instead of the main one.
Right-click a terminal's tab and choose Open in new window.
Open dashboard in new window in the dashboard's header.

It moves, it doesn't copy

A session, project or terminal you open in a new window moves there, so the same terminal is never open in two places at once. In the main window its row shows a small window icon, and selecting it brings its window to the front. If the main window was showing it, it now offers Focus window and Bring back here. The dashboard is the exception: its window is a second live copy, and clicking a session in it opens that session in the main window.

The agent and your terminals keep running while they move, and they keep their recent scrollback.

Closing windows

Closing one of these windows brings what was in it back to the main window, still running. Closing the main window quits Plexus as it always has, and closes the other windows with it.

When you restart Plexus, your session, project and dashboard windows reopen where you left them. Terminal windows don't, because terminals end when Plexus quits.

Good to know

A session can't move while a review cycle, an AI review or an AI summary is running for it, while a git operation on it is in progress, while the Explorer has unsaved changes, or while it is still starting. The menu item says which.
Closing a session's window while one of those jobs is running in it cancels the job, so Plexus asks first.
Notifications and sounds still come once, however many windows you have open.

Split view

Put up to six sessions of the same project side by side. Each pane is a full session, with its own Agent, Review, Explorer and Git tabs and its own terminals, under a slim header with the session's name and status.

To make one, open a session's ⋯ menu and choose Add to split view ▸ New split view…, or choose New split view… in a project's ⋯ menu. Name it and tick the sessions you want. The same menu adds a session to a split view you already have.

A split view gets its own row in the project's session list, with its sessions listed under it. The row shows one dot per pane and takes the colour of the pane that most needs you, so a collapsed split view with an agent waiting on you still says so. Click the row to open the split view. Selecting any of its sessions, from the sidebar, search or a notification, opens it with that pane focused.

Working in panes

Click a pane to focus it. The focused pane is the one the top bar and your shortcuts act on. Every agent keeps running whether its pane is on screen or not.

Maximize pane in a pane's header fills the split view with it, and Restore pane brings the others back.
Layout in the split view row's ⋯ menu arranges the panes: Auto, Columns, Rows or Main + stack. Drag the dividers to resize them.
Ctrl+Shift+] and Ctrl+Shift+[ (Cmd on macOS) move to the next or previous pane, and Ctrl+Shift+Enter maximizes or restores the focused one. All three can be rebound under Settings → Shortcuts.

The layout, the pane sizes and the focused and maximized panes all come back after a restart.

Good to know

A session is in one split view at a time. The × in a pane's header takes it out again, and Dissolve split view turns all its sessions back into ordinary rows. Nothing is stopped or deleted either way.
Archiving or deleting a session takes it out of its split view. A restored session comes back as an ordinary row.
A pane's session can still open in a window of its own; its pane then offers Focus window and Bring back here.
Split views stay on this computer and are not synced.

Resolve landing conflicts with AI

A land queue on Bitbucket no longer stops on "You can't merge until you resolve all merge conflicts". This usually happened when several independent pull requests were queued: the first one landed on your main branch, and the next one then conflicted with it. Bitbucket doesn't report a conflict until you try to merge, so Plexus now checks with git on your machine before it merges. If your provider refuses a merge because of conflicts, Plexus handles it the same way.

When the next pull request conflicts, Plexus restacks it onto its base. If the restack conflicts, Plexus puts the branch back as it was and, by default, pauses landing on that pull request. Its row in the Land queue panel lists the conflicting files and offers Resolve with AI and Open terminal, and the toast that tells you landing paused has Resolve with AI too.

Resolve with AI hands the conflict to that session's own agent, in its terminal, so you can watch it work. The agent is given the exact rebase command and the conflicting files, and is asked not to push. Once it has finished the rebase, Plexus pushes the branch with a lease, waits for its checks and merges it, then carries on with the queue. Each conflict goes to the agent once: an agent that gives up pauses the queue and says so, rather than being asked again and again.

A new setting, When landing hits a conflict in Settings → Git ▸ Stacked PRs, decides what happens next:

Ask me before the agent resolves it (the default)
Resolve it with the session's agent and keep landing, without asking
Stop and let me resolve it

A branch you checked out from an existing branch is never rebased by landing; it still pauses and asks you to restack it yourself. A pull request that is only behind its base, with no conflict, is merged as it is. Plexus doesn't restack it, so the rest of your queue isn't force-pushed and doesn't run its checks again.

Coming back from a payment

When you finish paying for a plan and the invoicing provider sends you back to the Billing page on the account panel, the page now checks the plan straight away and tells you where it stands: Payment received — your plan is active, or that the payment is in but the provider has not confirmed it yet, which usually takes under a minute. Press Refresh to see the plan once it has.

If what you just bought was seats for an organization, you now land on that organization's Billing page instead of your personal one, with the same message.

Diffs beside the file list

In a project's Git tab, clicking a file now opens its diff where the commit graph was, to the left of the file list, instead of on top of it. The list stays where it is and you can keep using it while you read: click another file and the diff switches to it, or stage and unstage files without closing anything. The ✕, the Uncommitted or commit sha at the start of the diff's header, and Escape close the diff and bring the graph back.

This works for every file list in the tab: uncommitted changes, a commit's or a stash's files, a comparison, a file's history and blame. In a narrow window, where a diff beside the list would be too cramped to read, the diff still opens over the list as before.

Selecting several files

In the uncommitted changes, a plain click opens that file's diff. Ctrl-click (Cmd-click on macOS) or Shift-click to select several files, and the diff closes so you can see the graph again while your files stay selected. Deselect back down to one file and its diff opens again.

With files selected, the header now has a Stage and an Unstage button next to Discard, each showing how many files it will move. Right-click a file inside the selection for Stage N files, Unstage N files and Discard N files….

Drag and drop on Windows

Dragging inside Plexus now works on Windows. Until now, starting a drag there showed a "not allowed" cursor and nothing happened when you let go. That affected:

Dragging a branch or tag onto another in a project's Git tab to merge, rebase, fast-forward, push or start a pull request.
Reordering sessions and split views in the sidebar, panes inside a split view, and pull requests in the Land queue panel.
Moving cards between columns on a project board.
Dragging a field into a saved prompt, or moving one that is already in it.

Dropping a file from your file manager onto a terminal still pastes its path, as before. A field dragged from a saved prompt's palette can now only be dropped into that prompt, not into another application.

v1.0.1 — A Git tab that matches your history

2026-10-12T00:00:00Z

The project Git tab catches up with the dedicated Git clients: a graph that reads like your history, stashes and worktrees right on it, history you can edit and undo, and your pull requests, submodules and LFS files in one place.

A graph that matches your history

The project Git graph now lists commits newest first by date. On a repository where a long-lived branch keeps merging another one, the graph used to spread into dozens of lanes and push your other branches far down the list. Now it stays a few lanes wide, and the branches you worked on recently sit at the top.

A header runs along the top of the graph with Branch / Tag, Graph and Commit message columns. Drag any column's edge to resize it, and use the gear to add Author, Date and SHA. Each commit shows the first lines of its description after its subject, and a thin line with a label such as Yesterday or A month ago marks where each stretch of history begins. The target button in the header, or Ctrl+Shift+H (Cmd+Shift+H on macOS), jumps to the commit you have checked out.

The strip along the right edge is now the graph's only scrollbar. Drag it, click it, or use Page Up, Page Down, Home and End. Double-clicking a commit opens its details, and the parents in a commit's details are links. A commit, branch or tag menu can open it on GitHub or Bitbucket, a remote branch's menu can pull it into your branch, and the Pull menu has a Prune when fetching switch.

Checking out a remote branch

Double-clicking a remote branch such as origin/develop still puts you on your local develop and brings it up to date. Before, if your local develop had commits the remote didn't, Plexus quietly left it where it was and still said it had checked out origin/develop. Now it stops and asks. You can reset your local branch to the remote, optionally stashing your uncommitted changes first, or check it out as it is, or cancel. The message afterwards says what actually happened, for example "fast-forwarded 4 commits".

The same choice is on the branch menus as Reset to origin/develop… and Reset local develop to this….

Stashes and worktrees on the graph

Each stash now appears in the graph directly above the commit it was taken on. Click it to see the files it holds and what changed in each, and to apply, pop or drop it. Stashes can also be renamed now.

When one of your sessions has uncommitted changes, a // WIP row shows them in the graph above the commit that session's worktree is on. It names the session and counts the changed files. Click it to open the session.

Show or hide branches

Narrow the graph to the lines you care about. Click the eye next to a branch to hide it, or right-click a branch and choose Show only this branch. The gear in the graph's header can hide all remote branches, tags or stashes. A strip above the graph says what is hidden, and Show all brings everything back. Plexus remembers this per project.

Edit, squash and reorder commits

Right-click a commit and choose Edit message… to change the message of any commit on a branch, not just the last one. Squash into parent… folds a commit into the one before it. Neither one touches your files, so both work while you have uncommitted changes.

Interactive rebase from here… opens your branch's commits from that point up. Drag them into a new order and choose for each one whether to pick, reword, squash, fixup or drop it. Plexus asks before rewriting commits that are already on a remote, and conflicts are handled by the usual conflict banner.

Undo and redo

The Git tab has Undo and Redo buttons, also on Ctrl+Z and Ctrl+Shift+Z (Cmd on macOS) while you aren't typing. They work for commits, merges, rebases, resets, checkouts, cherry-picks, reverts, pulls, edited messages, creating, renaming or deleting branches, and creating or deleting tags. Hover a button to see which operation it would undo or redo.

Undo never rewinds anything it didn't do. If an agent committed or you ran git in a terminal since, it refuses rather than take that work with it. Fetching, pushing, staging and discarding changes can't be undone.

Stage single lines

Select the lines you want in an uncommitted file's diff, with a click, Shift-click for a range or Ctrl/Cmd-click to add one, then press Stage N lines. You can unstage, or discard, just those lines the same way.

Compare, history and blame

Ctrl/Cmd-click a second commit to compare the two, either directly or from where they split, with the commits each side has and the files that differ. Compare with current branch on a branch or tag menu does the same.

Right-click a file for File history, which lists every commit that changed it and follows it through renames, or Blame, which shows who last changed each line and when. Click a line's commit to find it in the graph.

Pull requests, submodules and LFS

With GitHub or Bitbucket connected, the Git tab lists the repository's open pull requests, with their checks and review state. You can check any of them out, including pull requests from forks. Authors are shown as initials, so the list loads no pictures from the provider.

Repositories with submodules get a section to see which are out of date and update them. Repositories that use Git LFS get one to download the files you are missing and to lock and unlock files.

A reused branch name no longer picks up an old pull request

A new session on a branch name you had used before — for a pull request merged and deleted long ago — could pick up that old pull request: the session showed as merged, was renamed to the old pull request's title, and stopped checking for a new one. Plexus now ignores a pull request that was closed or merged before the session was created, so a reused name starts clean, while an open pull request on the branch still counts. A session that is already showing an old pull request is checked again once after you update and cleared, and the Refresh PR status button in its header does the same at any time; the session keeps the name it was given.

v1.0.0 — Sign in to Plexus, and bring your team

2026-10-12T00:00:00Z

Plexus now has an account, and it is completely optional. Sign in and you can create organizations for the people you work with, invite them, manage all of it without leaving the app, and see every machine your account is signed in on. There is also, for the first time, something you can pay us for — an individual plan and a per-seat organization plan — and the seven things a plan unlocks: cross-device sync, which keeps your settings, your workspaces and your projects the same on every machine you sign in on; a prompt library that travels with you the same way; the workspaces an organization shares, set up once and handed to everybody who holds a seat; the settings an organization manages, recommended or enforced on every seat-holder's machine; the prompts an organization publishes, written once as a numbered revision and handed to every seat-holder's template list; your issue tracker inside Plexus — a project's GitHub issues and project boards, read, edited and worked from your own GitHub account, and turned into a session with one click; and stacked pull requests, kept restacked and retargeted as the stack moves and landed in order.

All of it is optional. Sign out, never sign in at all, or sign in and never buy anything, and Plexus works exactly as it did before: every session, every worktree, every git operation, every agent and every setting behaves the same way on your machine. All seven are new things rather than fences around old ones — nothing you already had moved behind the plan. Your code, your keys and your agents still never leave your computer, sync sends nothing at all until it has shown you the entire list first, and signing in or buying a plan changes nothing about the anonymous usage report or about Feedback. Neither one carries your account, and neither one has anywhere to put a plan.

Your Plexus account

A new My account page lives in Settings, at the foot of the sidebar with the rest of your account. It is a different thing from the GitHub and Bitbucket connections under Git ▸ Providers: those are accounts you hold at a repository host, this is an account you hold with us.

Signing in opens your browser, asks you to confirm the machine by name, and hands the app a sign-in that is kept in your operating system's keychain — never in a file, never in the app's database. Creating an account, changing your password or your email address, and setting up two-factor authentication all happen on the web, because each of them needs an email you have to go and read.

Organizations

An organization is how you group the people you work with. You can create, rename and delete organizations from Settings → Organizations without leaving Plexus, and the same list is on the web.

Pick an organization and you see everyone in it under Plan, seats and people — their role, whether they hold a seat, and any invitations still waiting to be answered.

Inviting people to an organization

Invite somebody by email address from Settings → Organizations or from the account panel on the web. You pick their role when you invite them, and you can pick any role your organization has — one of the five it starts with, or one you made yourself — rather than choosing between two fixed ones. Owner is the single exception: handing over ownership stays a separate, deliberate act on an existing member, done from the web panel. A seat is a separate question from a role, and anybody can be given one whatever role they hold. What each role can actually do is now yours to decide — see Roles you define yourself.

They get an email with a single-use link that expires after two weeks. Until they accept, they sit in the same list as everyone else, marked as invited, and they hold no seat. Accepting or declining happens in the browser, from that link — the person you invited very often has no Plexus account yet, so the link's whole job is to take them through creating one and bring them back to your invitation.

Resending an invitation issues a new link and kills the old one. There is no "copy invite link" button, and there cannot be one: the link only ever exists in the email we sent, never in a list, a response or a log.

Because a second person can now be an owner, deleting your Plexus account is no longer refused just because you own an organization. It is refused only while you are its only owner — promote somebody else first, or delete the organization.

Roles you define yourself

What somebody may do inside an organization is decided by the roles they hold, and you write those yourself, from the account panel on the web. Every organization starts with five:

Owner — everything, including buying a plan and deleting the organization.
Admin — everything except those two.
Maintainer — a member who also looks after what the organization shares with everybody in it.
Member — the ordinary role somebody arrives with.
Restricted — a member with something deliberately taken away, for contractors and anybody who should be in the organization without being free to act in it.

Those five ship with Plexus and cannot be edited, which is what lets them mean the same thing in your organization as in anybody else's. To get something else, copy one, name it, and tick or untick what it can do. The copy is an ordinary role of your own — rename it, change it again later, hand it out, delete it — and it takes effect the moment you save it. Nothing about it waits for a release from us.

Some of the boxes are greyed and marked as planned. The list deliberately names every act a role will ever be able to grant, including ones inside features we are still building, so that a role you think through today does not have to be reconsidered every time we ship something. A greyed box does nothing yet, and it stops being grey in the release that gives it something to do.

Somebody can hold more than one role, and what they end up able to do is everything their roles allow — except that taking a permission away always beats granting it. That is the rule that makes Restricted reliable rather than advisory: a contractor who holds Restricted and Member keeps whatever Restricted takes away taken away, instead of quietly getting it back through the other role. Copy Restricted and the copy keeps the takeaway too.

The last owner cannot be removed or demoted. An organization with nobody left who can pay for it or close it down is one only we could rescue, so both are refused while there is only one owner. Promote somebody else first.

All of this is free. Roles and permissions are not part of a plan and never will be: an organization with no plan at all, and no seats, writes and edits roles exactly like one paying for a hundred. Deciding what a contractor may do is not something that should stop working because an invoice bounced.

An admin no longer buys plans

One thing genuinely changes for organizations that already exist, and it is better read here than discovered on an invoice. Admin no longer covers billing or deleting the organization. An admin cannot buy a plan, change how many seats the organization pays for, read the invoices, or delete the organization — those stay with the owner who signed up for them. Everything else an admin did, they still do: inviting people and removing them, giving out and taking back seats, renaming the organization, and writing the roles.

If your admins are the people who pay your bills, the fix takes a minute and needs nothing from us: copy Admin, tick the billing permission back on, and give that role to the people who need it in place of Admin. It is Admin with billing added back, so nothing else changes hands in the swap.

Paid plans

Plexus now has something you can buy. There are two plans, both monthly, both priced in euro, and both renewing until you cancel:

an individual plan, held by your own account
an organization plan, sold per seat, held by an organization you own or administer

Buying opens your browser at our invoicing provider's checkout page, where the price and the VAT that applies to you are shown before you pay, and where you set up how you pay. Your card, bank account and direct-debit details are given to them on their page and never to us.

The Billing page on the account panel shows the plan on offer and its current price before you buy anything — the price is read from the invoicing provider's own product each time the page is drawn, so it is the figure the checkout will use, with VAT added there for your country. Press Subscribe (Buy seats on an organization) and a dialog asks you to tick a box — unticked, never ticked for you — saying you want the plan to start immediately and understand that you give up the 14-day right to withdraw by doing so; without the tick it goes no further. In the app the same box sits beside Buy a plan. The plan starts the moment the purchase completes and there is no trial, so that acknowledgement is the honest version of the transaction rather than a formality.

Coming back from the checkout, the app re-reads the plan it is showing on its own, and the seven things a plan unlocks follow within seconds: whenever a fresh answer about the plan disagrees with what the app last knew about them, it asks again straight away instead of waiting for its hourly check. There is also a button that asks our invoicing provider for the current state of the plan right now — Reload on the plan in the app, Refresh on the web panel's Billing page — for the minute after you have changed something on their side and come straight back.

A cancelled plan reads Cancelled with the day it ends, and nothing else is offered on it: a cancellation cannot be taken back, so there is no second Cancel plan and no Resume. When the period runs out, subscribing again starts a fresh plan.

What a plan unlocks, as of this release, is cross-device sync, saving a prompt to your library, the workspaces an organization shares with the people who hold a seat, and the settings it manages for them. Everything else in Plexus is the same on both sides of the purchase — see What a plan unlocks, and what it never will.

Seats

An organization plan pays for a number of seats, and a seat is something you hand to a member. The two are deliberately separate: an organization can have more members than seats, and nothing forces a member to hold one. Give and take back seats from Settings → Organizations with one click each, and the count on screen moves with the list — it is one answer from the server, never two things that can disagree.

Change how many seats you pay for from the app or the web panel. The invoicing provider works out the difference and raises the correction invoice, because there is exactly one place that decides what anything costs and it is not us. Setting an organization to zero seats is allowed — that is how a team gives its seats up without cancelling. Setting it below the number of seats people are actually holding is refused, and the refusal tells you how many are in use so you know what to take back first.

Taking somebody out of an organization frees their seat. And to be clear about what a seat now is: it is how a member gets whatever your organization's plan includes. In this release that is cross-device sync on their own machines, the workspaces your organization shares — the first thing a seat carries inside the organization rather than only between one person's own computers — and the settings it manages. A member without a seat keeps everything Plexus did before, in full; what they do not get is the organization's workspaces and its settings.

Invoices and payment details

Payment method & invoice PDFs on the Billing page (Manage billing in the app) opens the invoicing provider's own customer portal in your browser, where you change how you pay, read and download your invoices as PDFs, and cancel. The link is created at the moment you click it and is good for an hour — press the button again rather than keeping the tab.

Your invoices are also listed on the Billing page, with the number, date, state and total of each, and each issued invoice has a Download PDF button on its row, so the file is one click away without leaving the page. The billing details that get printed on them — a company name, an invoice address, a country picked from a list, a VAT number, an invoice email — are a two-column form at the top of that same page, saved with one button, and an organization keeps its own set, separate from your personal ones. The provider works out the VAT from those details, including reverse charge for a business in another EU country, so a VAT number is worth entering before you buy.

Plexus itself works out no amount at all: the price on the Billing page is read from the provider's product, and every number with a currency on it lives with the provider who issues the invoice, which is the only way to be sure there is one set of figures rather than two that can drift.

If a payment fails

Nothing is switched off. If a card expires or a direct debit is refused, your plan stays active and every seat stays exactly where it was, for the whole sequence of reminders. The app and the account panel show that a payment is late, and that is the entire consequence — an unpaid invoice is a payments problem, not a reason to take a team's tools away.

Sort it out under Payment method & invoice PDFs (Manage billing in the app) and the notice clears on its own. A plan only ends if you cancel it — in which case it runs to the end of the period you have already paid for — or if an invoice is eventually written off as uncollectible.

There is a new avatar at the right-hand end of the app bar. Signed in, it shows who you are and offers Account settings, a link to manage your account on the web, and Sign out. Signed out, it offers to sign you in or create an account. In compact mode it is the circle alone, like everything else up there.

Signed-in devices

Both the app and the web panel list every machine your account is signed in on, when each was added and when it was last used, with the one you are sitting at marked. You can sign any of them out, or all of them at once, and that machine is asked to sign in again the next time it contacts us. A sign-in also expires on its own after a year of not being used.

The list records the machine name you were shown before it was stored, its platform and its Plexus version. It deliberately holds no IP address and no browser identification string.

A calmer Settings

Settings has been rebuilt to be quieter. Every page is now a short list: a setting's name on the left and its current value on the right, with nothing else in the way. Select a row and a side panel opens on the right with one sentence on what the setting does, its choices, and Where this comes from. When there is more to say, More detail holds the full explanation. Switches can be flipped straight from the list, and on a narrow window the side panel slides over the list instead. The arrow keys move through the rows, Enter opens the side panel and Esc closes it.

The sidebar is down to eight pages: General, Appearance, Agent, Git, Worktrees & hooks, Shortcuts, Prompts and About. Your account sits at the foot of it, under your name: My account, Sync and Organizations. A few things moved on the way:

Advanced is gone. Its settings are on General, under Terminal, Performance, Claude CLI and Diagnostics.
Git providers is now Providers, the first part of the Git page.
Git & PRs is now Git, and it still holds the code review settings.
Keybindings is now Shortcuts.
Worktrees & Hooks is now Worktrees & hooks.

Every setting keeps its label and its default.

Workspace and project settings got simpler too. Open Settings… from a workspace's or a project's menu and an Applies to choice at the top switches between Everywhere, the workspace and the project. There are no more Override parent settings switches. Each setting overrides on its own: change a value and it applies at that level, and Use workspace value, Use global value or Use built-in default puts it back. A setting your organization enforces shows a lock, and its side panel says who set it.

One organization at a time

Organizations have a page of their own. Settings → Organizations has an organization picker at the top, with New organization in it; pick one, and everything below is about that one: Name (your role and how many people are in it, with Rename and Delete), Plan, seats and people, Shared workspaces, Managed settings and Published prompts, each opening in the side panel.

Until now that was spread over two pages. The account page held the list, with each organization's plan, seats and people under its row; the old Organization page held the three things an organization hands its members, each listing every organization you belong to one after the other — so with three organizations it was three lists of three, and "Acme's settings" was never on screen by itself. Now it is. Each row is about the organization you picked, a feature one organization's plan does not include is said so in that organization's row and nowhere else, and nothing about an organization is read until it is the one you are looking at — an account in eight organizations makes one billing request here, not eight.

My account keeps your sign-in, the web launchers, your own plan and your signed-in devices; your organizations are on their own page, right below it in the sidebar. Two shortcuts follow from the move: Manage organization on a shared workspace's ⋯ menu opens the page on the organization that shared it, and Manage seats on an over-capacity banner opens that organization's plan on the same page instead of leaving for another one.

Your settings follow you

Signed in on a plan, your settings, your workspaces and your projects can now be the same on every machine you use. Turn it on under Settings → Sync with Sync this machine, and set how closely Plexus watches with Check for changes every (minutes) — anything from 5 minutes to a day. Plexus checks when it starts, when you switch back to its window, a couple of seconds after you change a setting, and then on that schedule on its own for as long as it is running — it does not need the window in front of you, and it never needs a restart, so a change made on your other machine reaches this one without you touching anything. That number is the shortest gap between any two checks rather than the only moment one happens, whichever of the four prompted it, and it counts the time the machine was actually awake, so a laptop that spent the night closed does not fire off a burst of checks the second you open the lid.

What crosses is the settings you have changed from their defaults, the names, descriptions and order of your workspaces and projects, each project's base branch, and which repository each project stands for. Overrides follow the thing they were set on: the review instructions you wrote for one repository on the desktop are the review instructions you get for it on the laptop. There is one exception, and it is the only one — your own override on a workspace your organization shares stays on the machine you set it on; see Workspaces your organization shares.

Two machines that changed different settings both keep their changes. Each device sends only the keys it actually touched, so there is nothing to resolve, no prompt, and nothing lost. Change the same setting in two places and the one your account received last is the one you end up with everywhere — ordered by your account's own counter and never by a machine's clock, so a laptop that is ten minutes fast cannot quietly win every disagreement. A change you have made but not yet sent always beats what arrives, so a value you typed thirty seconds ago is never replaced by the one you replaced.

Both switches are per machine. Turning sync off on your laptop never turns it off on your desktop, and a machine with no internet connection keeps working exactly as it does today. A sync that fails never signs you out anywhere.

You see everything before it leaves

Nothing is sent until you have read it. The first time you turn sync on, Plexus opens a setup right on the Sync page, below the switch, listing everything that would leave this computer — every setting key and the value you gave it, every workspace and project name and description, every repository slug, and every clone URL — with a switch beside each workspace and project to keep it off your account entirely. Excluding a workspace excludes every project inside it, and nothing about an excluded project crosses: not its name, not its slug, not its existence.

The list opens with a one-line count of what is in it and is split into sections that show their count on the heading: workspaces and projects start open, while the settings and what stays on this machine start folded away, a click from being read. A folded section still holds every row it counts, so nothing about what is sent changes. Send this and turn on sync sits in a bar pinned to the bottom beside Cancel, so it stays in reach however long the list gets.

That list stays reachable afterwards from What this machine sends…, which opens it in place on the same page, so it is not a one-time door. Excluding something you had already synced takes it back off your account on the next check.

The setup also names what stays here, and why:

Fifteen settings describe this particular machine and can never cross — the path to your claude binary, your shell and shell path, your port window, your warm-session budget, your hook timeout, your reshape fetch preference, all three diagnostics settings, the two switches for sync itself, and the two that changed sides in this release (see Two settings that now stay on the machine you set them on). They are refused on the way out and again on the way in, so no other machine can write them here either.
A path that only means something here is held back and named. Older versions of Plexus accepted an absolute value in Where to create session folders, Files and folders to copy or Write ports to file; those are your username and your folder layout, so they stay put.
A single value too large for the wire is held back, listed by name in Settings, and everything else keeps syncing.

Three settings that do travel are flagged for a second look first, because their value has a consequence on the machine receiving it: Run scripts committed to the repository, Let the agent work without asking permission, and When you remove a session set to delete.

Clone URLs travel with any password removed, and on https with the username removed too. Your code, your keys, your sessions, your worktrees, your hooks, your transcripts, your pull-request records and every absolute path on your disk are never sent at all.

If your account already holds settings from another machine

You choose what happens, once, from three cards in the setup. With Merge picked, it also shows you which settings the two sides disagree about before you confirm:

Merge — the default. Keys only this machine has are added to your account, and each disagreement is settled one setting at a time, with this machine's value already picked because you are sitting at it.
Keep this machine's — your account is replaced with what is here.
Take the account's — this machine takes what the account holds. Before anything is overwritten, this machine's state is written to the version history, so the decision can be undone.

Version history, and putting a version back

Your account keeps the last twenty versions of your settings and of your workspaces and projects. Settings → Sync → History lists them, newest first, each with when it was written, which of your machines wrote it, how it came to exist — saved, replaced or restored — and how many items it held. Any of them but the current one can be put back.

A restore is written forward, as a new version, rather than rewinding the counter. Nothing already in the history is lost by one, every other machine picks it up through its next ordinary check with no special handling, and a restore is itself undoable by restoring the version before it.

The machine's name is recorded at the moment it wrote the version, so the history still reads correctly after you sign that device out — and signing a device out never deletes anything it synced.

Stop syncing and forget what we hold erases everything sync has stored on your account: the current values, every retained version, and every workspace and project name. This machine is untouched and Plexus keeps working exactly as it does now. Deleting your Plexus account takes all of it with it too.

Projects that are not on this machine

With sync on, a project you added on another computer appears in this one's sidebar, under the workspace it belongs to, marked Not on this machine alongside the repository it stands for. It is an ordinary row rather than a warning — a repository you have on your laptop simply is not checked out here yet.

Most of the time you will never see one, because Plexus links the two sides itself. It compares the host/owner/name of every remote each checkout has configured, so a fork links through its upstream and an SSH clone links to an HTTPS one; case, a trailing .git, a port, a login name in the URL and any url.<base>.insteadOf shortcut you have configured are all normalised away first. Self-hosted GitLab, Gitea and GitHub Enterprise repositories are matched exactly like github.com ones, and no repository URL is ever looked up or contacted — a slug is only ever compared against your own checkouts.

Where it cannot be sure, it asks rather than guesses. Each row offers:

Locate… — point at the folder if the repository is already here. If that folder's remotes do not match the synced ones, Plexus says so and links it anyway, because that is what a fork looks like. Pointing it at a session's worktree is refused with a sentence saying why: that folder is deleted when the session is torn down, and it would take the project's settings with it.
Clone… — hand the synced clone URL to the usual Add repository dialog, choose where it goes, and the new checkout arrives already linked, with its settings and its place in the tree.
Choose a matching repository… — when more than one repository here shares a remote with the synced project, Plexus lists each folder with the remotes it matched on, and you pick.
Stop showing … here — removes the row on this computer only. It does not delete the project for any other device.

A project whose folder has been moved, unmounted or deleted is now marked on its row rather than removed, with the path it is looking for. Nothing is deleted for it — its settings and its sessions are all kept, and the row goes back to normal the moment the folder does.

Deleting a workspace or a project on one machine is never an instruction to destroy work on another. If the other machine has a session or a worktree under it, the row stays exactly where it is and simply stops following your account.

Two settings that now stay on the machine you set them on

Two settings that used to be ordinary preferences are now classified as belonging to this device rather than to you, which means they will never travel between your machines even with sync on:

Show commit author avatars from Gravatar, under Git. It is a privacy switch, and a privacy switch that follows you is one you can turn off on your laptop while your desktop carries on asking a third party who wrote each commit.
Clean up a session when its pull request is merged, under Git. Turning it on is the consent for an unattended, unconfirmed worktree removal, and that consent should not arrive on a machine nobody is sitting at, weeks after you gave it somewhere else.

Nothing changes on the machine you set them on: same label, same default, same place, and whatever you have chosen is kept exactly as it is. What changes is that from now on you set each of them per machine. Being wrong in this direction costs one re-typed toggle; being wrong in the other costs a worktree somebody was using.

The prompt library

Some prompts you write once and then rewrite from memory forever — the review one, the "work out why this test is failing" one, the release-notes one. Plexus now has somewhere for them to live. Save a prompt under a name, turn the parts that change into fields, and run it again from the New Session dialog or straight into a session that is already going.

The fields are typed, which is the difference between this and a text file you keep open in another window. A choose one field is a list you write yourself, so nobody has to remember whether it is "perf" or "performance". A checkbox switches a whole paragraph of the prompt on and off rather than blanking a word. A field can be needed, so the prompt cannot run half-filled. And two kinds only Plexus can offer, because it is the thing holding your worktree and your git state: a file field suggests paths from the project you are actually in, and a branch field suggests that project's branches, local and remote.

Write {{name}} in the prompt where a value goes, and {{?flag}} … {{/flag}} around a part a checkbox turns on and off. Doubled braces rather than $name for one reason that matters here: prompts in this app are full of shell, and $VAR collides with it.

Where they live, and what that means

A template is filed under just you, a workspace or a project, and the list shows all of them together with a badge saying which — there is no override chain, so two templates with the same name are two templates. Templates you save are kept in your Plexus account, so they follow you to every machine you sign in on. That part needs a plan; see below.

A project can also commit its own. Drop a markdown file into .plexus/templates/ in a repository and everybody who clones it gets that prompt in their list, badged Repository. Those work with no account and no plan at all, and they are the one kind that never leaves your computer — there is no field on the wire that could carry one. If you would rather not see a repository's prompts, Use prompt templates committed to the repository turns them off, globally or for one project.

Running one

In the New session dialog a Template field appears above the branch fields once you have saved something. Pick one, fill it in, and the rendered prompt is waiting in the terminal when the agent comes up — including when you have auto-start off, in which case it waits until you press Start. In a session already running, Insert prompt in the footer of the Agent tab does the same thing.

Either way the text is typed into the terminal and left there. Plexus never presses return for you: you read what it wrote and send it yourself.

Starting from a session that already worked

The prompt worth keeping is usually one that already did the job. Save as template… in a session's ⋯ menu lifts that session's opening prompt into a new template, ready to edit — and it works on a session that is stopped or archived, which is when you actually know it was worth keeping.

Before anything leaves your machine

Nothing is sent until you say so. Show me what this machine would send… lists every prompt that would go, in full, alongside everything staying here and why — and only then does the first one leave. Afterwards the Prompts page tells you when it last checked, which machine wrote last, and how many prompts are still waiting to go, so "you have nothing saved" and "we could not reach the account" never look the same.

Delete every template we hold erases the lot from your account, and it never stops working — not on a lapsed plan, not on a cancelled one. It leaves the copies on your computer exactly where they are.

What a plan does and does not gate here

Saving a prompt to your account needs a plan. Reading, running, copying, exporting and deleting the ones you already have do not, and never will: your templates live on your disk as well as in your account, so a plan that ends takes away the ability to write new ones and nothing else. Every template you had keeps listing, keeps running, and can still be deleted or exported. Repository templates are unaffected either way.

Workspaces your organization shares

An organization can now set a workspace up once and hand it to the people in it. It has a name, a description, a rule about who may join, and a list of the repositories that belong in it — and everybody who is in it gets the same one. You will find them on Settings → Organizations, under Shared workspaces for the organization you pick.

On your own machine it is an ordinary workspace. It sits in the sidebar with the rest, carries your organization's name, and you open Settings on it and configure it exactly like any other. What the organization owns is its name, its description and the repositories attached to it. Your sessions, your checkouts and your own settings for it are yours.

The repositories arrive already attached. Each one appears under the workspace the moment you join, marked Not on this machine beside the repository it stands for, and a Clone button beside it hands its address to the usual Add repository dialog — you choose where it goes, and the new checkout arrives already in the right place. Nothing is downloaded onto your computer until you ask for it, so joining a workspace with nine repositories in it costs you nothing on disk. If a repository was attached without an address, the button says so and tells you to ask an administrator for one, rather than failing when you press it.

This needs a seat. An organization's workspaces reach the members who hold a seat on its plan, and nobody else. An organization is allowed to have more members than seats — that is deliberate, not an accounting mistake — and a member without a seat keeps everything Plexus did before, in full; what they do not get is the organization's workspaces.

It does not need cross-device sync switched on. Sync this machine, under Settings → Sync, is your consent for this computer's own settings and layout to leave, and it is off until you turn it on. Your organization's workspaces are a list arriving, so a brand-new laptop that has never had sync turned on receives them as soon as you sign in and hold a seat.

And one thing about a shared workspace does not follow you between your own machines. Your own settings override on a workspace your organization shares stays on the machine you set it on. The organization's side of it is the same everywhere; your personal change to it is per machine, unlike the overrides on your own workspaces, which do travel. If you want the same override on your laptop, set it there too.

Joining and leaving

There are three ways a shared workspace reaches you, and the workspace itself says which:

Open — anyone in the organization can join it, with one click.
Request — you ask, and an administrator answers. Until they do, the row says it is waiting, and you can cancel an ask you have not had answered.
Invite only — an administrator adds you, and it appears.

If you asked and were not added, the row says so and gives you the date you can ask again. It is a pause and not a verdict: an administrator can still add you at any time before then, and nothing about it follows you anywhere else.

Leaving always works. It sits beside the workspace's row in Settings, and on the workspace's ⋯ menu in the sidebar — where it stays whatever happens to a plan or a seat. It is never behind either one, and it keeps working for an organization whose plan has lapsed. Being able to stop receiving something is not the kind of thing a subscription gets to take away.

And leaving deletes nothing. The workspace stays in your sidebar, its repositories stay on disk, and their sessions, worktrees and branches are left exactly as they are. It simply stops being your organization's: the name stops being updated, new repositories stop arriving, and what you are left with is an ordinary workspace of your own.

The confirmation tells you what getting back in would take before you press it, because the three modes do not agree — an open workspace you can rejoin whenever you like, a request one you would have to ask for again, and an invite-only one you cannot rejoin at all until an administrator adds you back.

Where a workspace came from

A workspace can appear in your sidebar without you having done anything, because that is what an organization sharing one means. So every shared workspace's ⋯ menu has Why do I have this?, and it answers in one sentence: you were added automatically because your organization gives this workspace to every new member, you joined it yourself, a named person added you, you asked and a named person approved it, or somebody added everyone at once.

That name is recorded at the moment you were added, so the answer still reads correctly after the person who added you leaves the organization or deletes their account. It is two facts and no more — there is no history behind it and there will not be one.

The same dialog says who can join the workspace, and spells out the split that explains the menu: the name, the description and the repositories are your organization's, and your own settings, sessions and checkouts are yours. That is why a shared workspace cannot be renamed, deleted or set as your default from your machine — those all belong to the organization — while Settings… stays exactly where it was.

Auto-add applies to new members only

A shared workspace has an Add everyone automatically switch. Turn it on and everybody who joins the organization from then on receives the workspace without having to ask for it.

Turning it off later removes nobody. The switch is read once, when a new person joins the organization, and it is never a member list reconciled against the workspace. There is no way to express "un-share this from the people who already have it" as a side effect of a toggle — somebody stops being in a workspace only by leaving it or by an administrator taking them out, both of which are deliberate acts on a named person.

That is a decision rather than an oversight. People run agent sessions inside these workspaces, and a switch that quietly pulled a workspace out from under a running session would be a far worse surprise than a switch that means exactly what it says.

To give the workspace to the people who are already in the organization, add them — one at a time from the app, or with Add everyone on the account panel on the web, which tells you how many people it is about to add before it does it.

Managing shared workspaces from the app

None of the administration needs the web. Settings → Organizations shows one organization at a time; open its Shared workspaces row, press Manage, and you get its workspaces with everything an administrator does:

New workspace — a name, a description, who may join, and the auto-add switch.
Edit — all of the same, afterwards.
Repositories — attach one by name and its host/owner/name slug, with an optional clone URL and base branch, or remove one again.
People — who is in the workspace, who is waiting to join, and the buttons to add somebody, answer a request, or take somebody out.
Withdraw — stop the organization handing the workspace out. Nobody's checkouts, sessions, worktrees or branches are touched. On every machine that already has it the workspace stays exactly where it is, with its repositories and everything anybody has done in them, and simply stops being your organization's: the name comes off it, and nothing further arrives.

What you can do is decided by your role in the organization, not by which build you happen to be running: the app asks the server what you may do and offers exactly that. Out of the box owners and administrators can do all of it, and everybody else can join, ask and leave — and the five workspace permissions are ordinary tickable boxes in the role editor, so you can copy a role and hand any part of it to whoever should have it.

One rule about clone URLs is worth knowing before you type one. https://, ssh:// and git@host:owner/name are accepted; plain http:// is not. This is an address handed to every member's machine, and an http:// clone would send a colleague's git credentials across their network in the clear.

When more seats are handed out than are paid for

An organization can end up with more people holding a seat than the plan pays for — a seat count lowered, a plan changed, an invoice that has not caught up. Nothing is switched off and nobody loses a workspace. Everyone keeps every workspace they have, keeps receiving its repositories, and keeps joining, asking and leaving.

What pauses is the short list of acts that add or change: creating a workspace, editing one, attaching a repository, adding somebody to one, and approving a request. Each is refused with a sentence naming two numbers — what the organization pays for, and how many people hold a seat — and a banner at the top of the page says the same with Manage seats beside it. No member is named, and no seat is taken off anybody to make the sums work.

Everything that takes something away keeps working, deliberately: withdrawing a workspace, detaching a repository, removing somebody, saying no to a request, and any member leaving on their own. The remedy for the refusal is to raise the seat count or take a seat back, and an organization that could not take a seat back could not do the thing it is being told to do.

Changes arrive while the app is open

Until now a running Plexus learned what your account and your organization had to say when it started, and not afterwards. A seat granted this morning was invisible until you quit and reopened; a workspace your organization added while you were working turned up at the next launch.

It now checks on its own while it is running. One setting governs both halves — Check for changes every (minutes), under Settings → Sync — and a check also happens when Plexus starts, when you switch back to its window, and a couple of seconds after you change a setting. The number is shared; the switch above it is not. Your organization's half runs whether or not Sync this machine is on, because it is a list arriving rather than anything of yours leaving. So a workspace added, renamed or withdrawn, a repository attached or detached, being added to a workspace or taken out of one, and a seat handed to you or taken back all reach a running app with no restart.

Two things worth knowing about the number. It is the shortest gap between any two checks rather than the only moment one happens, whichever of the four prompted it. And it counts the time your machine was actually awake, so a laptop that spent the night closed does not fire off a burst of checks the second you open the lid.

Sync now under Settings → Sync still forces one immediately, and Refresh, on the workspace list behind Manage, does the same for an organization's catalogue.

Settings your organization manages

An organization can now set some of Plexus's settings for the people in it. An administrator picks a setting, gives it a value, and chooses how strongly to mean it:

Recommended — set once on each member's machine, as if they had typed it themselves. After that it is theirs: change it and the organization never puts it back. A changed recommendation updates a value you have not touched and leaves one you have, and withdrawing it takes back only a value nobody had touched.
Enforced — applies on every member's machine and wins over everything: your own global value, and any override you set on a workspace, a project or a session. The row locks.
Evaluate — a dry run. Nothing on anybody's machine changes. The administrator sees how many devices would change if the setting were enforced, and that is all they see.

What a locked row looks like. The control is greyed and cannot be changed, there is no reset button, a lock sits beside the label, and the row says Managed by your organization. Hover over it and it shows the organization's value beside the one you had set yourself. Your own value is not deleted — it is kept, and it comes back the day the organization relaxes the rule. Writing a locked setting from anywhere in the app is refused with a sentence naming the organization, never silently ignored.

It keeps its last known value when you are offline or a plan lapses, and unlocks only when you leave the organization. A locked setting stays locked on a plane, on a laptop that has not spoken to us in a month, on a plan whose invoice bounced, and on a seat that was taken back. A value an organization set is a decision about a shared way of working, and it must not evaporate on the day the network does. It comes off only when the organization withdraws it, or when you are no longer in the organization at all — at which point every setting it managed unlocks and your own values return. Nothing you set yourself is ever deleted from your machine.

The dry run sends one yes-or-no per setting per device, and nothing else. While a setting is being evaluated, each of your machines reports whether its current value differs from the proposed one — a single yes or no per setting, no value, no name. The administrator sees "Would change on 3 of 12 devices", and a count under five devices is folded into "Fewer than 5 devices reporting" rather than shown, unless it is everyone or nobody, so a report can never single out one person's setting.

What can be managed. The same sixty-seven settings that cross-device sync carries — the ones that mean the same thing on every machine. A setting that describes your particular computer — the path to your claude binary, your shell, your port window, the switches for sync itself — cannot be set by an organization any more than it can follow you between your own machines. A value this version of Plexus does not know is listed as such and applied to nothing.

Where to find it. The Managed settings row of Settings → Organizations lists everything the organization you picked currently sets on this machine, with the level of each and when it last checked; Refresh asks for the latest. Administrators manage them there too: press Manage in its side panel for the editor — publish a setting, pick its level, enforce or unenforce it, withdraw it, and read the dry-run counts — and the same page exists as Shared settings on the account panel on the web. What you can do in it is decided by your role: viewing, editing and enforcing are three separate permissions, and all three are ordinary boxes in the role editor. When more seats are handed out than are paid for, publishing and enforcing pause the way creating a workspace does, and withdrawing and unenforcing keep working.

This needs a seat, not sync. Like shared workspaces, managed settings reach the members who hold a seat on the organization's plan, and they arrive whether or not Sync this machine is on — that switch is about your own settings leaving this computer, and these are values arriving. Withdrawing a setting and unlocking one never need a plan, so an organization whose plan has lapsed can always take a lock off. A member whose seat has gone keeps the lock and is told why on that page.

Prompts your organization publishes

An organization can now keep prompt templates of its own and hand them to the people in it. Somebody proposes a template — a name, a description, the prompt with its {{fields}}, exactly as in your own library — and somebody publishes it, and from then on every member holding a seat finds it in their template list, in the New Session picker and under Insert prompt, badged Org · Acme. Fix the prompt on the organization's side and everybody has the fix on their next check; nobody copies anything around, and nothing about Plexus itself has to be updated.

A template is a list of revisions and one pointer. Every proposal is a new, numbered revision, and a revision is never edited once it exists. Publishing moves the organization's current pointer onto the draft; rolling back moves it onto any earlier revision, in one action, and that reaches every member the same way a publish does. Members only ever receive the current revision — a draft is invisible to anybody outside the people who manage the library — and nothing changes a template out from under a session that already rendered it. Discard draft drops a proposal that never went out, and Delete retires the template: it disappears from every member's list on their next check, and its revisions go with it.

Your own templates are untouched, including one with the same name. An organization's prompts sit beside yours in one list; they never replace, override or hide a template of your own. If you and your organization both have one called "Review", you see both, and the badge is how you tell them apart — so both pickers now show a badge on every row, not only the organization's. You can copy an organization's template into your own library and change the copy; you cannot edit or delete the original from your own machine, because it is the organization's.

What an organization prompt may not contain. Its text is typed into Claude Code's input on your machine, where a line starting with ! runs a shell command, a line starting with / runs a slash command, and @path attaches a file. An organization prompt is refused at the moment it is proposed if it starts with ! or /, or mentions a file as @path — an email address such as dana@example.com is fine — and the same check runs again on every publish and every roll back. Plexus also strips those from an organization prompt as it types it, on your machine, so nothing an administrator publishes can run a command or attach a file on your computer. Your own templates, and the ones a repository commits, keep all three: you chose that content. And as with every template, the text is typed into the terminal and left there — Plexus never presses return for you.

Where to find it. The Published prompts row of Settings → Organizations lists what the organization you picked has published to this machine, with each template's revision number and when the list was last checked; Refresh asks for the latest. Administrators manage the library there too: press Manage in its side panel to Propose a new template, Publish draft, open a template's Revisions, Roll back…, Discard draft or Delete — and Propose to organization… on one of your own templates on the Prompts page starts a proposal from it. The same library is a Prompt library page on the organization's account panel on the web. Five boxes in the role editor decide who does what — Use prompts, Propose prompts, Publish prompts, Manage revisions and Delete prompts — and they are live now rather than planned: Member and Restricted use and propose, Maintainer also publishes and rolls back, Admin and Owner do all five. A control your role does not grant is absent rather than greyed, and the organization's own service refuses the act itself if a stale screen lets a click through.

This needs a seat, not sync. Receiving an organization's prompts needs its plan to include them and you to hold one of its seats, and they arrive whether or not Sync this machine is on — they are text arriving, not anything of yours leaving. Proposing, publishing and rolling back need the plan too, and pause when more seats are handed out than are paid for, the way creating a workspace does. Three things never need any of it: the prompts already on your machine keep listing and running — offline, on a lapsed plan, and after a seat is taken back; discarding a draft and deleting a template keep working after a plan has ended, so a lapsed organization can always take back what it published; and your own library is yours whatever the organization does. An organization's prompts leave your machine in one case only — you leave the organization, or its answer says your role may no longer use them — and never because a check failed.

Your issue tracker, inside Plexus

A project's GitHub issues can now be worked inside Plexus — read, opened, edited, commented on and created — and a GitHub project's boards can be worked the same way, cards and all. Everything goes from your machine to GitHub with the account you connected under Git ▸ Providers, and a session started from an issue is tied to it from the moment it exists: the branch carries the issue number because Plexus named it, not because anything guessed at it afterwards.

The Toolchain

Every workspace and every project now has a Toolchain: a catalogue of the tools it can be connected to, one card per tool with an Available or Installed badge and a Configure button. Two tools ship — GitHub issues, one repository at a time, and GitHub Projects, one project at a time — and each becomes a tab on the tab strip. Open the catalogue with the Settings button at the right end of a project's or a workspace's tab strip.

You no longer type a repository: Configure opens a dialog with a search over the repositories your GitHub account can see (a project's own repository is suggested first), and the same search over projects for GitHub Projects. Detach removes an instance and nothing else — no session, no link, nothing on GitHub.

A workspace of ten services that share one tracker attaches it once. Each tool a workspace attaches has its own Share with projects switch, and each project has Inherit the workspace's tools; both are on by default, and a project sees a workspace tool when it inherits and that tool is shared. Nothing here needs a plan or a connection: the catalogue works before GitHub is connected and tells you the tabs will be empty until it is. The toolchain stays on the machine you set it up on — it is not part of what cross-device sync carries, and an organization's shared workspace does not carry one either.

The workspace view

Clicking a workspace's row opens a workspace view, shaped like the project view: a Dashboard tab showing the global dashboard pinned to that workspace, one tab per tool attached to the workspace, and the same Settings button at the right end. The workspace's ⋯ menu gains Open. The chevron keeps doing only what it did — collapsing and expanding.

The Issues tab, like GitHub's

The tab lists the repository's issues the way github.com does — the state glyph, the title, the labels, #123 opened 3 days ago by author, the comment count, who is assigned — with Open and Closed, a search box, Assigned to me / Mentioning me / All, and pickers for labels, assignee, milestone and sort. Pull requests are left out. The list refreshes itself every minute while Plexus is the focused window, every five minutes while it is merely visible, and not at all while it is hidden; Refresh asks now, and two projects inheriting one tool share one request.

Click a title and the issue opens inside the tab: the text rendered as GitHub renders it (images and other remote media are left out on purpose — Plexus never loads anything from the web into the app on your behalf), the labels, assignees and milestone in a side column, and the comments. Everything you can change on github.com you can change here — the title, the text with a write/preview editor, close or reopen, labels, assignees, the milestone, a new comment — and it is saved to GitHub the moment you do, undone with a message if GitHub refused. New issue creates one from inside the tab.

GitHub's answers are shown as they are. If it is rate-limiting you, the tab says so with a countdown and keeps the last list it had. If it rejects the token — or nothing is connected — the tab says so and offers Reconnect GitHub.

Boards from GitHub Projects

Attach a GitHub project and a Board tab lists every one of its views. A board view renders as columns with the project's cards; drag a card to another column and its status changes on GitHub, drag it within a column and its position does. A table view renders the columns GitHub shows; a roadmap renders as a table. Click a card to open the issue behind it — the same view the Issues tab opens, with the same editing — and every issue card has Start session.

A view's filter is applied by Plexus itself, and where it uses something Plexus does not understand the tab says Filter partly applied and names the parts it skipped, so a board never quietly shows fewer cards than GitHub does. Projects sit behind a GitHub permission a repository connection does not carry: the first time you attach one on a connection made before this release, Plexus asks you to Reconnect GitHub, and reconnecting is enough. Nobody without a project attached is asked.

Start a session from an issue, and keep it beside you

Every issue row, the opened issue and every issue card have Start session. It opens the New session dialog with the name already filled in as #123 The issue's title, a Linked to #123 chip under it, and a checkbox — on by default — Send the issue to the agent as the first prompt, which types the issue's title, its link and its full text into the agent when it comes up, together with a request to reference #123 in its commits, after any template you also chose. The branch comes out as plexus/123-the-issues-title, because that is what Plexus already does with a session called #123 ….

The session then carries the issue with it. An Issue button at the right end of the session's tab strip — and the #123 chip in the context bar — opens a sidebar on the right with the issue exactly as the Issues tab shows it, editable, resizable, remembered per session. The issue's row lists the session under Sessions, and Create PR starts its description with Closes #123, so merging the pull request closes the issue on GitHub. The link is written when the session is created and lives as long as the session does.

What a plan gates here, and what it does not

The tabs and the sidebar need a plan — an individual plan, or a seat on an organization's. Listing, opening, editing, commenting, creating and working a board all go from your machine to GitHub with your own token, and every one of them is behind the same gate. It is the sixth thing a plan unlocks, and the first that is not a service we run: we are not told any of it happened. Without a plan the Issues tab, the Board tab and the sidebar show a locked pane in place of their content, and nothing else in the app changes — there is no lock on any tab, or anywhere else.

Everything around them is free. The Toolchain catalogue, attaching and detaching tools, the switches, the repository and project pickers, the link a session carries, the #123 chip, the Sessions list on a row and the Closes #123 line are yours whether or not you hold a plan, and a plan that lapses hides the next list and nothing you already made.

Stacked pull requests, and a land queue

Split a big change into a stack: start a session on top of another one — New session on top… in a session's ⋯ menu — and it nests under its parent in the sidebar, cuts its branch from the parent's, and opens its pull request against it, so every pull request shows only its own changes.

Plexus then keeps the whole stack consistent while the agents work. When the session underneath moves ahead, every session above it is restacked onto it as soon as its agent is idle, and pushed again if it was already pushed — with a lease, so a push someone else made is never overwritten. A restack that conflicts is never left half-done: Plexus puts the branch back and hands the conflict to that session's agent. When the bottom pull request merges, the ones above it are retargeted and moved onto your main branch — and because Plexus remembers where each branch forked, that works after a squash merge too. Each pull request in a stack also lists the others at the end of its description.

Land stack… merges a whole stack from the bottom up, through GitHub or Bitbucket: it waits for each pull request's checks, retargets and restacks the next one, and moves on, stopping with a reason the moment something needs you. Add to land queue does the same for independent pull requests, and the Land queue panel on the project dashboard shows where everything stands. On a GitHub branch that requires GitHub's own merge queue, Plexus adds the pull request to that queue instead of merging it.

Stacks and landing need a plan. One part of this is free for everyone: a branch another session is based on is no longer deleted when its own session is removed — including by the cleanup that runs after a pull request merges.

What a plan unlocks, and what it never will

Until this release we could say that nothing in Plexus at all was held back. This one introduces the first seven things a plan unlocks, so here is the exact shape of them.

Seven things need a Plexus account and a plan — an individual plan, or a seat on an organization's. Cross-device sync, saving a prompt template to your account, receiving the workspaces an organization shares, receiving the settings an organization manages, receiving the prompts an organization publishes, your issue tracker inside Plexus, and stacked pull requests with a land queue. All seven are new: none of them has ever worked without a plan, in any version, for anybody, and nothing else in this release needs one.

Nothing that already worked moved behind the plan, and nothing ever will. Sessions, worktrees, the agent terminal, the review tab, the explorer, the git client, pull requests, hooks, the dashboard, the tree and every setting behave identically whether you are signed out, signed in, paying or not, holding a seat or not. There is no cap on sessions, projects or worktrees, now or ever, and no limit on the free part that a plan exists to remove. Everything a plan unlocks will be something that did not exist before it.

And we will say so here, every time. A feature that becomes conditional on a plan or a seat arrives as a section in these release notes and as an announced change to the Terms — never quietly, and never discovered. This is that section for all seven of them, and it is where the next one will be too.

If a plan ends, you stop writing to those seven and nothing else changes. Every machine keeps every setting, workspace and project it already has — the copy on your disk is the real one — and they simply stop exchanging changes with us. What your account holds is kept rather than deleted, so resuming picks up where you left off. Your prompt templates behave the same way and go one step further: every one of them keeps listing, running, copying and exporting, because the copy on your disk is complete. A workspace your organization shares behaves the same way again: it stays in your sidebar with its repositories, its sessions and its worktrees exactly as they are, and what stops is receiving the organization's changes to it and joining new ones. A setting your organization manages goes the same way, and deliberately further in one respect: an enforced value keeps its last known value and stays locked, because a lock that came off on the day an invoice bounced would be a rule that meant nothing — it unlocks when the organization withdraws it or when you leave. A prompt your organization published goes the way of its workspaces: every one already on your machine keeps listing and running, badge and all, and what stops is receiving the next revision. An Issues or Board tab shows its locked pane instead of the next list, and every tool you attached, every session you started from an issue, its #123 chip and its Closes #123 line stay exactly as they are. Sessions you stacked stay nested under their parents and can still be unstacked; what stops is the restacking, retargeting and landing. And Stop syncing and forget what we hold, Delete every template we hold and leaving a shared workspace never stop working — nor does withdrawing a workspace, detaching a repository, taking somebody out of one, withdrawing or unlocking a managed setting, or deleting an organization prompt or discarding its draft, which is what stops a lapsed plan from trapping a departed colleague's access, a colleague's settings, or a prompt an organization no longer stands behind. Deleting is not part of what a plan buys, so you can erase what we hold, and stop receiving what we send, long after you have stopped paying us. Cancelling cannot trap any of them.

If you never want an account, nothing in this release asks you to have one. If you never want a plan, nothing you already use asks you to buy one.

The service that completes a GitHub or Bitbucket sign-in accepted a callback address it should have rejected, which meant a crafted link could have sent the resulting token somewhere other than your own machine. Signing in now validates that address properly and always requires the proof-of-origin check that binds the sign-in to the copy of Plexus that started it. Nothing about how you connect a provider changes, and existing connections are unaffected.

Project path settings now catch a bad path when you type it

Three settings under Worktrees & hooks name a file or folder inside your project — Where to create session folders, Files and folders to copy, and Write ports to file. Until now Plexus accepted anything you typed and quietly worked around a bad value later: an absolute path or a .. was silently dropped when the session was created, so the folder simply appeared somewhere you did not ask for, long after you had stopped looking at the settings screen.

These fields now tell you at the moment you save. A path has to stay inside the project, and folders have to be separated with a forward slash — config/local.env, not config\local.env — so the same setting means the same thing on Windows, macOS and Linux. Values you already saved are left exactly as they are and keep working; only a new edit is checked.

A profile picture, and initials that sit in the middle

The circle that stands for your Plexus account — in the app bar and on Settings → My account — can now show a picture of your choosing. Press Add a picture on the account page, pick any image, and Plexus crops it to a 128 × 128 square on your own machine before storing it with your account, so the same picture greets you on every machine you sign in on. Change picture and Remove picture are on the same page. An account without a picture keeps its coloured circle with your initials, which are now centred properly: they used to sit a couple of pixels too high.

Every dropdown in the app now opens with a search box at the top, so the branch you want is a few keystrokes away even in a repository with hundreds of them. They still look and work like the dropdowns you know: click one and pick, or start typing straight away — a letter typed on a closed dropdown opens it and starts the search — then use the arrow keys and Enter. That covers the Project, Template and Base branch fields of the New session dialog, a template's branch fields, and every choice on the Settings pages.

Fields you can drag into a prompt

Writing a saved prompt no longer means typing {{name}} by hand. In the prompt box, each field is now a small chip. Type { and a list of your fields opens at the cursor. You can also click one of the field chips listed under the prompt, or drag it to where it belongs. If the name you type is not a field yet, the list offers New field "…", which puts the chip in and adds the field for you. A checkbox goes in as a pair of chips, if … and end …, around the part it switches on and off, and it wraps whatever text you have selected. A chip turns amber when something is wrong with it, such as a name that is not set up as a field, and hovering over it says what.

Edit as text still shows the prompt as plain {{…}} text, and anything you type or paste in that form turns back into chips. What is saved has not changed, so every template you already have opens as chips as it is.

The same goes for an organization's prompts on the web. On the Prompt library page of your account, the prompt box shows its fields as chips. Type {{ or open the Merge tags panel beside it to put one in.

A tidier prompt library

Settings → Prompts now works like a library. Your templates are in a list, and the one you pick opens in the side panel on the right, where you can read it, see its fields and their defaults, and copy it. The editor no longer sits on the page all the time. It appears when you press New template or Edit, with Save and Cancel at the top, and the fields and the preview are side by side as two tabs instead of one long page.

In the New session dialog, a template you picked can now be taken off again. Use the ✕ next to the Template field or No template at the top of its list, without closing the dialog.

Pasting a screenshot works on Windows again

On Windows, pasting an image into a session — a Snipping Tool capture, say — did nothing. Claude Code on Windows listens for a different key to paste an image than it does on macOS and Linux, and Plexus was sending the wrong one. Press Ctrl+V in the Agent tab with an image on the clipboard and it lands in the prompt as an attachment, the same as on every other platform.

The project Git tab puts the graph first

The project's Git tab has been rebuilt around the commit graph, which now takes the whole width of the tab instead of sharing it with two side panels.

Your branches, remotes, worktrees, stashes and tags moved to a slim rail on the left that shows how many of each there are. Click one to slide the References panel out at that section, or pin it to keep it beside the graph. A dot on Worktrees tells you when an agent in one of your sessions is working (green) or needs you (amber).

Clicking a commit slides its details in from the right, over the graph. Click another commit and the details change in place. Click a file and its diff opens on top, with the commit's file list still showing at its edge, so one click takes you back. Escape closes one layer at a time, and the graph underneath never moves, so you never lose your place in the history. Use the arrow keys (or j and k) to move through the graph and Enter to open the selected commit.

The graph itself is easier to follow. Lines run straight and turn once, with a rounded corner, where they meet another line. Every branch has a clear color of its own, and its label is tinted to match, so you can tell which line a name belongs to. Each commit shows its author's picture in a ring of its branch's color. Your uncommitted work is a dotted circle on the branch you are about to commit to.

You can also see your agents in the graph. A branch a session is working on shows what that session is doing, such as Working or Needs you, next to its label, with a ring of the same color on its newest commit. Commits that arrive while you are watching slide in at the top and stay highlighted until you look at them. If you have scrolled away, a button tells you how many new commits there are and takes you back to them. A thin strip along the right edge marks the checked-out commit, your sessions, new commits and your selection, so you can jump to any of them with one click.

A redesigned account panel on the web

The account panel in your browser has a new look, in light and dark, and it follows your system unless you pick one. The menu now runs across the top: Dashboard, Organizations, Billing and Signed-in devices, with your name in the corner.

The Dashboard now shows four things at a glance: your plan and its next date, the machines signed in to your account, the organizations you belong to with your role in each, and whether two-factor sign-in is on. Each one links to the page where you change it.

An organization's Members page opens with how many seats are handed out against how many are paid for. Giving or taking back a seat stays on each person's row, and Change roles and Remove are now in the ⋯ menu beside it. On the Billing pages your plan and your billing details sit side by side, with the invoices underneath. The sign-in pages, the screen that confirms a new machine and the invitation pages all match.

Nothing was renamed: every page, button and field keeps its name and does what it did.

v0.20.2 — Windows sessions start, and consoles close

2026-08-19T00:00:00Z

Two Windows fixes that turn out to be the same bug seen from opposite ends. A session could refuse to start — a blinking cursor, then "Claude didn't start — it launched but produced no output, and an automatic retry didn't help either." And every terminal Plexus opened left its Windows console process behind when it closed, some of them spinning a CPU core for as long as the app stayed open. One report had 23 of those alive after a day of use, burning 85 CPU-hours between them while Plexus itself sat idle. There are fixes in here that are not Windows ones either: the review-and-fix cycle no longer marks findings as done when its agent never ran, and pull request comments you send to the agent can always be sent again.

Sessions that never started

A new Windows console asks the terminal it is attached to where the cursor is, and it will not start the program inside it until something answers. Plexus answered from its terminal view, which meant the answer could be missed entirely — and when it was missed, that session was stuck for good. Resuming again started a fresh console with the same problem, which is why Retry did not help.

Plexus now answers immediately, in the same place it reads the console's output, before any of the app's own machinery is involved. It was never a problem with your Claude installation, and nothing about that installation needed fixing.

The review-and-fix cycle's background agent could never answer at all — its terminal is deliberately read-only — so its rounds are covered by the same change.

A review round that didn't run keeps its comments

The review-and-fix cycle marked the comments it handed to a round as resolved the moment it launched the fix agent — about a minute before it could tell whether that agent had started at all. So when one didn't start, the round's findings were struck through anyway: the Review tab read as though there was nothing left to do, Send N comments to agent greyed out, and the per-file counts showed a tally of work that never happened.

A round now resolves its comments only once it has actually run. If the fix agent never started, the comments stay open and the next round hands them over again — so a cycle that stopped early leaves you exactly where you were, with every finding still there to act on.

The fix agent says when there is too much to send it

There is a limit to how much text can be handed to a program when it starts, and a cycle with a lot of open comments could exceed it. What came back was the operating system's own wording — "The filename or extension is too long." — attached to a failed cycle, which explained nothing.

Plexus now checks first and says what is wrong: how much there is, what the limit is, and that resolving or deleting some comments will let the cycle run. It never sends a shortened version of your comments, because an agent working from half a list is worse than one that didn't start.

Consoles are closed when a terminal closes

Stopping a session, switching away from one, closing a scratch terminal or finishing a review round now releases the Windows console that terminal was using, instead of leaving it running until you quit the app.

Switching between sessions was the quietest source of this. Plexus keeps a limited number of sessions warm and stops the least recently used one beyond that, so simply moving around a project with more sessions than the warm limit leaked a console each time — with nothing on screen to suggest it.

If you have been hitting this, you do not need to do anything after updating: the leftovers from earlier runs are gone the next time you quit and reopen Plexus.

A terminal that fails to open is retried

If building a terminal failed once, Plexus remembered the failure and reused it for every terminal afterwards, for as long as the app stayed open. Every session opened from that point on got no terminal — and on Windows, a session with no terminal was a session that could not start. Plexus now retries instead of caching the failure.

Sessions that fail to start no longer leave an agent behind

If the last step of starting or resuming a session failed, Plexus could return an error while the agent it had just launched kept running — with no way for you to see or stop it. That agent is now stopped as part of the failure.

Diagnostic logs stay a sensible size, and stay readable

Three fixes to the log behind Settings → Diagnostics:

It could grow without limit inside a single run — one report arrived at 179 MB — because the clean-up on start-up skipped any file whose oldest line was still inside the retention window, which is always true of a file something is actively filling. Oversized logs are now trimmed to their most recent portion regardless of age.
A session that failed to start wrote a warning about it every two seconds for as long as the app stayed open, which is what filled those logs. That warning is now capped, so the log keeps the part that explains the problem instead of burying it.
Lines written at the same moment from different parts of the app could interleave, splicing two entries into one unreadable line. Each entry is now written in one piece.

Setting Delete diagnostic logs after (days) to 0 still keeps everything, and a log you pointed Plexus at yourself with PLEXUS_DIAG is still never touched.

Pull request comments you can always send again

Handing a PR review comment to the agent marks it Sent so you don't send it twice. That mark now lasts only as long as the agent that received it. Stop the session, resume it, or lose the agent to a crash, and every comment it was given goes back to being sendable — because a prompt written to a terminal that is no longer there was never read by anybody.

Before, the mark lasted for as long as Plexus was open. A send into a session whose agent was not actually running still counted, so the comments were left chipped Sent, the button that sends them all disappeared, and restarting Plexus was the only way back.

That button also stays on screen now instead of vanishing once everything has been sent. It goes quiet and says what it is waiting for, rather than leaving you looking for a control that isn't there.

If you have Resolve PR comments after the agent fixes them turned on, it is held to the same rule: a comment is only resolved on GitHub or Bitbucket if the agent that was actually given it finishes the turn. A resume no longer resolves comments that agent never saw.

v0.20.0 — Send feedback, and open your dev server from the session

2026-08-16T00:00:00Z

Plexus can now hear back from you. There is a Feedback button in the app bar, the diagnostic log finally stops growing forever, a session's dev server is one click away from its tab strip, a session whose pull request has merged cleans itself up without stopping to ask, and a session that has handed its work to subagents says so rather than asking for you. And on Windows, two things that never worked on an npm install of Claude Code now do: every AI feature, and starting a session at all when your user name has a space in it.

Send feedback

Next to the search field there is now a Feedback button. Write whatever you want — a bug, a missing feature, something that annoys you — and it reaches us directly. No account, no issue tracker, no signing up.

Because Plexus is local-first, this is the one place where something you made can leave your machine, so the dialog is built around showing you exactly what that is. Nothing is sent until you press Send, and nothing is sent that the dialog did not put in front of you first.

What you can attach

A screenshot, only if you press Attach screenshot. It is a picture of the Plexus window drawn by Plexus itself, not a capture of your screen — it cannot contain another application, a second monitor, or anything behind the window, and Plexus never asks macOS for screen-recording permission. You see it before you send, and you can remove it again.

Diagnostic logs, on by default, with a Preview what's included panel that prints the exact text that will be uploaded. Anything shaped like a token, key or password is blanked out before it leaves your machine, and your home folder and username are rewritten. What it keeps — deliberately, because it is what makes the log useful — is repository paths, branch names, worktree folders, session ids and timings.

If Diagnostic logging is switched off, Plexus says so, still attaches the activity trail it keeps in memory, and offers to turn logging on — while being honest that it starts recording from that moment and will not help the report you are writing.

Your email address is optional and blank unless you type it. Without it we simply cannot reply.

Deleting a report

Every report comes back with a reference code, which Plexus keeps in a list on your device. Mail that code to timo@codedwords.com and we delete the report and everything attached to it. Screenshots and logs are deleted automatically after 90 days in any case, and the message itself after a year.

Full details of what is and is not sent are at https://runplexus.com/docs/feedback and in the Privacy Policy.

Diagnostic logs stop growing forever

plexus-diag.log used to be appended to and never trimmed. Now every launch drops lines older than seven days.

You can change that with Delete diagnostic logs after (days) under Settings → Advanced — set it to 0 to keep everything, which is what you want when you are capturing a problem that only reappears every few weeks. A log file you pinned yourself with the PLEXUS_DIAG environment variable is never touched.

Diagnostic logging itself is still off by default, and still writes nothing until you turn it on.

Open the session's dev server

Every session gets its own block of ten localhost ports, and the first of them — the one your dev server should be listening on — used to be a small grey number on the session's sidebar row and in the header bar. A number you could read, in two places you could not do anything with it.

It has moved to where it is useful. Open a session and its tab strip now carries an Open localhost:20030 button, beside Hook output. Click it and your browser opens at that port. The caret next to it holds Copy port and Reassign ports, so nothing about a session's ports asks you to leave the session any more. In Compact the label shortens to localhost:20030, and on a narrow pane it drops to the icon, so the tabs beside it stay reachable however far you drag the sidebar over. Hover it and the tooltip names the whole block, ports 20030 through 20039.

The button is there when the session holds a block and Assign dev server ports is on for that project — and it goes the moment you switch that setting off, with no restart. It is never shown greyed out: a session that has never started holds no ports, and there is nothing you could press to give it some.

The dashboard keeps its port chip. That screen has no session tab strip to put a button in, and it is the one place you compare one session's ports against another's. The ⋯ menu on every session row, in the sidebar and on the dashboard alike, still carries the same three port actions it always did.

One thing worth knowing now that reassigning is a click away: it does not move a dev server that is already running. The port variables are handed to what Plexus starts, at the moment it starts it, so a server your run hook launched keeps listening where it was told to while the button already names the new block. Reassign while the session is stopped, or restart it afterwards.

Full details are at https://runplexus.com/docs/worktrees#dev-server-ports.

Cleanup after a merge no longer asks

Clean up a session when its pull request is merged has always described something Plexus did not quite do. It said it would remove the session automatically; what it actually did was wait until a background check noticed the merge — sometimes a minute after somebody else pressed the button — and then open a confirmation dialog in front of whatever you were doing.

That dialog is gone. If you switched the setting on, that was the answer. Plexus now cleans the session up on its own, with no interruption, and tells you afterwards what it did.

It still follows your When you remove a session setting, so Archive (keep a restorable copy) files the session away and leaves everything on disk. The one change is Ask each time: there is nobody to ask when the trigger is a background check, so it deletes there, the same as Delete immediately. The setting's description in Settings → Git & PRs now says all of this outright.

Whether the session's branch goes with it is inherited from the Also delete the local branch switch in the ordinary removal dialog — the one you last used when removing a session by hand. That switch starts off, so branches are kept until you have ticked it at least once. A branch that existed before the session, one you started work on rather than one Plexus cut, is always kept: deleting somebody else's branch is not a decision Plexus will make while you are not looking.

Only a merge Plexus watched

The cleanup runs for a pull request Plexus saw while it was open. One that was opened and merged entirely between two checks — or that Plexus is meeting for the first time already merged — is left alone. Removing a worktree cannot be undone, so it is not something to do on the strength of a status just seen for the first time.

Several at once

If more than one session's pull request has merged, all of them are cleaned up now, one after another. Previously only the last one got its dialog and the rest were quietly skipped, which is why a merged session sometimes stayed in the sidebar for no visible reason.

Sessions say "Delegating" instead of "Needs you"

A session with background subagents running now says Delegating — in the same blue as the ring around its dot — whenever its main agent is not mid-turn. It reads that way on the second line of its sidebar row and in the header bar at Normal density, and in ⌘K search, where it comes with the count: Delegating · 2.

A session whose agent is still working is untouched. That one keeps saying Working, and Working · 2 delegating in search, because the main agent being busy is the more useful half of that answer.

Before this, the same session said Needs you in amber, or Idle — and amber reads as a call to action for a session where the agent has handed work off and the delegated work is what is still running. The rest of the app had already decided that isn't a moment worth pulling you in for: a turn that ends with subagents still going gets no chime and no notification. The word was the last surface still calling you over.

One thing worth knowing, because the word alone won't tell you: a session paused on a permission prompt, a plan waiting for approval or a question also reads Delegating while the ring is lit. The tell is the dot, which is deliberately unchanged — it stays amber, and hovering it still says Waiting for input — 2 subagents running.

Nothing else moves. The dot, the ring, the tooltip and every "N delegating" count are exactly as they were.

AI features on a Windows npm install

Run AI review, the AI pull request title and description, session summaries and every round of the review-and-fix cycle now work on an npm or Volta install of Claude Code, on Windows, with nothing for you to change. No setting, no reinstall.

They had never worked there. Plexus handed Claude its instructions on the command line, and on Windows an npm install of Claude Code is a small claude.cmd script that Windows runs through the command prompt — which cannot carry a line break inside a command-line argument at all. Every one of those instructions is more than one line long, so each of those features failed every single time, before Claude was even started. AI commit messages were the one exception, and only because their instruction happens to fit on a single line.

Plexus now sends the instruction to Claude the same way it has always sent the diff or the transcript that goes with it: through the program's input rather than its command line. That is the case on macOS and Linux too, not only on Windows — one route everywhere, so this is not a special case that only breaks again somewhere nobody looks. What the agent is asked for is unchanged, word for word.

The review-and-fix agent runs in a terminal of its own and has no such input to write to, so on those installs Plexus hands it a file holding the instructions instead. That one is the only part of this that is Windows-specific: for the fix agent, native installs of Claude Code and every install on macOS and Linux take exactly the route they always did.

If Plexus does still refuse an argument on Windows — a session name containing a character the command prompt would treat as punctuation, for instance — the message now tells you what to do about it. It leads with claude install, the Claude Code command that replaces an npm install with the native build without opening a browser, and offers the PowerShell one-liner irm https://claude.ai/install.ps1 | iex beside it. The old message pointed at a page that answers with an error.

Sessions start when your Windows user name has a space in it

A second Windows bug, found while fixing the first, and unrelated to AI features: if the path to your claude.cmd contained a space, starting a session did not work at all. That is not an exotic case — a Windows profile named First Last puts a space in the npm install path, and so does any install under C:\Program Files.

Plexus runs a claude.cmd through the Windows command prompt, and a quoted path at the very start of that command was being taken apart by the command prompt's own quote handling before it ever ran. The command is now written so that cannot happen. Nothing about your setup needs to change.

v0.19.0 — Appearance settings, two interface modes, and one header per window

2026-08-14T00:00:00Z

Plexus has always had exactly one look, and it was the tightest one — built for the moment you have five to ten sessions live and every pixel is signal. That is still there, and it is still what Compact means. But it is no longer the only answer, and it is no longer something you have to accept silently.

Settings has a new Appearance page. Theme moves there from the title-bar button — including "match my operating system", which the button could take you out of but never back into. Beside it are two new choices about the shape of the app itself.

Appearance settings

Settings → Appearance. Three preferences, each shown as a pair of cards with a small diagram of the layout it produces, so you can see the difference before you commit to it.

These are per-machine preferences. Unlike everything else in Settings they are never inherited by a workspace or project, and they will not appear on a project's own settings page — how Plexus looks on this laptop is not a property of your repository.

Theme

Light, Dark, and Match system, which is what a new install uses. The title-bar toggle stays as a shortcut between light and dark; the page is where you get back to following the OS.

Compact and Normal

Density is a layout mode, not a spacing slider. Each one changes what a session row is.

Compact is one 28px line per session: the name, a coloured dot for the agent's state, and the pull-request icon. It is the layout Plexus shipped with, unchanged.

Normal — the new default — gives a session two lines. The second one names the branch it is on and says what the agent is doing in words: Working, Needs you, Idle.

The glyph beside that branch name does two jobs at once. Its shape tells you where the branch came from: a branch Plexus cut for the session, or a link for one it attached to — which is what you want to spot before a rebase rewrites history someone else may already have. Its colour is the pull request: grey when there is none, green when one is open, purple once it is merged. Click it to open the PR.

The row's ⋯ menu no longer holds a place for itself while it is hidden, so the session name and the state word run to the edge of the sidebar instead of stopping short of it. The menu appears over that edge when you hover the row.

Switch between them from the app bar, or from Settings → Appearance.

The session and project tabs changed with them: the active tab is now marked by a brand underline along the bottom of the strip rather than a filled chip, and each tab carries its own glyph.

One active workspace

The sidebar used to nest three levels: workspace, then project, then session. It now shows one workspace at a time, chosen from a switcher in the app bar — so a project is the first thing in the sidebar and a session is one step in, with no chain of chevrons to open before you reach the thing you wanted.

The switcher's menu lists every workspace with its session count and, in amber, how many are waiting on you. That is the question you switch workspaces to answer, so it is visible before you switch rather than after.

Under that list are the active workspace's own actions — Edit, Settings, Set as default and Delete workspace. With one workspace shown at a time there is no workspace row in the sidebar to hang them on, so this menu is where they live.

Prefer the old tree? Settings → Appearance → Workspace navigation → All workspaces in the sidebar brings all three levels back — and it is easier to read than it was. Each workspace is now drawn as a group: a header that stays put while its projects scroll past, over a well with a rail down its left edge, so you can see where one workspace ends and the next begins instead of counting indentation. The workspace holding whatever you have open is tinted, and nothing is tinted when nothing is open.

Project rows also gained a standing button for the project view — the dashboard, git client and terminal — which previously you could only reach by knowing that clicking the row did something.

Search your sessions

Press ⌘K — Ctrl+K on Windows and Linux — or click the search field in the app bar, and type. Every session and every project in the tree is there: match on a session's name, the branch it is on, the project it belongs to, or the workspace. Two words narrow instead of widen, so plexus settings finds the one session you meant.

Enter opens it. If it lives in a workspace you are not currently looking at, or in a project that is collapsed, Plexus points the sidebar at it and scrolls the row into view rather than selecting something you cannot see. With nothing typed you get your whole tree as a flat list, 50 rows at a time — when there are more than that, the bar along the bottom tells you how many. The same is now true of the Open button on a notification — it used to be able to take you to a row that was nowhere on screen.

The shortcut works while the agent terminal has focus, which is where it is most useful and where a shortcut normally stands down. That does mean Ctrl+K no longer reaches the terminal on Windows and Linux, where it clears to the end of the line; if you want it back, Settings → Keybindings → Search sessions and projects rebinds or unbinds it. It does stand down for one thing: another dialog. Opening a search on top of a half-filled New session dialog would navigate away and leave that dialog stranded over an unrelated session.

Choose the project when you create a session

The New session dialog inherited its project from wherever you opened it, and the + in the app bar had to guess — the project you had selected, or the first one in the workspace. When the guess was wrong the only way out was to close the dialog and start again.

It now asks. Project is a field in the dialog, prefilled with that same guess and changeable in one click. It offers what the sidebar offers: the current workspace's projects, or every workspace's grouped by name if you use the "All workspaces in the sidebar" setting. Open it on a project from another workspace — from a dashboard row — and both are listed under their names, so the way back is a click rather than a reopen.

Switching re-reads that repository's branches and clears the base and branch you had picked — main in one repository is not main in another — while keeping the name you typed. A name Plexus filled in for you from a branch goes with that branch.

The New branch / Existing branch switch is now a segmented control, with the explanation for whichever mode is selected below it.

Session summaries introduce themselves

Plexus can keep an AI-written digest of a session — what you asked for, and what the agent has done about it — refreshed as the agent stops, while you have the panel open on it. It has been there for a while, switched off by default. The trouble was that the same setting also hid its button, so the only way to find the feature was to already know it existed.

Summary is now always in the session header. Open it with summaries switched off and the panel says what it does and what it costs — each refresh sends that session's transcript to the agent and uses one of your plan's turns — and offers two ways to switch it on: for the project you are working in, or everywhere. Either way Plexus writes the first summary straight away rather than leaving you with an empty panel until the agent next stops.

Nothing is sent anywhere until you press one of those buttons.

One header per window

The session view and the project view each used to draw their own header inside the right pane, starting at the sidebar's edge and repeating what the sidebar already showed. There is now a single bar across the full width of the window that says where you are — project, then session, then the agent's state — and carries the tools that act on it. The pane below it is just the work.

Dev server ports

Running two sessions of one repository has always had the same sharp edge: both want to start the dev server, and the second one finds port 3000 taken. Plexus now hands every session its own block of ten localhost ports and puts them in the environment of everything it starts for that session — the agent, the session's terminal tab, and every lifecycle hook.

The block is reserved when a session starts, checked to be genuinely free before Plexus commits to it, and kept for as long as the session's working copy exists. Resuming gives a session the same ports it had, so a dev server that is already listening is never moved out from under itself. Tearing the worktree down releases them.

Each session's first port shows as a small chip in three places — its sidebar row, its dashboard row, and the header bar while it is open. Hover it and the tooltip names the whole range.

Its ⋯ menu, in the sidebar and on the dashboard both, gains three matching actions: Open localhost:20030 launches your browser at that port, Copy port puts the number on the clipboard, and Reassign ports is covered below. They are absent rather than greyed out for a session that holds no block, since nothing you could do from that menu would give it one.

What your scripts get

PLEXUS_PORT is the session's first port — the one to use. PLEXUS_PORT_BASE is the same number for scripts that do arithmetic, PLEXUS_PORT_COUNT is how many the block holds, and PLEXUS_PORT_1 through PLEXUS_PORT_9 are the rest of it, for a second server, a test database or a debugger. PORT is set too, because that is the name Next.js, Nuxt, Rails and Express already read.

The intended home for all of this is a run hook, which fires on every start and resume:

pnpm dev --port $PLEXUS_PORT

Commit that to your repository's .plexus/hooks.json and everyone on the team gets it from a clone.

Your dev server still has to be told

Plexus sets the variables. It does not inspect your project, does not know which framework you use, and never adds a flag to a command you wrote. If your server reads PORT on its own, there is nothing else to do. Vite, Astro and Angular do not — they need --port $PLEXUS_PORT on the command, or the value threaded into their config. And if nothing in your project reads any of these variables, nothing about your setup changes.

One thing that may change under you

Most .env loaders leave a variable alone when the process already has one. So for a project whose .env is copied into each session and carries a PORT=3000 line, that line no longer wins: Plexus sets PORT in the environment first, and the loader will not overwrite it. If you were fixing a port that way — which is exactly what the old documentation suggested — your server now starts somewhere in the twenty-thousands instead.

That is usually the outcome you wanted. If it isn't, open Settings → Worktrees & Hooks and clear Extra port variables: with the list empty, Plexus sets only its own PLEXUS_PORT* names and PORT is yours again.

The range, and the settings behind it

Blocks come out of 20000–32000 — around 1200 of them. That window sits above every common dev-server port, above 10080 (the highest port Chrome and Firefox refuse to open, which would give you a server that starts fine and a browser that will not load it), and below 32768, where Linux starts handing the same numbers out to outgoing connections. Move it with First port and Last port if it clashes with something on your machine.

All five settings live in Settings → Worktrees & Hooks, globally or per project: Assign dev server ports (on), First port, Last port, Extra port variables, and Write ports to file.

That last one is off by default and covers what environment variables cannot reach — a docker compose file reading .env for substitution, or a server you launch yourself from a terminal Plexus did not open. Name a file and Plexus keeps a marked block of the same variables inside it, refreshed every time the session comes back up, with everything outside the markers left exactly as you wrote it. It is for compose services, database ports and app config. It is not a second way to move a dev server: Vite, for one, loads .env.local and still takes its listen port only from its config or its command line.

If a port gets taken anyway

A reservation is remembered, not re-checked — re-checking it on every resume could move a running server's ports out from under it — so something else on your machine can claim one of a stopped session's ports while it is down. Reassign ports in that session's ⋯ menu drops the block and searches again. If nothing has taken the old one after all, you get it back: what you asked for is a block that works, not a different number.

Full details, including what the reservation does and does not promise, are at https://runplexus.com/docs/worktrees#dev-server-ports.

Watch the review-and-fix cycle work

A review-and-fix cycle can run for the better part of an hour, and until now the only thing it told you was "Cycle round 2 — agent applying fixes…". That sentence is the same on a round that is editing files and a round that is stuck, which made a long round and a broken one impossible to tell apart.

Watch agent now sits next to Stop, both in the Review tab's status strip and in the session header, and only while a cycle is actually running. It opens a panel across the bottom of the session with two halves. The top is a running account: which round it is on, how many files the review is reading, when it asked the model, how many comments came back, and how long each phase took. The bottom is a live terminal on the fix agent itself, so you can watch what it is editing as it happens.

The terminal is read-only. You can select and copy from it, but nothing you type reaches the agent — which also means a stray keystroke can't interrupt a round that has been going for twenty minutes. The output never touches disk, and it only reaches the app while the panel is open; closing it stops the stream at the source rather than just hiding it. Open the panel part-way through a round and it back-fills the most recent stretch so you aren't starting from blank.

Only the fix half runs in a terminal. During a reviewing phase the panel says so, and the account above it carries the story instead — with a live clock on the current step, so you can always see something is moving.

Rounds that don't idle, and settings for the rest

Every headless call Plexus makes — the AI review, session summaries, pull request descriptions, commit messages — was starting up your configured MCP servers first, waiting for all of them to connect, and shutting them down again when it finished. None of those features can use an MCP tool. On a machine with a handful of servers configured that was tens of seconds of waiting per call, twice per review-and-fix round, for nothing. They are no longer started.

Three other things on the review path were quietly wrong. It ran in whatever directory Plexus itself had been launched from rather than the session's worktree. It had no time limit at all, so a review that wedged looked exactly like a review that was merely slow, forever — it now gives up after fifteen minutes and says so, and inside a cycle that just skips the round. And the fix agent was handed the review comments with nothing telling it to stay on them, so in a repository whose agent instructions describe a lot of routine upkeep, a round applying six comments could go and do all of that too.

The parts that are genuinely a matter of taste are now settings rather than assumptions (Settings → Git & PRs, overridable per workspace or project). Model and Effort pickers for the review and, for the first time, for the fix agent — the expensive half, which previously had no controls whatsoever and silently inherited whatever your Claude Code configuration resolved to. Review-and-fix agent instructions for what the fix agent is told before the comments. And Allow MCP servers in the review-and-fix agent, off by default, for the rare project whose fixes genuinely need one.

All four model and effort settings default to Automatic, so nothing changes until you choose — but the new panel reports what each round actually used, which is the part that was invisible before.

A more reliable subagent ring

The blue ring around a session's dot means the agent handed work to subagents and carried on without waiting for them. When it appeared it was right — it just did not appear anywhere near often enough, and once lit it did not always go out again.

Work started by a workflow counts now. A workflow that fans out to several agents at once records the fan-out but nothing about the agents themselves, so the ring stayed dark for exactly the case where the most work is running in parallel. Plexus now follows the run itself, and those agents light the ring and drop off it as each one finishes.

A launch is reported the moment it happens, rather than when the session's conversation record catches up. Those are usually the same instant, with one exception that made the ring look unreliable: if the same turn also stopped to ask you a question or to show you a plan, the record could land after the work had already been reported finished — and the ring then never appeared at all. Nothing about that was visible from the outside, so the same action seemed to work sometimes and not others.

What lights the ring is unchanged. An agent the main agent is sitting and waiting on is the main agent working, so it stays a plain green dot with no ring; the ring is for work running beside your session, not work it is blocked on.

Stopping a session clears it. A session stopped in the middle of a delegation kept pulsing blue until you restarted Plexus. Stopping it — or the agent exiting on its own — now clears the ring immediately, which is what the documentation has always said happens.

And it shows up where sessions are only summarised. A collapsed project used to hide delegated work completely; its row now carries a small ring and the number of sessions delegating underneath it. The workspace switcher in the app bar does the same for the workspace you are in, and its menu shows that count per workspace beside the "need you" one. In ⌘K search, a session's second line spells it out in words — Working · 2 delegating.

A dark ring can now explain itself. Turn on Diagnostic logging (Settings → Advanced) and Plexus records what the session actually delegated to — including the kinds of agent that deliberately do not light the ring, counted alongside the ones that do. If your subagents did not show up, that tells you whether Plexus missed them or whether they were the sort that never lights it, without you having to reproduce anything.

v0.18.0 — An activity dot that works on Windows, published review notes, and comments that delete

2026-08-12T00:00:00Z

The notes you leave on a diff line have always been private — written for the agent, kept on your machine. Sometimes the right reader is a person instead. A note can now be posted to the session's pull request as an inline comment on the same line, one at a time or the whole review at once. And notes finally keep their line breaks, so a paragraph stays a paragraph wherever it ends up.

Deleting one of those notes could also do nothing at all, and then insist the note no longer existed. Both halves of that are fixed.

Connected accounts got a fix of their own: a Bitbucket connection that was short of a permission could ask you to reconnect for ever, and now it stops once it has been asked and answered.

On some Windows machines the green dot next to a session simply never lit up. The agent was working perfectly — it just never looked like it, so a wall of sessions gave you nothing to read and the dashboard was worth no more than a glance at each terminal.

The cause was a link in the chain nobody could see. Plexus asked Claude Code to report what your agent was doing by running a small command, and Claude Code hands that command to a shell — which on Windows is PowerShell unless you happen to have Git Bash installed. There the report was quietly lost on the way. That is why it broke for some Windows users and not others, and why nothing anywhere said so.

Plexus no longer asks a shell. It also no longer depends on those reports arriving at all, and if something is still wrong there is now a button that tells you which link is broken.

Publish a note to the pull request

Every inline note carries a fourth button next to Edit, Resolve and Delete: publish it. It posts the note to the session's pull request as an inline comment on the same file and line, under your own GitHub or Bitbucket account.

Plexus asks first. A confirmation shows the note about to go out and names the repository it is going to, as owner/repo#number — publishing is public and there is no undo from Plexus, so the last step is always yours.

Publishing consumes the note. Once the comment lands, the local copy is deleted and the pull request's own thread renders on that line in its place, so there is nothing left in Plexus to accidentally send twice. To change or remove it afterwards, edit or delete the comment on GitHub or Bitbucket, the same as any other comment you left there.

The Review header carries the bulk version — the same confirmation, a button with a count. It sends the session's unresolved notes, up to forty at a time; with more than that the dialog says so ("the first 40 of 57") rather than quietly leaving the rest behind. Notes whose file has left the diff are skipped, since there is no line left to anchor them to — which is why the count can be lower than the one on Send N comments to agent.

Resolved notes can be published too. Send N comments to agent resolves everything it sends, and so does each round of the review-and-fix cycle, so the notes worth showing a reviewer are often exactly the resolved ones.

Notes the AI review agent wrote say so

A published note that the AI review agent drafted opens with an italic line, Drafted by the Plexus review agent. — someone reading the thread should know which findings came from a model rather than from you. Notes you wrote yourself go out exactly as written, with no marker, the same as the line composer's Comment on the PR always has.

When it's offered, and what can still refuse it

Both buttons appear only once the pull request's conversation has actually loaded, only while the pull request's comments are shown, and only while the pull request is open — a merged or closed one takes no new comments.

A line that isn't part of the pull request's diff yet is refused by the provider. Plexus keeps that note and tells you which ones didn't land, so committing and pushing and trying again is all it takes. A large batch goes out one comment at a time, paced so the provider doesn't rate-limit it halfway through; if it does run into a rate limit or an authentication problem it stops there and reports the rest as untried, rather than hammering an endpoint that has already said no.

And you can stop a batch yourself: while one is running, the header button becomes a Stop. It stops at the next note — the comment already on its way still lands — and leaves the rest untouched, so publishing again picks up where it left off.

Notes keep their line breaks

An inline note used to be flattened into a single line the moment it was saved, which turned a two-paragraph thought — or an AI review finding with a code block in it — into one long run of text. It doesn't any more: paragraphs, nested lists, indented code fences and the alignment inside them survive being saved, so the Review tab shows you the note you wrote, and so does the pull request when you publish it. That matters most for a suggestion block, which the person reading your comment can apply into the file with one click.

Two things a saved note still bounds, so no note can pad the rest of itself out of view: a run of spaces is kept up to 16 columns, and a run of blank lines up to two. A very long note now scrolls inside its own thread rather than pushing the diff off screen.

The prompt the agent receives is unchanged: it still gets one line per note, so a long comment can't split the instruction it belongs to.

Reconnect notices that stop coming back

If your Bitbucket connection was short of a permission — the access to your repositories, or to pull requests — Plexus asked you to reconnect, then announced Bitbucket access restored a moment later, then showed the very same notice the next time you searched for a repository or refreshed a pull request. Not now didn't end it either: the notice was back with the next round. Reconnecting never stopped the app asking you to reconnect.

Behind it was a check being read as an all-clear it was never able to give. Plexus checks your Bitbucket connection every few hours, but that check can only confirm one thing — that your workspaces are still visible — because Bitbucket offers no way to ask what else a connection covers. Passing it was treated as proof that everything was fine, which wiped a warning about a completely different permission, and wiped the fact that you had put that warning away.

A check now clears a warning only when it actually tested the permission the warning is about. So a notice raised by a real refusal stays up until the refusal stops, Not now puts it away for good, and the "access restored" message only appears when something really was restored.

Three things follow from that:

When signing in again genuinely can't help, Plexus says so and stops asking. Some Bitbucket permissions have to be enabled on the Plexus side, where no amount of re-signing-in will widen them. Once a reconnect has been tried and the access is still short, Plexus tells you that plainly instead of offering the same button again — and it now remembers it after a restart, so you don't walk into the same loop every time you open the app.
The notice names the permission the way Bitbucket does. Bitbucket's newer permission names are recognised now, so a notice reads Account: Read — the checkbox as it is labelled — rather than an internal identifier you'd have to guess at.
A refusal while loading a pull request counts. If a provider turned down a pull-request request because of a missing permission, that could pass without ever reaching a notice. It now raises the same notice as everything else, against the account it came from.

The access each connection carries, in Settings → About

Settings → About now lists every connected account under Connected accounts, together with the access the provider recorded for it. When Plexus tells you a permission has to be enabled on our side and asks you to report it, that list is the thing to copy into the report — until now there was no way to see it from the app at all. A provider that recorded nothing says so, rather than showing a blank you would read as "no access".

Deleting an inline comment

Clicking the trash icon on an inline comment in the Review tab could leave the comment sitting exactly where it was, with no error and no sign anything had happened. Clicking it a second time then said not found: review comment 3 — and the comment still stayed on screen. The frustrating part was invisible: the first click had already deleted it. The list you were looking at had simply put it back.

It deletes on the first click now, and stays deleted — through a tab switch, and through quitting and reopening Plexus.

Two things caused a comment to come back. Plexus matched a comment by its number alone, and those numbers get reused after you delete a session, so a comment could be matched against a long-gone comment from a session you had already thrown away. And re-reading the comment list in the background could overwrite a comment you had just deleted with an older copy of the list. Neither can happen now: a comment is only ever matched inside the session it belongs to, and a list that was read before your change is discarded rather than applied on top of it.

Resolve and Edit were affected by the same matching fault and are fixed with it — they could silently apply to the wrong copy of a comment, so the strikethrough or the new text only showed up after you left the Review tab and came back.

Deleting a comment that is already gone is no longer reported as an error. It is what you asked for, so the comment simply disappears.

While a change to a comment is still being saved — a delete, a resolve or an edit — that comment's buttons are greyed out. A second click can't land on a comment that is already on its way out, and two quick clicks on Resolve can no longer race each other into leaving the row showing the opposite of what was saved.

Comments from a deleted session no longer show up under a new one

Deleting a session left its inline comments in memory. Because Plexus reuses the internal numbering of deleted sessions, a session created afterwards could show the deleted session's comments in its Review tab until you switched tabs. They are now cleared along with the rest of the session's state when it is deleted.

A change you made just before deleting a session can no longer land in the session that inherits its number either, which could otherwise leave a comment in a brand-new session's Review tab that had never been written there.

The first comment on a file appears immediately

Adding the very first comment to a session — before Plexus had finished reading that session's existing comments — could leave it invisible until something else redrew the diff. It shows up as soon as you add it.

Commenting during that same moment could also hide the comments that were already there: Plexus discards a comment list it read before your change, and it now reads a fresh one instead of waiting for the next time you open the Review tab.

Sessions on Windows show what the agent is doing

Plexus now has Claude Code report activity directly, with no command and no shell in between — so there is nothing left to lose the message. Working, waiting for you, plan-mode pauses and the background-subagent ring all behave on Windows the way they always have on macOS and Linux.

If you are running an older Claude Code, Plexus keeps using the previous method, which is unchanged. Updating Claude Code is worth it on Windows.

The dot keeps working even when the reports don't

The activity dot used to be entirely dependent on those reports. If none arrived — an old Claude Code, a policy that blocks them, a broken PATH — the dot was simply dead, and a session that ran a tool could get stuck showing green forever, with Reset status the only way out.

Now, when a session has gone a while without a single report, Plexus falls back to reading the agent's own conversation record instead. It turns green while the agent is writing and goes back to amber when the turn ends — including for turns that use no tools at all, which the old behaviour could never show. A session that was interrupted mid-tool now returns to amber on its own instead of pulsing green until you notice.

This only ever engages for a session that has had no reports at all, so nothing changes for a session where they are arriving normally.

Check activity hooks

There is a new Check activity hooks… item in a session's ⋯ menu, right above Reset status. It runs the whole chain end to end and tells you in one line what it found — whether Claude Code is running Plexus's hooks, whether they are reaching Plexus, and whether this session is pointing at an older run of the app and needs restarting.

It also reports what happened on the session's last real turn, not just a test, so a problem that has already happened can be diagnosed without reproducing it. Copy report puts the whole thing on your clipboard for a bug report. Plexus's own secret is never in it. Claude Code reports hook errors for the whole turn rather than per hook, so if any of your other hooks failed their errors appear too — that is where your own API keys can end up, so those errors stay on screen and are kept out of the copied report unless you turn on Include these in Copy report underneath them. The report still says how many there were, so nobody reads it as "no errors".

Anonymous usage data is now always on

Plexus has always sent one small message a day: your operating system, your processor type, the app version, and a random install id that our server scrambles with a key that changes every day, so today's message can't be matched against yesterday's. It is what tells us how many people actually use Plexus — the number every decision about what to build next rests on.

That message is now part of the app, it carries more, and the Share anonymous usage data setting is gone, along with the Privacy page in Settings that held nothing else. If you had switched that setting off, it is now on again. We are telling you plainly rather than letting you find out: the reason the switch went is that there is nothing in what we send that identifies you, your machine, or your work, and a switch labelled "share anonymous usage data" suggests otherwise.

The message now also carries how much the app was used since the previous one — how many sessions you ran, how many turns you exchanged with an agent, how often each feature and Git operation was used, and how often things failed and in what broad way. Alongside that it carries a few coarse facts about your setup: your colour theme, which model you have selected, whether a Git provider is connected, how many workspaces and projects you have as a range like "6-20" rather than an exact figure, your operating-system version, how Plexus was installed, your shell, and the version of the Claude CLI it is driving.

What is never sent has not changed, and this is the part that matters: no code, no file contents, no prompts, no file paths, no repository, project or branch names, no commit or pull-request text, no error messages, no IP address. Nothing you type is ever part of it, and every value we do send is either a number or one of a fixed set of options — never free text.

Three things keep it anonymous rather than merely promised. The usage counts are added into shared daily totals the moment they arrive and are never stored against your install, so no record of "what this install did" exists on our side at any point. The daily id used to count how many installs were active is deleted every night once it has been counted. And the random install id stored on your own machine now expires after a year — Plexus replaces it with a new one, so nothing identifying the install persists indefinitely, and there is no version of it we could go back and join anything to. What survives is aggregate: "1,240 active installs on macOS running 0.18.0". It is all stored in the EU.

If you need Plexus to send nothing at all — a locked-down machine, an offline-by-policy network — it still honours the DO_NOT_TRACK and PLEXUS_NO_TELEMETRY environment variables. Set either one before launching and no message is sent. Development builds never send anything either.

The full detail, including the legal basis, is in the Privacy Policy at https://runplexus.com/legal/privacy.

Fixes

A session whose folder is spelled differently from how Plexus recorded it — a different drive-letter case, a trailing slash, one of Windows' long-path prefixes — no longer loses its activity updates.
When the check finds that a session's hooks point at an earlier run of Plexus, or that it has none at all, it can now repair them in place — no restart, so the agent keeps its conversation and whatever it is in the middle of. If you have just updated Claude Code, the repair picks that up as well and switches the session to the newer, shell-free method — without restarting Plexus either.
Turning on Diagnostic logging in Settings → Advanced now records the whole activity chain: whether the hooks were installed, whether Claude Code ran them, whether they reached Plexus, and which session they were matched to.

v0.17.1 — A commit graph that stays on screen, and links that open

2026-08-09T00:00:00Z

The project Git tab's commit graph could go blank and stay blank until you switched to another tab and back. It no longer can — and while you are down in a repository's history, refreshing now keeps your place instead of throwing it away.

Clicking a link in Plexus mostly did nothing, either. The Open in browser button on a pull-request comment, a link inside a comment someone wrote on your PR, a link in a markdown file you were previewing, a dependency's homepage on the About screen, a link in this very changelog window — all of them were dead. Not slow, not an error: nothing at all. They open now.

The commit graph no longer goes blank

Scrolling a fair way down a project's commit history and then doing anything that reloaded it could leave the graph pane empty. Deleting a branch was the easiest way to hit it, but it did not need a git operation at all: leaving Plexus and coming back, or an agent committing in a session worktree of the same repository, would do it just as well. Nothing brought the graph back except switching to another tab and returning — and typing into Search commits while scrolled down could empty the pane the same way, taking the search results with it.

The pane now stays on the deepest position that still exists whenever the history under it gets shorter, so there is nothing left to strand it.

Refreshing keeps your place in the history

Loading more commits and then refreshing used to snap you back to the most recent 200, which happened on every commit, checkout, branch switch and background refresh. A refresh now reloads as much history as you had actually loaded, so the graph stays where you were reading.

The graph says when it is loading, and when it could not load

If reading a repository's history failed, the graph pane simply sat empty with no explanation and no way to try again. It now tells you it is loading while it works, and shows what went wrong with a Try again button if it could not.

Links open in your browser again

The button that started it was the small Open in browser icon on a pull-request comment thread in the Review tab, and the read them on the provider link next to a thread Plexus had only fetched part of. Both went nowhere. The same fault was underneath every other link in the app that was written as markdown rather than as a button — links inside PR comment bodies, in the Explorer's markdown preview, in an AI session summary, and in the What's new window you are probably reading this in.

mailto: links now open your mail client, too. They used to be styled as links, sit there looking clickable, and do nothing.

Where Plexus genuinely cannot open something — an address in a form no browser handles — it no longer shows you a button for it. A dependency on Settings → About whose homepage Plexus can't open is now printed as plain text instead of a link that fails silently, and a pull-request comment whose permalink is unusable simply has no button. If your system refuses to open a link, you get a message saying so rather than nothing happening.

Session summaries can't lose the window

A link in an AI session summary was worse than dead. Summaries are written by the agent, and if one contained a link to a file in the repository — the kind of thing an agent writes without thinking about it — clicking it replaced Plexus's own window with a blank page, with no way back except quitting and reopening the app.

Links in a summary now behave like links everywhere else: the ones that point at a real web page open in your browser, and the ones that point at a file in your repository do nothing at all.

v0.17.0 — Remotes without a terminal, discarding where you are looking, and a file list that remembers

2026-08-07T00:00:00Z

The project Git tab can now add, edit and remove the repository's remotes: right-click a remote's heading in the refs panel to rename it, point it somewhere else, or drop it — and hover it to see where it actually points.

Throwing away uncommitted work has stopped meaning a hunt through the panel header, too. Changed files answer to a right-click like everything else in the git client, the whole working tree can go in one action, and a single hunk can go without the rest of the file. And in the Review tab, resolving a comment no longer drops the file from the file list — each row now says both how many comments are still open and how many have been dealt with.

Add, edit and remove remotes

Until now the Git tab showed you the remotes your repository had and left changing them to a terminal. Each remote's heading in the refs panel is now a menu: Edit remote…, Add remote…, Remove remote…, and copies of its URL and its name. Hovering that heading tells you the URL it points at, and the separate push URL underneath when it has one — so a repository whose origin quietly points at the wrong fork is something you can now see rather than something you find out about on the next push.

Add remote… takes a name and a URL — HTTPS, SSH, or a path to a repository on your own machine. Edit remote… renames it, repoints it, and can give it a separate push URL so fetches and pushes go to different places. Renaming is the safe kind of rewrite: the remote's branches move to the new name and every local branch that was tracking one is repointed for you.

If the repository has no remotes at all, the refs panel offers Add remote… on the spot, and so does the Pull button's menu — with nothing to pull from, there is no heading to right-click.

Adding a remote doesn't reach out to it

The Add dialog has a Fetch after adding switch, on by default, that runs an ordinary fetch right after. The two stay separate steps on purpose: a typo in the URL or a credential the remote won't accept is then reported as a fetch that failed against a remote that was still added properly, rather than as an add that half-worked and left you guessing which half.

Credentials stored in a URL are left alone

Some remote URLs carry a password or a token in them. Plexus shows those URLs without it, and the Edit dialog leaves that field empty with the stripped URL as a hint. Leave it empty and the stored URL is kept exactly as it is, credential included; type a new one and it replaces the whole thing, so put the credential back in if you still need it there.

What removing costs, and what it doesn't

Removing a remote deletes your local copies of its branches and clears the upstream of every local branch that tracked one. The confirmation spells that out first, down to which branch copies go and how many locals lose their upstream. Your own branches and their commits stay put, and nothing at all changes on the server.

Two things are worth knowing before you rename or remove one. Remotes belong to the repository, not to a session: every session of a project works in a linked copy of the same checkout, so the change reaches all of them at once. And Plexus finds a project's pull requests through the remote called origin — so renaming or removing that one clears its record of which pull request belongs to which session, and the badges showing it. Nothing is lost on GitHub or Bitbucket: those links come back on the next refresh, worked out from wherever origin points now.

Right-click a changed file

Every other row in the git client has a right-click menu — branches, tags, stashes, worktrees, commits. Changed files did not, which made Discard hard to find: it only appeared in the panel header once you had already selected something, and the header is nowhere near the file you are looking at.

Changed files now have their own menu, in both the project Git client and a session's Git tab. It stages or unstages the file, copies its path or its name, and discards it. On a conflicted file it offers Take ours and Take theirs instead, with discard greyed out until the conflict is resolved.

The menu follows the same rule your file manager does. Right-click a file that is already part of a selection and the whole selection is what gets discarded — the entry says which, reading Discard 3 files… rather than Discard changes…. Right-click anywhere else and that one file becomes the selection first. Staging is the exception, and the labels make it obvious: it always acts on just the file you clicked.

Discard all changes

Stage all and Unstage all have always been one click. Discarding everything meant selecting every row by hand. With nothing selected, the header now offers Discard all.

Every tracked file goes back to its state at the last commit, and every new file is deleted from disk — including new files you have already staged, which have never been committed either. A switch in the confirmation turns that second part off if you would rather keep them, and the dialog says how many of each it found before you commit to anything. Empty folders left behind by deleted files go too, which the per-file discard never handled.

Files ignored by .gitignore are never touched, and there is no switch that changes that. Your node_modules, your build output and your local .env are not part of "your changes" — they never appear in the file list, so a confirmation could not honestly show you what it was about to delete. If you genuinely want that, git clean -xfd in the built-in terminal is one line and carries its own warning.

Discard all also refuses while a merge, rebase, cherry-pick or revert is in progress. Reverting the working tree underneath one of those does not cancel it — it strands it, leaving git convinced an operation is still running over files that no longer contain the resolution. Finish or abort it from the conflict banner first, and the button explains itself in the meantime.

Discard a single hunk

Diffs in the project Git client already let you stage one hunk at a time. Each hunk on the unstaged side now carries a Discard hunk button next to Stage hunk, for the case where one experiment in a file did not work out and the rest of it did.

It reverts only those lines, and only in the working tree. Anything you have already staged in the same file is left exactly as it was, so a file you were carefully splitting across two commits stays split.

To discard a hunk you have already staged, unstage it first and then discard it. That is one extra click and it is deliberate: once a file is both staged and further edited, "remove just the staged half of these lines" has no single correct answer, and guessing at one would quietly destroy the other half. Unstaging first merges the two into the hunk you can actually see, so you are confirming against the real result.

Discarding still cannot be undone and still never stashes anything on your behalf. Stash sits next to it for when you might want the work back.

Resolved comments stay on the file list

A file with comments used to carry one badge — a speech bubble and a count of its open comments. Resolve them all and the badge went away, which left a file you had just read and worked through looking exactly like one nobody had ever opened.

Each row now shows two badges: a speech bubble with the open comments, and a check with the resolved ones. Either appears only when it has something to count, so a file whose comments are all resolved still says so, and a file with no comments still shows nothing at all.

This was most confusing where Plexus resolves comments for you. Send N comments to agent resolves everything it sends, and so does each round of the review-and-fix cycle — so handing a whole review over used to blank the entire sidebar in one click. It now reads as a count of resolved comments per file: a record of what was addressed, on the files it was addressed on.

While the pull request conversation is shown, both badges count its threads too — open threads in the speech bubble, resolved ones in the check. Hide the conversation and they go back to counting only your own notes, so a badge never points at a comment the tab isn't showing you. (A pull request thread that no longer lines up with the diff still counts on its file — you'll find that one in the conversation rather than on a diff line.)

v0.16.1 — Git that authenticates itself, and a What's new window that shows up

2026-08-06T00:00:00Z

Fetch and push can now use the GitHub or Bitbucket account you connected in Plexus when your machine has no credentials of its own. The What's new window no longer sits out the update that introduced it, and a release now runs down the side of it rather than across the top.

Your connected provider now authenticates git too

Fetch, Pull and Push run the real git on your machine, so they have always used your own credentials — a credential helper, an SSH key, whatever git fetch would use in a terminal. On a machine that has none of those for an https remote, that was the end of it: the operation simply failed, even for people who had signed into GitHub or Bitbucket in Plexus.

That connection now counts. If your machine's own credentials can't authenticate an https remote on GitHub or Bitbucket, Plexus retries the operation once with the account you connected in Settings → Git providers — including background fetches, which cannot ask you for anything. Most people will simply notice that Fetch works now.

Your own credentials still go first, always. The connection is only ever tried after git's own attempt has failed, so a credential helper with wider access than your Plexus connection keeps being the one that authenticates, and nothing about a setup that already works changes. The token is offered only to the provider's own host, only for that one command — never written into your repository's config or its remote URL. ssh remotes are untouched.

And if the provider turns that connection down — the account can't reach the repository, the grant was revoked, your organization hasn't authorized it — Plexus rests it for a few minutes instead of doubling every fetch with an attempt it already knows will fail. Reconnecting the provider clears that immediately, so following the error's own advice never means waiting.

Git errors that say what to do

A git operation that couldn't authenticate used to report git's own words:

git command failed: fatal: could not read Password for 'https://you@bitbucket.org': terminal prompts disabled

Which reads like a Plexus fault, and isn't — "terminal prompts disabled" is Plexus deciding never to hang on a password box you can't see. That message now names the host that refused and what will fix it: connect the provider, sort out your credential helper, or switch the remote to ssh. If the credentials that were tried got refused — an expired app password, a revoked token — it says that instead, which is a different problem with a different fix.

The What's new window

Plexus shows a What's new window the first time you run a new version. Until now it stayed quiet unless it already had a record of what you had last been shown — which nobody had before the window itself existed, so the release that introduced it was the one release it could not announce. It now opens after an update, with the notes for the version you have just moved to.

A brand-new install still opens straight into Plexus. A first launch is not an update, and nobody's first minute with an app should be a wall of release notes.

The window is also wider, and the changes in a release are listed down the left-hand side rather than across the top, so you can see everything a release contains at a glance instead of scrolling a strip of tabs. A long entry scrolls on its own, while the title, the release you are reading and the buttons stay where they are.

v0.16.0 — Sessions on branches you already have, hooks that add up, and a What's new window

2026-08-05T00:00:00Z

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.

v0.15.0 — Side-by-side diffs, PR conversations, and steadier Windows sessions

2026-08-04T00:00:00Z

A big review release: diffs can now be read side by side, pull-request conversations live inside the Review tab, and several long-standing Windows rough edges are gone.

Side-by-side diffs

Every diff pane — session Review, the Git tab, and the project Git client — now has a Unified / Split switcher. Split lays the old and new sides next to each other and marks the words that actually changed within a line, so a rename or a reordered argument reads at a glance instead of as two near-identical rows.

Your choice is remembered globally and applies to all three panes at once. Review comments work the same in both layouts: an anchor still belongs to a line, not to a column.

Pull-request conversations

Once a session has a pull request, the provider's own review conversation is rendered in the Review tab beside your local notes — never merged into them. Works with both GitHub and Bitbucket.

For each thread you can Reply, Resolve, or hand the whole thread to the agent to act on. Comments that no longer point at any line in the current diff collect in a collapsible Pull request conversation strip rather than silently disappearing.

Search your repositories when adding a project

The repository picker's search box now actually filters. Type to search the repositories you can see on a connected provider, with a refresh control beside the box for a repository you have just created. When the list is capped, the footnote says so plainly instead of pretending it searched everything.

Worktrees that clean up after themselves

Deleting a session — or a whole project or workspace — now reliably removes the git worktree that went with it. Previously the .git/worktrees entry could outlive its directory, which left git holding the branch and refusing to reuse it.

The Git tab's refs panel gained a cleanup action for metadata stranded by older versions, and Plexus reclaims what it can at startup. When it deliberately keeps something — a branch you may still want, a worktree an agent is still using — it now says so rather than acting silently.

Windows: sessions that start, and stay started

Three separate wedges are fixed. Starting a session no longer hangs on a "Starting…" spinner that only a restart could clear. Resuming a session resumes the actual conversation instead of opening a fresh one. And the review-and-fix cycle no longer freezes the window after its first round.

If Windows has been asking "Are you sure you want to uninstall this product?" every time Plexus updates, it can now find the older installation responsible and offer to remove it — see Settings → About.

Plexus changelog

v1.3.1 — Bitbucket's new SSH address

Bitbucket's new SSH address

Updating your projects

v1.3.0 — The Stack map

The Stack map

Moving between layers

Merging a stack

A state on every row

No more Retry

Stack on…

Stacks on GitHub

Bitbucket's merge queue

Syncing around your work

Merge in order

Stacks settings

Stacks & ordered merging

v1.2.1 — Status that keeps up with Claude Code

Workflows keep the ring lit until they finish

The dot follows Esc and approved prompts

Only prompts that need you turn the dot amber

One Plexus per data folder

v1.2.0 — Plnnrly in the Toolchain

Plnnrly in the Toolchain

Connect your organization

A Plnnrly tab

Start a session from a work item

Part of your issue tracker in Plexus

v1.1.0 — New windows and split view

Open in new window

It moves, it doesn't copy

Closing windows

Good to know

Split view

In the sidebar

Working in panes

Good to know

Resolve landing conflicts with AI

Coming back from a payment

Diffs beside the file list

Selecting several files

Drag and drop on Windows

v1.0.1 — A Git tab that matches your history

A graph that matches your history

Checking out a remote branch

Stashes and worktrees on the graph

Show or hide branches

Edit, squash and reorder commits

Undo and redo

Stage single lines

Compare, history and blame

Pull requests, submodules and LFS

A reused branch name no longer picks up an old pull request

v1.0.0 — Sign in to Plexus, and bring your team

Your Plexus account

Organizations

Inviting people to an organization

Roles you define yourself

An admin no longer buys plans

Paid plans

Seats

Invoices and payment details

If a payment fails

The account menu in the app bar

Signed-in devices

A calmer Settings

One organization at a time

Your settings follow you

You see everything before it leaves

If your account already holds settings from another machine

Version history, and putting a version back

Projects that are not on this machine

Two settings that now stay on the machine you set them on

The prompt library

Where they live, and what that means

Running one

Starting from a session that already worked

Before anything leaves your machine

What a plan does and does not gate here

Workspaces your organization shares