Your first session

Nothing works until there is one, and nothing is spawned until you ask for it. A Project is a folder swe-mux is pointed at, and it is what sessions, layout, notes, files, history, and per-Project settings all bind to. Point your first one at a repository you already work in. Projects covers the rest.

1. With a Project selected, press Ctrl+Alt+T. That opens a real terminal at the Project's root - a plain shell, nothing more.
2. Type claude, codex, or whichever CLI you use, exactly as you normally would.
3. The terminal is promoted in place. Same pane, same scrollback, now carrying a transcript, a status, a prompt queue, and a context meter. swe-mux puts its own launchers first on that terminal's PATH, which is the whole mechanism.
4. Give it something to do, and watch the pane's status strip. Working, ready, awaiting, and blocked mean the same thing whichever vendor's CLI produced them.
5. While it is mid-turn, open the Queue tab in the utility drawer and stage your next message. It is durable and head-of-line, and automatic delivery is off by default: a queued message waits for you to send it.

It worked when the pane's status strip stops saying working, and the Transcript tab has something in it. A session sitting on awaiting is the agent waiting on you rather than a stall.

It starts an agent, a shell, a worktree session, or a task discovered in the repository: VS Code tasks, root package.json scripts, and .swe-mux/actions.toml. An imported task stays inert until its exact current bytes are approved, and any edit revokes that approval - so a task file that changed under you cannot run on yesterday's permission.

swe-mux is a terminal multiplexer before it is anything else. Any shell, any TUI, any CLI runs in a real pseudoterminal exactly as it does outside. A harness the registry does not know works perfectly; what it does not get is the layer on top - normalized status, transcripts, cross-vendor history, account switching. Sessions and harnesses has the detail.

mux harnesses        # every harness in the registry, with its detection state

Settings, Harnesses shows the same thing plus the executable each one resolved to. If it resolved to the wrong binary, or to none, set the path for that harness there. That is the usual fix on a machine carrying several installs of the same CLI.

The full default set is on the keyboard reference, and every one of them is rebindable.