concepts

Projects and Groups

A Project is a folder swe-mux is pointed at, and it is the thing everything else binds to. Nothing works until there is one.

#

What a Project owns

  • SessionsEvery terminal and agent session is spawned into a Project and stays in its sidebar group for life. Stepping into a worktree does not re-home a session: a worktree is the same Project as the tree it was cut from.
  • Workspace layoutPanes, tabs, and split geometry are durable per-Project state on the desktop. The phone renders a projection of the same tree rather than a second layout.
  • Notes and filesA Project-owned note collection and a bounded file tree with ignore rules. Both open into a pane rather than only into the drawer.
  • HistoryConversations are indexed against the Project they ran in, so a search can be scoped to one repository or run across all of them.
  • Its own settingsMost switches that decide how much swe-mux does live here rather than globally. That is what lets the control plane be on for one repository and off for every other.
#

Groups are optional organisation above Projects

A Group is sidebar structure and nothing more. It does not change what a Project owns, and a Project does not need one.

#

Per-Project rather than global, and why

The control plane, automation observers, the scan timeline, the code graph, and the land queue are all off by default and enabled per Project. The reason is that they cost something - a model call, a scan budget, a graph build - and most of a person's Projects are not the one they want that spent on.

There is a second rule stacked on top of that one, and it is what makes an opt-in reachable from a drawer pane safe: a gate can only ever turn something on. Many surfaces may switch a thing on in place; exactly one editor may switch it off. For automation that editor is the Automation dashboard's Policy tab, and it holds both the install-wide ceiling and every per-Project opt-in.

#

The Project context card

A Project can carry a short user-owned description of what it is and how it is meant to be worked in. It is a fixed file with an editor and bounds, it is yours rather than generated, and control-plane features that need context read it instead of guessing.

#

What a Project does not do

  • It does not copy, move, or rewrite anything in the folder it points at.
  • It does not commit, and it does not run anything you did not ask for.
  • Registering a Project spawns no session. Nothing starts until you start it.
  • .swe-mux/ inside a checkout is per-machine state. Nothing in it is meant to be committed, and swe-mux writes a .gitignore that says so - unless you already wrote one, which is never overwritten.

Switching Projects: Ctrl+Alt+1 through 9 activate the first nine in sidebar order, and the command palette reaches the rest.