[{"data":1,"prerenderedAt":218},["ShallowReactive",2],{"site-nav-marketing":3,"feature-stacks":36,"features-all-nav":201},{"features":4,"compare":23},[5,8,11,14,17,20],{"label":6,"to":7},"Sessions & status","\u002Ffeatures\u002Fsessions-and-status",{"label":9,"to":10},"Review","\u002Ffeatures\u002Freview",{"label":12,"to":13},"Worktrees & hooks","\u002Ffeatures\u002Fworktrees-and-hooks",{"label":15,"to":16},"Git & issues","\u002Ffeatures\u002Fgit-and-issues",{"label":18,"to":19},"Stacks","\u002Ffeatures\u002Fstacks",{"label":21,"to":22},"Teams","\u002Ffeatures\u002Fteams",[24,27,30,33],{"label":25,"to":26},"vs Claude Code","\u002Fcompare\u002Fclaude-code",{"label":28,"to":29},"vs Claude Squad and Nimbalyst","\u002Fcompare\u002Fclaude-squad-and-nimbalyst",{"label":31,"to":32},"vs Conductor","\u002Fcompare\u002Fconductor",{"label":34,"to":35},"vs Cursor","\u002Fcompare\u002Fcursor",{"id":37,"title":38,"body":39,"description":92,"draft":93,"extension":94,"faq":95,"hero":114,"meta":117,"navTitle":18,"navigation":118,"order":119,"path":19,"sections":120,"seo":197,"slug":198,"stem":199,"__hash__":200},"features\u002Ffeatures\u002Fstacks.md","Stacked pull requests and ordered merging for Claude Code sessions",{"type":40,"value":41,"toc":87},"minimark",[42,47],[43,44,46],"h2",{"id":45},"read-more","Read more",[48,49,50,59,66,73,80],"ul",{},[51,52,53,58],"li",{},[54,55,57],"a",{"href":56},"\u002Fdocs\u002Fstacks","Stacks & ordered merging",": stacks, syncing, the Stack panel, merging, merge queues and every setting",[51,60,61,65],{},[54,62,64],{"href":63},"\u002Fdocs\u002Fpull-requests","Pull requests",": opening and tracking a single pull request",[51,67,68,72],{},[54,69,71],{"href":70},"\u002Fdocs\u002Fgit","Git workflow",": Rebase onto… and the rebase badge for a single session",[51,74,75,79],{},[54,76,78],{"href":77},"\u002Fdocs\u002Fdashboard","Dashboard",": the state of every session, stacked or not",[51,81,82,86],{},[54,83,85],{"href":84},"\u002Fdocs\u002Fbilling","Plans, seats and billing",": what a plan unlocks",{"title":88,"searchDepth":89,"depth":89,"links":90},"",2,[91],{"id":45,"depth":89,"text":46},"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.",false,"md",[96,99,102,105,108,111],{"question":97,"answer":98},"Does Plexus force-push my branches?","Only a stacked branch it has just synced, and only when that branch was already pushed. That push carries a lease on the commit Plexus last saw on the remote, so if anyone else pushed in the meantime git refuses it. Turn off Push after syncing to push yourself. The session Git tab's Push is never a force-push.",{"question":100,"answer":101},"What happens to the stack when the bottom pull request is squash-merged?","The session above it is re-attached to the merged session's base, usually your main branch, its pull request is retargeted, and its branch is synced from the commit it was last cut from. Only its own commits are replayed, so the parent's commits, which reached main under new ids, do not appear twice.",{"question":103,"answer":104},"Does it work with GitHub's stacked pull requests and Bitbucket's merge queue?","Yes, both. With Create stacks on GitHub on, which is the default, a stack's pull requests become one GitHub stack, and merging it from Plexus lets GitHub merge it in one go. GitHub's merge queue is supported too: Plexus adds the pull request to it. Bitbucket's merge queue gives other apps no way to add to it, so Plexus asks you to, with Open on Bitbucket, and carries on once Bitbucket reports it queued. It never merges past a required queue.",{"question":106,"answer":107},"Can I stop Plexus from syncing on its own?","Yes. Set Sync stacked sessions to Only mark them, and the rows read Behind until you choose Sync now in the session's ⋯ menu. Off stops checking altogether. The settings live in Settings → Git ▸ Stacks, globally or per workspace or project.",{"question":109,"answer":110},"What happens when a pull request conflicts while it's being merged?","The same as a conflicting sync. Plexus puts the branch back as it was and, by default, hands the conflict to that session's agent, which resolves it in its own terminal without pushing; Plexus pushes the result, waits for the checks and merges it. Each conflict goes to the agent once. If the agent can't resolve it, or you chose Ask me first or Stop, the row reads Needs you: conflict, merging stops there, and it carries on by itself once the conflict is resolved.",{"question":112,"answer":113},"What if Plexus quits halfway through a merge?","The merge comes back paused, and nothing merges until you click the merge button again; the panel says where it will carry on from. Every step is a single action against your git provider, so what had merged stays merged, and the rows keep their states in the meantime.",{"eyebrow":57,"headline":115,"lead":116},"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.",{},true,5,[121,134,145,155,164,175,182,189],{"id":122,"heading":123,"body":124,"state":125,"docsPath":126,"sim":127},"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.","working","\u002Fdocs\u002Fstacks#stack-sessions",{"view":128,"stacks":118,"selected":129,"anchors":130},"sessions","guest-checkout-ui",[131,132,133],"stack:checkout-flow","stack-pill","stack-panel",{"id":135,"heading":136,"body":137,"state":125,"docsPath":138,"sim":139},"sync","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":128,"stacks":118,"start":140,"anchors":141,"note":144},16,[142,143],"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":146,"heading":147,"body":148,"state":149,"docsPath":150,"sim":151},"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.","needs-you","\u002Fdocs\u002Fstacks#when-a-sync-conflicts",{"view":152,"anchors":153,"note":154},null,[],"The demo has no conflicting sync.",{"id":156,"heading":157,"body":158,"state":125,"docsPath":159,"sim":160},"pull-requests","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":128,"stacks":161,"anchors":162},"merge",[163,133],"stack-native",{"id":161,"heading":165,"body":166,"state":167,"docsPath":168,"sim":169},"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.","merged","\u002Fdocs\u002Fstacks#merging",{"view":128,"stacks":161,"start":89,"anchors":170,"note":174},[171,172,173],"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":176,"heading":177,"body":178,"state":167,"docsPath":179,"sim":180},"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":152,"anchors":181},[],{"id":183,"heading":184,"body":185,"state":149,"docsPath":186,"sim":187},"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":152,"anchors":188},[],{"id":190,"heading":191,"body":192,"state":193,"docsPath":194,"sim":195},"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.","neutral","\u002Fdocs\u002Fstacks#what-a-plan-gates",{"view":152,"anchors":196},[],{"title":38,"description":92},"stacks","features\u002Fstacks","mluEYhfCwLlz_h6IREuuBb8DdeGjRpIJLcv4oqPMIKQ",[202,205,208,211,214,215],{"path":7,"title":203,"navTitle":6,"description":204},"Parallel Claude Code sessions with live 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.",{"path":10,"title":206,"navTitle":9,"description":207},"Review AI agent changes like a pull request","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.",{"path":13,"title":209,"navTitle":12,"description":210},"A git worktree per agent, set up by your own 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.",{"path":16,"title":212,"navTitle":15,"description":213},"Git client, PRs and GitHub issues for AI agents","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.",{"path":19,"title":38,"navTitle":18,"description":92},{"path":22,"title":216,"navTitle":21,"description":217},"Teams: organizations, managed settings, prompts","Organizations, shared workspaces, managed settings, a shared prompt library and sync for teams on Claude Code. Seats are paid; the core app stays free.",1792695507504]