direction, not dates

Roadmap

This is a projection of the internal plan, not a copy of it, and it carries no dates. Everything on this page is direction, and direction changes. What has already shipped is deliberately not here: the changelog is the record of that, and it is the only one of the two that is a commitment.

Some of what gets asked for will never be built, and the reasons are specific rather than a shortage of time. Deliberately not on the roadmap is that list, and it is worth reading before asking for something.

Being built now

One theme at a time, and this is the current one.

  • Getting it installablePublished wheel and desktop artifacts, an update check against a static manifest with a staged swap that preserves live sessions, clean-machine install and upgrade testing, and this site.
  • The first ten minutesA first run that works on a phone as well as a desktop, an in-app help surface that links here rather than restating things, and inline controls for the gates that quietly stop a new install from doing anything.

Next

Direction, in rough order of how settled it is. None of it is dated, and anything here can be reordered by what the first users actually hit.

  • More harnessesThe registry was built so that a new agent CLI costs a descriptor and an adapter instead of a branch through every feature. The candidate study exists; spending that abstraction is the work.
  • macOSImplemented behind the same platform seams as Linux and typechecked on every gate run, but it has never been executed. It becomes a supported platform when somebody runs the suite on real hardware, not before.
  • Deeper code analysisJoining the structural graph to the behavioral record at the symbol level: cross-session conflict prediction, entity-level change facts, and stale-caller detection. swe-mux is the only observer that sees every parallel session's edits as they happen, which is what makes the first of those possible at all.
  • A portable verification contractThe setup and verify scripts a worktree needs are already repository-neutral, and the land queue is worth nothing without them. Making that pair reachable and adoptable from inside any repository is the gap.
  • A shared browser surfaceRecorded, and gated on an authorization decision that has not been made. Today's previews are safe precisely because they cannot navigate anywhere and no agent can drive them; letting either of those change is a product decision about trust, not a feature.

Recorded, not scheduled

Written down so the reasoning survives, with no commitment to build them.

  • Subagent visibility. Nested rows for a session's subagents and a read-only pane per subagent. There is no way to attach a terminal to a specific subagent from outside its session, so a reader over the on-disk sidecar files is the only path.
  • Following a forked conversation. When a CLI replaces its own conversation underneath a pane, that pane should be followed rather than abandoned, and a pane swe-mux has demonstrably lost track of should say so instead of freezing on its last reading.

Deliberately not on the roadmap

These are not oversights and they are not "later". Each would need a new decision about authorization, confirmation, audit, and failure behaviour before it could be scheduled at all, and none of those decisions has been made. A request for one of them is closed with a link back to this section, which is a boundary rather than a judgement about whether the idea is a good one. No number of votes moves anything out of this list; only one of those decisions would.

  • Autonomous actuation. Model-authored action selection, unrestricted terminal writes, auto-approval, or arbitrary command execution. Observers structurally cannot type, approve, or spawn, and that is the property the rest of the design rests on.
  • Killing processes it merely suspects. swe-mux finds hung and orphaned processes and shows them to you. It does not terminate them on its own judgement.
  • A cloud service. No account, no relay, no server, no telemetry. The phone reaches your machine over your own tailnet, and there is no third party in the path because there is no third party.
  • A chat-bot control adapter. Web push covers outbound alerting and the mobile browser covers inbound control, so a bot would buy "reply without opening the UI" at the cost of a second confirmation surface to keep safe.
  • Remote execution hosts. Treating machines over SSH as execution targets, with a remote filesystem provider and a deployed relay. A host already on your tailnet can reach the daemon directly, which is the cheaper answer to most of what this would buy.

Asking for something

Feature requests are GitHub Discussions in the Ideas category, and a thumbs-up on one is a vote. The issue tracker stays for bugs. A request that is accepted becomes an issue at that point and carries its discussion and its votes across with it.

Describe the problem, not the fix. What you were trying to do, what you did instead, and what made it hard. Two proposed implementations cannot be weighed against each other, and a request that arrives as one hides the thing that would actually be built for; the form asks for it in that shape. Read deliberately not on the roadmap first, because a request that lands inside one of those boundaries gets a reason rather than a queue place.

A vote is a signal, not a commitment. Votes say what to look at first and nothing more. Nothing is scheduled by being voted for, and no count obliges anybody to build anything.

The internal plan this projects from lives in the repository under .docs/development/, along with the audits and incident runbooks it cites. It is written for the people building swe-mux and reads like it.