What happened
GitHub Next describes Ace as an experiment in real-time, multiplayer agentic development. The open-source application runs on a team’s machines rather than through a hosted service. A “channel” is the durable unit in the sidebar and runs as one worker on its host; each channel can contain one or more chats. Chats can have child chats, and stopping a parent stops its children.
For each unit of work, Ace uses a “lane”: an isolated Git worktree and branch, made with Luke Edwards’ copy-on-write worktrees. At most one chat writes to a lane at a time, and work lands as a pull request. Agents run as the user on the host, with access to that Mac’s shell, toolchains, signed-in command-line tools and, when desktop tools are enabled, apps. The announcement says this can include native app windows shown live alongside the conversation, as well as hardware the Mac can reach.
Teams are defined by a Tailscale network, or tailnet. People and machines on it can see one another’s channels in projects they can access. Access to a GitHub project follows what the user’s GitHub login can read; other people need a share. A teammate cannot ask another person’s agent to act until that person turns on the channel’s agent access, which starts off. Model calls go directly from the Mac to the provider using a user-provided Anthropic or OpenAI key kept in the keychain; GitHub says no Ace service sits between them.
Ace recommends deploying a small directory service to the team’s own account, through Cloudflare or Fly.io, so the team has one shared list of projects, hosts, project shares and channel locations. The directory does not hold channel content. A Mac on the tailnet can serve as a local-only directory instead, but channels are listed only while it is awake and online. Without a directory, teammates see channels only while their Macs are online. Optional cloud channels are in beta: they live in the team’s account and run tools in a Linux container, so they can keep working while laptops are closed. For now, cloud channels require Cloudflare Workers and Containers.
Ace is MIT-licensed, has no service behind it, and GitHub Next says to expect rough edges. The project’s own warning is unusually consequential: channels and lanes are not sandboxes. Agents can execute shell commands and modify files beyond the project with the host user’s privileges. GitHub Next advises keeping the host gateway on loopback or the private tailnet and never exposing it to the public internet.
What the archive adds
New Runtime’s earlier coverage on 2026-10-28 welcomed agents into GitHub’s product direction, while Ace is a distinct GitHub Next experiment in local, shared agent work. This is a new event rather than an update to that earlier coverage; the earlier note is not linked here because no matching New Runtime page URL is listed.
Trend signal
Ace supports the idea that production agent design depends on the harness around a model: where the agent runs, which tools it can reach and how teammates can authorize its actions. The relevant New Runtime pattern is Harness architecture outlives model choice. Ace also makes the runtime boundary concrete, though its own warning that agents inherit host privileges shows how much safety depends on configuration.
Why now
GitHub Next says this version began in the cloud and now runs on a team’s own machines so anyone can run it and invite a team. The move makes local tools and hardware available to agents without a VM setup or a separate hosted service, while shifting setup and security responsibility to the team.
Why it matters
Ace makes a useful trade-off visible for teams building agent workflows. Running an agent beside the code, developer tools and hardware it needs can reduce friction: there is no separate VM to configure or local environment to keep synchronized. Shared channels also let teammates contribute context and answer an agent’s question in the conversation where work is happening.
But local execution is not the same as isolation. An agent with the host user’s privileges can affect more than the repository, and enabling a teammate to operate it expands who can trigger those actions. Teams evaluating the workflow should treat the host, its Tailscale membership and the channel-level agent-access switch as security controls, not incidental setup. The model key path is direct to the provider, but the team still owns the machine, directory deployment and network configuration. Ace is best approached as an experiment for trusted collaborators, not as a ready-made sandbox for untrusted code or users.
Limits and uncertainty
GitHub Next labels Ace an experiment and warns that it moves fast and has rough edges. The announcement does not quantify reliability, performance, team scale or the overhead of running the directory and hosts. Cloud channels are beta and currently tied to Cloudflare Workers and Containers. The published description does not establish that Ace isolates agents from host files or commands; instead, it explicitly says they run with the host user’s privileges. Teams should verify the consequences of that access in a controlled environment before putting sensitive repositories or credentials in scope.
Skill to build now
Before piloting a local agent workflow, map the permissions of its host: which repositories, credentials, command-line tools, desktop apps and hardware are reachable? Then test one narrow task with a non-sensitive checkout, keep the host on a private tailnet, and leave teammate agent access off until you have agreed who may enable it and how changes will be reviewed.
Reader takeaway
Ace turns collaborative coding with agents into a shared, local workflow rather than a hosted sandbox. Its lanes and channels are concrete, but its key operational fact is that agents inherit the host user’s privileges. Evaluate the collaboration model and the machine’s security boundary together.