Model or dataset
alpbahadur/49-IDE avatar
alpbahadur/49-IDE

49-IDE: a 2D canvas for tmux sessions, agents and Beads issues

Open-source 2D IDE for managing AI agents in native CLIs, terminal, gits, beads issues, and files across multiple projects and machines. Self-host on a single machine via localhost OR host on a cluster via Tailscale OR connect to app.49agents.com (coming soon)

607 stars60 forksJavaScriptNOASSERTION

At a glance

What is it?
49-IDE puts terminals, a Monaco editor, a git graph and Beads issue tables onto one zoomable canvas, with a local agent relaying each machine over WebSocket to a relay you can self-host. The design is coherent; the licence is the part to read before you clone.
Who is it for?
Adopt it if you already run tmux and more than one machine and you want panes arranged spatially instead of in tabs; skip it if you need a plain MIT dependency, if your environment blocks WebSocket long connections, or if you need a second concurrent viewer, since the README guarantees a single-user localhost session with no account and no token.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 6 days ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem is pane sprawl, not agent capability

The README's comparison table is the clearest statement of intent. On one side: fourteen terminal tabs, SSH into each machine, alt-tab to check Claude, no way to work from a phone, no file view. On the other: one zoomable canvas, machines connected without SSH, Claude status shown on every pane, a Monaco editor on the canvas, a git graph, interactive Beads issue tables, permission notifications and markdown notes. The target reader is someone already running several agent CLIs (the repository topics list claude-code and codex, the README mentions Claude specifically) across more than one box, who has hit the limit of what tabs and splits can express. That is a narrow audience, and the project does not pretend otherwise. If you run one agent in one terminal on one laptop, the canvas is overhead you will not recover, and the README's own framing (before and after screenshots of terminal clutter) will not describe your situation.

A local agent, a relay, and a browser that holds the layout

The architecture diagram shows three roles. On each machine you run 49-agent. It opens a WebSocket (WSS) connection outbound to a relay. Browsers, on a phone, tablet or laptop, also connect to the relay over WSS. The relay is either something you self-host or the hosted 49agents.com endpoint, which the repository describes as coming soon. The multi-machine diagram makes the topology explicit: a MacBook, a PC and an Azure VM each run their own agent and each connects independently to the relay, with no agent-to-agent link. Terminals themselves are real tmux sessions exposed through ttyd, which is why the README can claim full ANSI colour, scrollback and your shell configuration rather than a reimplementation of a terminal. The README states that terminal I/O is relayed and never persisted server-side, so the relay is a pass-through for the session, not a store. Layout persistence therefore lives with the client and the agent rather than in the relay.

Setup is two shell commands and one URL

The Quick Start gives the whole path: git clone https://github.com/49Agents/49Agents.git, then cd 49Agents, then ./49ctl setup for an interactive one-time configuration, then ./49ctl start to bring up the cloud server and the agent. You then open http://localhost:1071. The README is explicit that there is no account, no login and no token on that path. For macOS there is a separate route: download the latest .dmg from the releases page, then run xattr -cr /Applications/49Agents.app once, because the app is not notarized and Gatekeeper will otherwise block it. It then lives as a tray icon, and updates are pulled from the tray menu via Check for Updates. Note the discrepancy between the repository identifier and the README: the clone URL points at 49Agents/49Agents while the repository you are reading is alpbahadur/49-IDE. I cannot confirm from this material whether one is a mirror, a rename, or a fork, so verify which remote you are actually cloning before you run 49ctl.

Broadcast input and the HUD are the parts that change habits

Two features do more work than the rest of the list. Broadcast input sends one set of keystrokes to several terminals at once, which is the reason to put multiple agent panes on a single canvas rather than in separate windows: you can drive the same instruction into several sessions without retyping it. The HUD overlay reports live CPU, RAM and Claude API usage across connected machines, which turns the canvas into a monitoring surface as well as an input surface. Navigation is keyboard-first by design: tab chords for pane switching, a WASD move mode for spatial movement, number keys 1 to 9 for instant pane focus. That set of bindings only pays off once you have enough panes that mouse targeting becomes slow, which is consistent with the multi-machine premise. The README does not document the exact chord syntax, so you will be reading the app rather than the README to learn them.

Where the design gets thin

The relay is a single point of failure for every connected machine, and the README does not describe reconnection behaviour, relay authentication, or how the hosted 49agents.com path is secured. The localhost path is stated to have no account, no login and no token, which is fine on a loopback interface and is not fine the moment the same server is reachable from a LAN or a Tailscale network. The README lists Tailscale, LAN and hosted relay as connection options without saying what protects the relay in the latter two cases. Multi-machine support also depends on a persistent outbound WebSocket from each agent, so a network that terminates long-lived connections will break panes in ways that look like agent crashes. Finally, the architecture depends on tmux and ttyd being present and working on every machine; the project is not a standalone terminal, so a broken tmux configuration on one host is a broken pane on the canvas.

Compared with a terminal multiplexer plus a browser terminal

The obvious alternative is the combination most people already have: tmux for sessions and a browser terminal such as ttyd or wetty for remote access. That stack gives you the same real tmux sessions and the same remote reach from a phone, and it costs nothing to adopt because it is already installed. The difference is spatial and structural. tmux arranges panes in a grid inside one window and expects you to attach from one client at a time; 49-IDE puts panes on an infinite canvas with persistent placement, adds file editing, git history and Beads issue tables as first-class panes, and fans several machines into one view through a relay. If your problem is only remote terminal access, tmux plus ttyd solves it with fewer moving parts. If your problem is that you cannot see six agents on three machines at once, the canvas is the thing tmux does not give you.

Licence and maintenance cost

The README states the licence as BSL 1.1, free for individuals and small teams, converting to MIT on 2030-02-26. The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not map the LICENSE file to a known identifier. Those two statements are not in conflict, but they do mean the only authority is the LICENSE file itself, and the README's summary of who counts as a small team is a summary, not the terms. Read the file before you build anything commercial on it, and take your own advice on whether your use fits. On maintenance, the release history shows 0.4.0 in August 2026 following 0.3.4 and 0.3.3 in May 2026, so this is a young project with uneven spacing between releases rather than a long stable line. Upgrades on the self-hosted path go through 49ctl, and the desktop path updates in-app from the tray, so there is no separate package manager channel to track. Budget for reading release notes between versions, because the setup script and the agent protocol are both things a minor bump can change.

Editorial conclusion

Adopt it if you already run tmux and more than one machine and you want panes arranged spatially instead of in tabs; skip it if you need a plain MIT dependency, if your environment blocks WebSocket long connections, or if you need a second concurrent viewer, since the README guarantees a single-user localhost session with no account and no token. Before you commit, run ./49ctl setup and then ./49ctl start, open http://localhost:1071, and check two things yourself: that your shell configuration and tmux scrollback survive inside the ttyd pane, and that the BSL 1.1 text in LICENSE matches what your organisation permits, because the README's plain-language summary of the licence is not the licence.

Official sources

  1. alpbahadur/49-IDE on GitHub
  2. Issues
  3. Project website
  4. README
  5. Releases
Community notes

Community notes