Emdash

Detailed report

Emdash Classic supports coding agents on your own development servers through SSH. Complete task and conversation synchronization across clients remains an open feature request. Emdash 2.0 is a separate early-access offering.

Research checked November 13, 2026. Sources below retain their actual publication or update dates. Undated marketing pages are treated as current claims.

Product versions

The product is General Action’s Emdash, the YC W26 coding-agent environment at emdash.com, linked directly from generalaction/emdash. I excluded Cloudflare’s EmDash CMS and the similarly named emdash.lat site, whose relationship to General Action I could not establish.

There are now two offerings: Classic, the available open-source desktop app, and Emdash 2.0, a team-focused product accepting early-access requests. The website says Classic will receive fixes while new development moves to 2.0. Its documentation explicitly covers Classic, updated November 6, 2026. 2.0 documentation is pending launch.

What it offers

Classic lets you use your preferred agents, subscriptions, repositories and compute from one workspace. You can assign tasks, inspect changes and prepare them for delivery. Remote execution keeps agents beside the dependencies and datasets already installed on your servers. Classic combines that with cross-platform clients, parallel tasks, issue intake, previews, and review tools. Its August 13, 2026 introduction confirms native agent execution and existing Claude Code or Codex subscription use.

Agents, models and payment

Agent support is broad, but “any model” needs qualification. The provider reference, updated October 23, lists 35 CLIs, including Claude Code, Codex, Cursor, Amp, OpenCode, Droid, Copilot, Qwen Code, Goose, Kimi, and Pi. Models and authentication depend on the chosen CLI. Existing subscriptions work where supported. API-key billing and custom model endpoints depend on that agent’s capabilities. Emdash is not a universal model entitlement. Resume, hooks, permission bypass, and chat-interface support vary by provider. Remote agents must be installed and authenticated remotely.

Remote execution

For your servers, the architecture is concrete. The desktop connects over SSH to a Workspace Server on your machine. That server handles Git, files, terminals, agents, search, language services, and scheduled work. Code and processes remain remote. The desktop supplies the interface and previews. No separate public application port is required. This is documented execution on machines you own or rent, distinct from Emdash’s proposed managed cloud. See Remote Development, updated November 6.

Headless Linux is therefore a real execution target, not merely a Linux desktop download. The connection guide specifies SSH access, writable home storage, Git, tools, and Linux x64/ARM64 with glibc for the referenced runtime version. It supports SSH-config aliases, jump hosts, keys, passwords, agent authentication, and forwarding. Later October 23 release notes add Apple Silicon Mac remote-server installation. Desktop clients support macOS, Windows, and Linux. Repository releases include Linux ARM64 packages.

Persistence and device handoff

Persistence has three separate meanings:

• Process survival: optional tmux integration keeps terminals and terminal-based agents running after disconnects or closing Emdash. It does not survive host reboot.
• Conversation recovery: provider-specific resume and Chat UI history are separate mechanisms. Support varies.
• Device handoff: issue #3174, opened September 8, 2026, reports that projects, tasks, and conversations created through one client do not fully appear in another. A maintainer’s September 9 workaround opens an existing host-stored workspace as a new task. That demonstrates workspace reuse, not seamless conversation synchronization.

For unattended work, Classic automations are particularly relevant: the remote Workspace Server owns scheduling, so the desktop need not stay connected. Credentials or services backed by the desktop can still introduce dependencies.

Worktrees, review and delivery

Workflow isolation uses Git worktrees: separate working directories and branches, normally one per task. You can instead use an existing workspace or repository root, which shares files with other work there. Worktrees prevent simultaneous file editing collisions. they do not guarantee conflict-free merges or provide a security sandbox. The remote task documentation clearly distinguishes these modes.

Review includes diffs, staging, commits, push, PR creation, and CI inspection. Issue integration supplies descriptions and other ticket context. Agents can run your tests using the remote toolchain. The evidence supports human-directed parallel work and recurring jobs. It does not establish a comprehensive autonomous planner that reliably decomposes work, coordinates agents, resolves dependencies, and validates everything without supervision.

Setup and privacy

Setup is straightforward: install Classic, install and authenticate agents, add a repository, and optionally connect GitHub or trackers. For remote work, add a machine and install/start its workspace runtime. Installation instructions confirm local tasks need no Emdash/GitHub sign-in.

Classic is Apache-2.0 licensed and stores application state in SQLite. The repository’s privacy statement says code and chats are not sent to Emdash servers. Agents still transmit whatever their providers require. Production telemetry is enabled by default, uses PostHog, and can be disabled. Normal events exclude code and prompts, but signed-in identity and diagnostic exceptions may be collected. Running Classic and its remote server yourself is documented. A fully self-hostable 2.0 team coordination service is not established.

Pricing

Classic’s application price is $0, with no published paid seat requirement for its documented desktop functionality. You separately pay agent subscriptions, API consumption, and infrastructure. I found no official public 2.0 seat price, compute tariff, included credits, or overage schedule. Its early-access page promises existing subscriptions and cloud commitments, but that does not establish free orchestration or cloud compute.

Development and user reports

Activity is credible: v1.2.11 shipped November 6, 2026, with SSH responsiveness, Windows authentication, and Git fixes. The repository showed roughly 6,200 stars when checked. These indicate activity, not reliability guarantees. The larger maturity concern is the product transition: Classic is maintained, while future development targets a less publicly documented offering.

Independent sentiment is sparse. In an archived Reddit discussion, a user praised appearance and feel but reported Windows setup failures and wanted container isolation and autonomous planning. The page exposes a relative “1y ago” timestamp, so I cannot assign an exact date. Those historical complaints are not proof of current missing features. More relevant, issue #2865, July 14, 2026, documents remote tabs freezing after laptop sleep. It is now closed, so treat it as a regression scenario, not a confirmed current defect. Website praise for parallelism and provider flexibility is vendor-selected testimony, not broader user satisfaction.

Team features in 2.0

For teams, 2.0 advertises shared sessions, environments, secrets, SSO, roles, spend controls, and Slack handoff. The YC profile claims web, desktop, and mobile access. These could support team workflows, but availability, deployment boundaries, security terms, and cross-device behavior need direct verification.

Fit and trial

Choose Classic if you value open source, heterogeneous agents, and your own remote compute. Avoid making it your sole workflow foundation if effortless laptop-to-phone continuity or contractual team governance is essential. The main concern is that your cross-device requirement falls between Classic’s documented limitations and 2.0’s unverified promises.

A practical trial: use one disposable repository on your Linux server, two laptops, Claude Code and Codex, and tmux. Run parallel tasks and existing tests. Sleep laptop A, continue from B, inspect conversation recovery, preview the remote app, and open a PR. Add one scheduled job while both clients are closed. Verify device handoff before adopting it.