[{"data":1,"prerenderedAt":476},["ShallowReactive",2],{"features-index":3,"site-nav-marketing":446,"compare-index-mini":467},[4,81,143,224,302,383],{"path":5,"title":6,"navTitle":7,"description":8,"hero":9,"sections":12},"\u002Ffeatures\u002Fsessions-and-status","Parallel Claude Code sessions with live status","Sessions & status","Run many Claude Code agents at once, each in its own git worktree, and see which one needs you: working, needs you, delegating or idle, across every repo.",{"eyebrow":7,"headline":10,"lead":11},"Run five agents. Know which one needs you.","Every session is a Claude Code agent in its own git worktree. A dot on each row says whether it is working, waiting for you or idle, and the dashboard shows every session in one table.",[13,26,38,49,60,70],{"id":14,"heading":15,"body":16,"state":17,"docsPath":18,"sim":19},"tree","One tree for every repository","Plexus arranges your work as workspace, project, session. A workspace groups related repositories, a project is one git repository, and a session is one named Claude Code agent on its own branch. Expand a workspace in the sidebar to see its projects, and a project to see its sessions. Settings and hooks cascade down the same tree, so you set a default once for a group of similar repositories.","neutral","\u002Fdocs\u002Fconcepts",{"view":20,"anchors":21,"note":25},"sessions",[22,14,23,24],"sidebar","project:storefront","row:checkout-flow","Crop to the sidebar ({x:0,y:88,w:318,h:420}) on narrow screens.",{"id":27,"heading":28,"body":29,"state":30,"docsPath":31,"sim":32},"states","Working, Needs you, Idle","A coloured dot sits on every session row. Green and pulsing means the agent is mid-turn. Amber means it is your turn: the turn ended, or the agent stopped on a question, a permission prompt or a plan waiting for approval. Grey means nothing is in flight. The dot follows Claude Code's own lifecycle events, reported back over a private loopback channel, so it reflects what the agent is actually doing. Only the session's own agent moves it.","needs-you","\u002Fdocs\u002Fstatus",{"view":20,"start":33,"anchors":34,"note":37},6,[24,35,36],"perm-prompt","needs-pill","At t=6 the hero session stops on a permission prompt and the pill reads 2 need you.",{"id":39,"heading":40,"body":41,"state":39,"docsPath":42,"sim":43},"delegating","Background work gets its own signal","When the agent hands work off and carries on without waiting, to background subagents, a workflow, a teammate or a cloud session, a blue ring appears around the dot. The ring combines with all three colours, and a row whose main agent is free while delegated work runs reads Delegating. A workflow keeps the ring lit for its whole run and counts as one item. Hover the dot for what is running, including how many of a workflow's agents are live and any background shell commands, which are listed but do not light the ring. Subagents the agent is waiting on count as ordinary work, so they show as a green dot with no ring.","\u002Fdocs\u002Fstatus#background-work",{"view":20,"start":44,"anchors":45,"note":48},0,[46,47],"row:conpty-teardown","row:settings-service","conpty-teardown is Delegating at t=0; settings-service launches a subagent at t=4.",{"id":50,"heading":51,"body":52,"state":53,"docsPath":54,"sim":55},"dashboard","Every session in one table","Press ⌘0 for the global dashboard: one live table of every session across all workspaces, with its state, project, branch, workspace and pull request badge. The header counts sessions working, waiting and idle, plus open and merged pull requests. The default sort puts sessions that need you first. Click a row to jump to that session. Each project and workspace has the same table, scoped to itself.","working","\u002Fdocs\u002Fdashboard",{"view":50,"anchors":56},[57,58,59],"dash-chips","dash-list","dash-row:checkout-flow",{"id":61,"heading":62,"body":63,"state":30,"docsPath":64,"sim":65},"notifications","Told when it is your turn","When a session starts waiting, Plexus sends a native notification that names the session and what it needs, even with the window minimised. Notifications are on by default. An optional two-note chime, or a sound file of your own, is off by default. While background subagents or a workflow are still running, Plexus waits and tells you once, when that work has finished. Notices that need nothing from you, such as a background agent finishing, do not count as waiting.","\u002Fdocs\u002Fstatus#getting-notified",{"view":20,"start":66,"anchors":67,"note":69},17,[36,68],"row:hook-bridge-retry","The simulation has no OS notification. Show the pill and the row that just turned amber instead.",{"id":71,"heading":72,"body":73,"state":17,"docsPath":74,"sim":75},"lifecycle","Stop, resume, pick up where you left off","Stopping a session ends the agent process and keeps the worktree, the branch and the conversation. Resume restarts the session and reattaches the same conversation. Sessions survive quitting Plexus: running agents come back as stopped, and the next Resume reattaches them. Archive hides a session without deleting anything, and ⌘K finds any session by name, branch, project or workspace.","\u002Fdocs\u002Fsessions#lifecycle",{"view":20,"anchors":76,"note":80},[77,78,79],"row:changelog-popup","search","context","changelog-popup is a stopped session with a merged PR.",{"path":82,"title":83,"navTitle":84,"description":85,"hero":86,"sections":89},"\u002Ffeatures\u002Freview","Review AI agent changes like a pull request","Review","A PR-style diff of each Claude Code session's worktree, inline comments the agent acts on, AI review, a review-and-fix cycle and the PR conversation.",{"eyebrow":84,"headline":87,"lead":88},"Review the agent's work before anyone else sees it.","The Review tab diffs a session's worktree against its base branch, like a pull request. Comment on lines and send the comments to the agent, run an AI review, or let a review-and-fix cycle run on its own.",[90,100,110,117,125,136],{"id":91,"heading":92,"body":93,"state":17,"docsPath":94,"sim":95},"diff","A pull request view of the worktree","The Review tab compares the session's worktree with its base, using the remote-tracking branch when there is one, so it matches what the pull request will show. Untracked files are included. Switch between unified and split views; in both, the words that changed inside a line are marked. The file list shows each file's change type, line counts and how many comments are open or resolved on it.","\u002Fdocs\u002Freview#the-diff-view",{"view":20,"tab":96,"anchors":97},"review",[98,99,91],"review-bar","review-files",{"id":101,"heading":102,"body":103,"state":53,"docsPath":104,"sim":105},"comments","Comments the agent reads","Hover a line, write a note and add it. Notes stay on your machine. When you are done, Send N comments to agent turns every open note into one prompt and writes it to the running agent, which picks it up on its next turn. Sent notes are marked resolved, so the file list keeps a record of what you handed over.","\u002Fdocs\u002Freview#inline-comments",{"view":20,"tab":96,"anchors":106},[107,108,109],"diff-thread","thread-send","send-review-comments",{"id":111,"heading":112,"body":113,"state":39,"docsPath":114,"sim":115},"ai-review","AI review on demand","Run AI review hands the diff to a separate, headless Claude, which looks for bugs, security issues and risky changes and leaves its findings as inline comments. You write the review instructions, globally or per workspace or project. Plexus supplies the output format, so the comments land on the right lines whatever your instructions say.","\u002Fdocs\u002Freview#ai-review",{"view":20,"tab":96,"anchors":116},[111],{"id":118,"heading":119,"body":120,"state":39,"docsPath":121,"sim":122},"cycle","Review and fix, unattended","The review-and-fix cycle runs an AI review, starts a separate headless agent to apply the fixes, waits for it, and reviews again. It stops when a review finds nothing or when it reaches the round limit, 10 by default. It asks for consent once per repository, refuses to run on the project's main checkout, and never pushes. Watch agent opens a live, read-only view of the fix agent while it works.","\u002Fdocs\u002Freview#review-and-fix-cycle",{"view":20,"tab":96,"anchors":123},[124],"review-cycle",{"id":126,"heading":127,"body":128,"state":17,"docsPath":129,"sim":130},"pr-conversation","The pull request conversation, under the diff","Once a session has a pull request on GitHub or Bitbucket, its review threads appear under the lines they are about. Comments, verdicts and outdated threads sit in a section above the diff. Reply, resolve, start a new thread, or publish one of your local notes to the pull request after a confirmation that names the repository. Send PR comments to agent hands the threads to the agent. Plexus fetches the conversation when you open the tab, focus the window or press Refresh. There is no background polling.","\u002Fdocs\u002Freview#pull-request-comments",{"view":20,"tab":96,"selected":131,"anchors":132,"note":135},"pricing-page-copy",[126,133,134],"comment-pr","send-comments","pricing-page-copy has an open PR with two PR comments.",{"id":137,"heading":138,"body":139,"state":17,"docsPath":140,"sim":141},"other-branches","Review a colleague's branch as well","Start a session on an existing branch, such as a colleague's branch or the head of a pull request you were asked to review, and set Compare with to the branch it will merge into. The Review tab then shows their work with the same diff, notes, AI review and pull request conversation. The session has its own worktree, so your main checkout and your other sessions stay where they are.","\u002Fdocs\u002Freview#reviewing-someone-elses-branch",{"view":20,"tab":96,"anchors":142},[79,98],{"path":144,"title":145,"navTitle":146,"description":147,"hero":148,"sections":151},"\u002Ffeatures\u002Fworktrees-and-hooks","A git worktree per agent, set up by your own hooks","Worktrees & hooks","Every Claude Code session gets its own git worktree, your .env files, a block of dev-server ports, and your Create, Run and Teardown hooks at three levels.",{"eyebrow":146,"headline":149,"lead":150},"Every session gets its own checkout, ready to run.","Plexus creates a git worktree for each session, copies in the env files git leaves out, gives the session its own ports and runs your setup scripts. You write each script once, at the level where it belongs.",[152,163,174,182,200,214],{"id":153,"heading":154,"body":155,"state":53,"docsPath":156,"sim":157},"worktree","One worktree per session","Starting a session creates a git worktree for it, by default at \u003Cproject>\u002Fworktrees\u002F\u003Csession-name>, on a new plexus\u002F\u003Cname> branch off the base you picked or on an existing branch. Plexus adds the folder to .gitignore so worktrees never show up as untracked changes. Removing a session removes the folder and git's own record of it. Plexus never deletes a branch it did not create without asking you first.","\u002Fdocs\u002Fworktrees",{"view":158,"project":159,"anchors":160},"projectGit","storefront",[161,162],"git-worktrees","git-ref:plexus\u002Fcheckout-flow",{"id":164,"heading":165,"body":166,"state":17,"docsPath":167,"sim":168},"env-files","The files git leaves out","A new worktree contains only tracked files, so .env and .env.local are missing and a dev server that needs them would fail. Plexus copies a list of files and folders into every new worktree, .env and .env.local by default, whether git tracks them or not. Paths must stay inside the repository: absolute paths and .. are refused, and symlinks are skipped.","\u002Fdocs\u002Fworktrees#copying-paths-into-worktrees",{"view":20,"tab":169,"anchors":170,"note":173},"hooks",[171,172],"hook-output","hook-runs","The Hook output tab lists the copy-paths run first.",{"id":175,"heading":176,"body":177,"state":17,"docsPath":178,"sim":179},"ports","Ten ports for each session","Two sessions of one repository both want port 3000. Plexus reserves a block of 10 free localhost ports for each session, from 20000–31999 by default, and exposes them as PLEXUS_PORT, PLEXUS_PORT_1 to PLEXUS_PORT_9 and PORT. The agent, the session's terminal and every hook get them. A session keeps its block when it resumes. Open localhost in the session's tab strip opens your browser on that port.","\u002Fdocs\u002Fworktrees#dev-server-ports",{"view":20,"anchors":180,"note":181},[171],"The app-sim has no anchor for the Open localhost button, which sits beside Hook output in the tab strip. See the report.",{"id":183,"heading":184,"body":185,"state":53,"docsPath":186,"sim":187},"events","Create, Run, Teardown","A hook is a shell script attached to one of three events. Create runs when the worktree is made: install dependencies, write local config. Run fires every time the agent starts or resumes: start a dev server or a watcher. Teardown runs when a session is removed: stop containers, clean up. The Hook output tab keeps each hook's output and exit status, and a hook that runs too long is stopped after the timeout, 600 seconds by default.","\u002Fdocs\u002Fhooks#the-three-events",{"view":169,"hooksScope":188,"hooksEvent":189,"anchors":190,"crop":195},"project","create",[191,192,193,194],"hooks-events","hook:create","hook:run","hook:teardown",{"x":196,"y":197,"w":198,"h":199},208,48,1232,852,{"id":201,"heading":202,"body":203,"state":17,"docsPath":204,"sim":205},"levels","Three levels, one resolved plan","Hooks are defined globally, per workspace or per project, and resolved from global down to project. Each workspace or project picks how its hooks join the ones it inherits: Override, Before, After or Parallel. The Resolved plan preview shows exactly what will run and in which order, with a badge saying where each hook came from, so you can check inheritance before you start a session.","\u002Fdocs\u002Fhooks#resolution-and-execution-order",{"view":169,"hooksScope":188,"anchors":206,"crop":213},[207,208,209,210,211,212],"hooks-combine","hooks-levels","plan:global","plan:workspace","plan:project","plan:builtin",{"x":196,"y":197,"w":198,"h":199},{"id":215,"heading":216,"body":217,"state":30,"docsPath":218,"sim":219},"repo-hooks","Hooks that ship with the repository","Commit hooks to .plexus\u002Fhooks.json and everyone who adds the repository gets them. They run alongside the hooks you set up in Plexus, and a setting decides which run first. Repository hooks run on your machine with your permissions, so Run scripts committed to the repository lets you switch them off for repositories you do not trust. Plexus removes Anthropic credentials from every hook's environment.","\u002Fdocs\u002Fhooks#repo-committed-hooks",{"view":169,"hooksScope":188,"anchors":220,"crop":223},[221,222],"hooks-defined","hook-row",{"x":196,"y":197,"w":198,"h":199},{"path":225,"title":226,"navTitle":227,"description":228,"hero":229,"sections":232},"\u002Ffeatures\u002Fgit-and-issues","Git client, PRs and GitHub issues for AI agents","Git & issues","A git client per Claude Code session and per repo, GitHub and Bitbucket pull requests with CI status, and GitHub Issues and Projects boards in one window.",{"eyebrow":227,"headline":230,"lead":231},"Git, pull requests and issues, next to the agents.","A git client for each session and one for the repository, pull requests on GitHub and Bitbucket with CI status, and your GitHub issues and project boards in the same window. The git client and pull requests are free. The issue list and boards need a paid plan.",[233,241,253,264,275,286,297],{"id":234,"heading":235,"body":236,"state":53,"docsPath":237,"sim":238},"session-git","A git client for every session","The session's Git tab shows the branch's commits with a divider at the merge-base, a staging panel with discard, stash and an AI-drafted commit message, and Push. Push is never a force-push. Rebase onto the base, merge the base in, or squash the branch with shortcuts that take two modifier keys, because they rewrite history.","\u002Fdocs\u002Fgit",{"view":20,"tab":239,"anchors":240},"git",[234],{"id":242,"heading":243,"body":244,"state":17,"docsPath":245,"sim":246},"project-git","The whole repository as a graph","Click a project to open its Git client on the main checkout. The commit graph takes the whole tab and draws every branch as a coloured lane, with author avatars on the commits and branch and tag labels at the side. A branch a session is working on shows that session's state at its tip, Working or Needs you, and a commit an agent makes slides in at the top, highlighted until you look at it. Click a commit and its details slide in as a layer over the graph. The rail on the left opens the references: local branches, each remote, worktrees, stashes, tags and pull requests. Drag one branch label onto another to merge, rebase, fast-forward, push or open a pull request. Conflicts from a merge, rebase, pull or stash pop are resolved in the same tab.","\u002Fdocs\u002Fproject-git",{"view":158,"project":159,"anchors":247,"note":252},[248,249,162,250,251],"git-graph","git-refs","git-session:checkout-flow","git-merge","Suggested crop: {x:318,y:130,w:730,h:520}.",{"id":254,"heading":255,"body":256,"state":17,"docsPath":257,"sim":258},"sync","Pull, push and background fetch","The toolbar has the branch switcher, Undo and Redo, Pull, Push and stash, and shows when the project was last fetched. Plexus fetches in the background, about once a minute for the project you are looking at and every ten minutes for the rest. A fetch only downloads: it never merges, checks out or deletes anything, and it pauses while the window is hidden.","\u002Fdocs\u002Fproject-git#automatic-fetching",{"view":158,"project":159,"anchors":259},[260,261,262,263],"git-toolbar","git-branch","git-pull","git-push",{"id":265,"heading":266,"body":267,"state":268,"docsPath":269,"sim":270},"pull-requests","Pull requests on GitHub and Bitbucket","Create PR on a session pushes the branch and opens the pull request. If the worktree has uncommitted changes, Plexus offers to commit them first. An AI-drafted title and description are optional. The branch icon on the session turns green when the pull request is open and purple when it is merged, and its tooltip shows CI status. Connecting GitHub or Bitbucket is a one-click sign-in. You do not need the gh CLI, and the token is kept in your OS keychain.","merged","\u002Fdocs\u002Fpull-requests",{"view":20,"anchors":271,"note":274},[272,273,77],"create-pr","row:pricing-page-copy","The hero opens its PR around t=19 (pr event); changelog-popup shows a merged PR.",{"id":276,"heading":277,"body":278,"state":30,"docsPath":279,"sim":280},"issues","GitHub issues, inside the project","Attach a GitHub repository to a project and its Issues tab lists the open issues with GitHub's own filters. Open an issue to edit the title, text, labels, assignees and milestone, or to comment. Start session turns an issue into a session on a branch named after it, sends the issue to the agent as the first prompt, and starts the pull request description with Closes #123. Everything goes from your machine to GitHub with your own account. The tab needs a paid plan. Attaching the repository and the issue link on a session are free.","\u002Fdocs\u002Fissues",{"view":276,"project":159,"anchors":281,"note":285},[282,283,284],"issues-toolbar","issues-list","issue-start","For the detail view use issue: 142 and anchors issue-detail, issue-start-detail.",{"id":287,"heading":288,"body":289,"state":17,"docsPath":290,"sim":291},"boards","GitHub Projects boards","Attach a GitHub project and its views open in a Board tab: board views as columns, table and roadmap views as tables. Drag a card to another column and the field changes on GitHub. Click a card to open the issue behind it, or start a session from it. The Board tab needs the same paid plan as the Issues tab.","\u002Fdocs\u002Fboards",{"view":292,"project":159,"anchors":293,"note":296},"board",[294,292,295],"board-views","board-column:in-progress","Suggested crop: {x:318,y:130,w:1122,h:560}.",{"id":298,"heading":299,"body":300,"state":17,"docsPath":301},"plnnrly","Plnnrly work items, boards and sprints","Connect a Plnnrly organization in Settings → Integrations by signing in through your browser, and attach one of its projects. Its tab has Plnnrly's own views: Backlog, Active sprint and All work, or Board and All work for a project without sprints. Open a work item to edit it and comment. The status menu and the board offer only the moves the project's workflow allows. Start and complete sprints, and start a session from any work item. Everything goes from your machine to your Plnnrly organization. The tab needs the same paid plan as the Issues tab.","\u002Fdocs\u002Fplnnrly",{"path":303,"title":304,"navTitle":305,"description":306,"hero":307,"sections":311},"\u002Ffeatures\u002Fstacks","Stacked pull requests and ordered merging for Claude Code sessions","Stacks","Stack Claude Code sessions on each other's branches. Plexus keeps every branch synced as the agents work, shows the stack as a map, and merges it in order, as a GitHub stack or through a merge queue.",{"eyebrow":308,"headline":309,"lead":310},"Stacks & ordered merging","Split the change. Merge it in order.","Start a session on top of another session's branch, and the next one on top of that. Each piece gets its own worktree, its own agent and its own pull request. Plexus keeps every branch synced while the agents work, draws the stack as a map beside the terminal, and merges it with one click: as one GitHub stack, through GitHub's or Bitbucket's merge queue, or one pull request after another.",[312,324,334,343,351,362,369,376],{"id":313,"heading":314,"body":315,"state":53,"docsPath":316,"sim":317},"stack","One change, in pieces that can be reviewed","Choose New stacked session… on a session, and the new session starts from that session's branch. Already have a session that belongs on top? Stack on… moves it there. Build the API in one session, the UI on top of it, the end-to-end tests on top of that. The stack nests in the sidebar under its bottom session, and the Stack pill in the context bar opens the Stack panel beside the terminal: the stack as a map, top to bottom, with your main branch underneath. Each pull request targets the branch below it, so it shows only its own changes. Alt+↑ and Alt+↓ move between the layers.","\u002Fdocs\u002Fstacks#stack-sessions",{"view":20,"stacks":318,"selected":319,"anchors":320},true,"guest-checkout-ui",[321,322,323],"stack:checkout-flow","stack-pill","stack-panel",{"id":254,"heading":325,"body":326,"state":53,"docsPath":327,"sim":328},"Synced while the agents work","When the session underneath gets new commits, the sessions above it read Behind. Plexus replays each branch's own commits onto its new parent, from the bottom of the stack up, as soon as that session's agent is idle, and the rows read Syncing until they go quiet again. Uncommitted work doesn't stop it: Plexus syncs around it and leaves those files as they are. A branch that was already pushed is pushed again with a lease, so the push fails rather than overwrite a commit someone else pushed in the meantime.","\u002Fdocs\u002Fstacks#sync",{"view":20,"stacks":318,"start":329,"anchors":330,"note":333},16,[331,332],"chip:guest-checkout-ui","stack-layer:guest-checkout-ui","Both stacked sessions read Behind from about t=15.5, when checkout-flow commits, and Syncing from 20.3 to 21.7, once guest-checkout-ui's own turn ends.",{"id":335,"heading":336,"body":337,"state":30,"docsPath":338,"sim":339},"conflicts","A conflict goes to the agent, not into your worktree","Plexus never leaves a worktree half rebased. When a sync conflicts it puts the branch back exactly as it was, then hands that session's agent the exact command and the files that conflicted, as soon as the agent is idle. The row reads Resolving while it works; the agent doesn't push, and Plexus pushes the result. When uncommitted edits overlap the sync, the agent is asked to commit them first. Prefer to decide each time? Set When a sync conflicts to Ask me first, and the row reads Needs you: conflict with Resolve with agent. Stop leaves it to you.","\u002Fdocs\u002Fstacks#when-a-sync-conflicts",{"view":340,"anchors":341,"note":342},null,[],"The demo has no conflicting sync.",{"id":265,"heading":344,"body":345,"state":53,"docsPath":346,"sim":347},"On GitHub, the stack is a GitHub stack","Create PR on a stacked session targets its parent's branch, and Open pull requests for the whole stack opens one for every session, from the bottom up. On GitHub, Plexus then groups them into one of GitHub's own stacked pull requests, so reviewers see the stack on GitHub and GitHub can merge it in one go. The Stack panel says so in its header, and each layer shows its pull request's checks and review. On Bitbucket, which has no stacks of its own, each description ends with a list of the stack instead. When the bottom pull request merges, the sessions above it move down a level, their pull requests follow, and each branch is synced so it carries only its own commits, after a squash merge too.","\u002Fdocs\u002Fstacks#pull-requests-in-a-stack",{"view":20,"stacks":348,"anchors":349},"merge",[350,323],"stack-native",{"id":348,"heading":352,"body":353,"state":268,"docsPath":354,"sim":355},"Merge up to here, with one click","The panel's merge button merges the layer you're on and everything under it: Merge 2 on the second layer, Merge stack on the top. It turns on once every one of them is ready, and until then says what it's waiting for. One short confirmation says exactly what will happen: which pull requests merge, whether GitHub merges them together as one stack, and which session moves onto main next. While it runs, a progress strip in the context bar keeps it in view from every session of the project, and merged layers stay in the map, in purple. Then the sessions above move onto main and sync.","\u002Fdocs\u002Fstacks#merging",{"view":20,"stacks":348,"start":356,"anchors":357,"note":361},2,[358,359,360],"stack-merge","stack-confirm","progress-strip","The confirmation opens at t=3; GitHub merges #128 and #129 from 6 to 11; the strip goes and the toast shows at 14.",{"id":363,"heading":364,"body":365,"state":268,"docsPath":366,"sim":367},"merge-in-order","Unrelated pull requests, merged one after another","Two pull requests that touch the same files merge fine one at a time, and conflict once the first is in. Add each to Merge in order from its ⋯ menu, put them in the order you want, and click Merge 3. Plexus merges the first, syncs the next onto main when it conflicts or the branch requires it, waits for its checks, merges it, and so on. Merging stops on anything that needs you, a failing check or a conflict, and carries on by itself once it's fixed. There is no Retry button to find.","\u002Fdocs\u002Fstacks#merge-in-order",{"view":340,"anchors":368},[],{"id":370,"heading":371,"body":372,"state":30,"docsPath":373,"sim":374},"queues","GitHub's merge queue, and Bitbucket's","When a branch requires a merge queue, Plexus goes through it and never around it. On GitHub it adds the pull request to the queue for you and waits for GitHub to merge it. Bitbucket doesn't let other apps add to its queue, so the confirmation says so up front, and the row reads Needs you: add to merge queue with Open on Bitbucket. Add it there, and Plexus sees it queued, waits for the merge and carries on.","\u002Fdocs\u002Fstacks#merge-queues",{"view":340,"anchors":375},[],{"id":377,"heading":378,"body":379,"state":17,"docsPath":380,"sim":381},"plan","What a plan adds, and what stays free","Syncing, GitHub stacks and merging need a paid plan, individual or a seat in an organization. Some of it stays free: every state chip, the Stack pill and the Stack panel's map, Unstack, Remove from Merge in order, the actions that only open something (checks, a pull request, the terminal), basing a session on another session's branch, and opening a pull request against any branch. So does the protection that keeps a branch alive while another session is based on it. Everything runs between your machine and your own GitHub or Bitbucket account.","\u002Fdocs\u002Fstacks#what-a-plan-gates",{"view":340,"anchors":382},[],{"path":384,"title":385,"navTitle":386,"description":387,"hero":388,"sections":392},"\u002Ffeatures\u002Fteams","Teams: organizations, managed settings, prompts","Teams","Organizations, shared workspaces, managed settings, a shared prompt library and sync for teams on Claude Code. Seats are paid; the core app stays free.",{"eyebrow":389,"headline":390,"lead":391},"Teams & organizations","Set it up once for the whole team.","Organizations add shared workspaces, managed settings and a shared prompt library to the free app. They come with seats on a paid plan. Agents, code and sessions still run on each developer's own machine.",[393,401,410,423,431,438],{"id":394,"heading":395,"body":396,"state":17,"docsPath":397,"sim":398},"organizations","Organizations and roles","An organization is a named account with members, roles and invitations, and creating one is free. Invite people by email; an invitation is valid for 14 days. Every organization starts with five built-in roles. Copy one to make your own, for example Admin with billing rights. The account service checks what someone may do at the moment they do it, rather than going by the role's name.","\u002Fdocs\u002Froles",{"view":340,"anchors":399,"note":400},[],"No app-sim view shows Settings → Organizations. Use a static panel, or leave this section without an illustration.",{"id":402,"heading":403,"body":404,"state":53,"docsPath":405,"sim":406},"shared-workspaces","Workspaces that arrive ready","An organization workspace is set up once, with a name, a description and its repositories attached, and appears in the sidebar of every member with a seat. Each workspace is open, request-to-join or invite-only. Joining adds rows to your sidebar and clones nothing until you ask. Leave is never refused, and leaving deletes nothing: the workspace becomes an ordinary workspace of your own.","\u002Fdocs\u002Fshared-workspaces",{"view":20,"anchors":407,"note":409},[408,14],"workspace","The demo has no organization badge on the workspace. Point at the workspace switcher and the tree.",{"id":411,"heading":412,"body":413,"state":30,"docsPath":414,"sim":415},"managed-settings","Settings the organization manages","An organization can publish a setting at one of three levels. Recommended sets the value once on each member's device, and members can change it. Enforced applies everywhere and is locked, and the setting names the organization that set it. Evaluate changes nothing and reports how many devices would change. Your own value is kept under an enforced one and comes back when the organization stops managing it. Settings that describe your machine, and anything in your keychain, can never be managed.","\u002Fdocs\u002Fmanaged-settings",{"view":169,"hooksScope":416,"anchors":417,"crop":420,"note":422},"global",[418,419],"settings","hooks-nav",{"x":44,"y":197,"w":421,"h":199},1440,"The app-sim Settings screen has no managed-setting badge or lock. Use it only as context.",{"id":424,"heading":425,"body":426,"state":39,"docsPath":427,"sim":428},"org-prompts","A shared prompt library","Prompt templates an organization publishes appear in every seat holder's template list next to their own, with a badge naming the organization. Each template is a list of numbered revisions, and proposing a revision and publishing it are separate permissions. Members always get the current revision. An organization prompt may not start a line with ! or \u002F, or attach a file with @path, and Plexus strips those on your machine as it types the prompt.","\u002Fdocs\u002Forg-prompts",{"view":340,"anchors":429,"note":430},[],"No app-sim view shows the template list. Leave this section without an illustration or use a static panel.",{"id":254,"heading":432,"body":433,"state":17,"docsPath":434,"sim":435},"Your setup on every machine","Cross-device sync carries your settings, workspaces and projects, including per-repository overrides such as a review prompt, to every machine you sign in on. It is off on every machine until you switch it on there, and it shows a list of everything that would leave the computer before anything does. Sessions, worktrees, transcripts and hook scripts are never synced. A seat includes sync on the seat holder's own machines, and the organization sees nothing of what they sync.","\u002Fdocs\u002Fsync",{"view":340,"anchors":436,"note":437},[],"No app-sim view for Settings → Sync.",{"id":439,"heading":440,"body":441,"state":268,"docsPath":442,"sim":443},"seats","Seats, and what stays free","An organization plan is billed monthly, per seat. A seat carries shared workspaces, managed settings, organization prompts and sync. A member without a seat is still a full member, and sessions, worktrees, review, hooks and pull requests work exactly the same for them. Setting the seat count to zero is allowed. When a plan lapses nothing is deleted: shared workspaces stay on each machine and stop updating, and enforced settings keep their last value.","\u002Fdocs\u002Fbilling#seats",{"view":340,"anchors":444,"note":445},[],"Pair with the live plans from the pricing API rather than the app-sim.",{"features":447,"compare":454},[448,449,450,451,452,453],{"label":7,"to":5},{"label":84,"to":82},{"label":146,"to":144},{"label":227,"to":225},{"label":305,"to":303},{"label":386,"to":384},[455,458,461,464],{"label":456,"to":457},"vs Claude Code","\u002Fcompare\u002Fclaude-code",{"label":459,"to":460},"vs Claude Squad and Nimbalyst","\u002Fcompare\u002Fclaude-squad-and-nimbalyst",{"label":462,"to":463},"vs Conductor","\u002Fcompare\u002Fconductor",{"label":465,"to":466},"vs Cursor","\u002Fcompare\u002Fcursor",[468,470,472,474],{"path":457,"competitor":469},"Claude Code",{"path":460,"competitor":471},"Claude Squad and Nimbalyst",{"path":463,"competitor":473},"Conductor",{"path":466,"competitor":475},"Cursor",1792695505283]