Your Agents Can't Share a Room. That's the Bug.
Look at GitHub's trending page today. mattpocock/skills sits at 312,000 stars — a curated folder of markdown files worth more than most SaaS products. claude-mem crosses 112,000 stars with persistent context across sessions. worktrunk has hit 10,900 stars managing git worktrees so multiple agents can code in parallel without stepping on each other. The agent-infrastructure wave has consolidated two hard problems: memory and parallelism. But there is a third primitive that none of these repos solve, and a dozen startups are now racing to build it.
> 📖 Read the full version with charts and embedded sources on AgentConn →
The shared session — multiple humans AND agents editing the same live context at the same time — is the genuinely unsolved problem in agent tooling. Not "run five Claude Code instances on separate branches" (worktrunk handles that). Not "remember what happened last session" (claude-mem handles that). The hard thing is: two developers and three agents, same codebase, same terminal, same conversation, right now. And Y Combinator's Fall 2026 Request for Startups says it plainly: "Agents are still mostly single-player even though serious work is collaborative."
View original post on X →
Parallel Is Not Multiplayer
To understand why the shared session is hard, you have to understand what the current parallel-fleet model actually buys you — and where it stops.
Worktrunk, the Rust CLI trending at +524 stars per day, is the poster child of the parallel approach. You run wt switch -x claude -c feature-auth, and it creates an isolated git worktree with its own branch, its own directory, and its own Claude Code instance. Five agents, five worktrees, five branches, zero conflicts. It is elegant and it works.
But it works by avoiding the hard problem. Each agent is isolated. No agent knows what any other agent is doing. There is no shared context, no real-time awareness, and no way for Agent A to say "I just refactored the auth module — don't touch it" to Agent B. When the branches merge, conflicts appear for the first time. Practitioners in Reddit discussions report the practical ceiling: "2-3 active sessions is the practical ceiling unless the tasks are very separated."
{% youtube ClWD8OEYgp8 %}
View on Hacker News →
Maggie Appleton, Staff Research Engineer at GitHub Next, put it best in her AI Engineer London talk: the "one man, two dozen Claudes" model does not produce team alignment. Scaling one person's output through isolated parallel agents does not coordinate a team. Her research prototype Ace puts teammates and coding agents into one shared workspace for planning, conversation, and code — because the alternative is a dozen agents with local plans that nobody else can see.
This is the gap. Parallel tools (worktrunk, Agent Teams) solve throughput. But real software engineering is collaborative: pair programming, live code reviews, cross-role handoffs between PMs and developers, debugging sessions where three people and an agent stare at the same stack trace. The current model forces you to choose between collaboration (single session, one agent, takes turns) and parallelism (many agents, zero coordination). The shared-session primitive is supposed to give you both.
The Tools Racing to Fill the Gap
A half-dozen tools launched in 2026 that each attack a different slice of the shared-session problem. None of them solve the whole thing.
Delta (Zed) — Session Sharing Across Machines
Delta, released by Zed Industries in August 2026, is arguably the most polished entry. The host runs /delta share inside Claude Code, gets an invite link, and the guest runs /delta join. Delta synchronizes the conversation transcript and the working copy across both machines. Both developers see what Claude tried, what failed, and what is uncommitted — without waiting for a commit.
View the full article on Zed Blog →
Zed's announcement describes Delta as "a multiplayer environment for coding with agents and reviewing what they build." It is still in private beta. Claude Code is the first third-party harness supported, with Pi planned next. The plugin is open source.
What it solves: Asynchronous context sharing between two humans working with the same agent. A developer picks up where their teammate left off without re-reading a branch history.
What it does not: Agent-to-agent coordination. Delta shares a human-readable transcript, not a machine-readable state. Two agents cannot negotiate file ownership through Delta.
Conductor (Melty Labs) — Multiplayer Cloud Workspaces
Conductor, from Melty Labs (YC-backed, $22M Series A), launched Conductor Cloud on July 30, 2026. It started as a Mac app for running parallel Claude Code sessions and evolved into multiplayer cloud workspaces. Teammates invite each other into the same workspace, prompt agents together, and watch progress from the desktop client.
View the full changelog on Conductor →
Each cloud workspace runs in an isolated microVM (built on Vercel Sandboxes) with the repo and dependencies preinstalled. Agents keep running when you close the app. The model-agnostic design supports Claude Code, Codex, Cursor, and OpenCode.
{% youtube fQmlML9Lay4 %}
What it solves: Persistent, cloud-native multiplayer. A teammate joins your workspace and both can prompt agents. The workspace outlives your laptop lid.
What it does not: Real-time co-editing. Conductor's multiplayer is more "shared workspace" than "shared cursor." Two people can prompt different agents in the same workspace, but they are not editing the same file in real time with conflict resolution.
vibelive — Figma-Style Cursors in the Terminal
vibelive takes a different approach entirely. It wraps any agentic coding terminal — Claude Code, Codex, Gemini — and adds live Figma-style cursors, presence indicators, and in-terminal chat. You run vibelive host -- claude, get a join URL, and collaborators see your terminal in real time.
What it solves: Real-time presence and awareness. You know who is watching, who is typing, and where their attention is. It is the closest thing to "Google Docs for terminals."
What it does not: Conflict resolution or agent awareness. vibelive shares the terminal stream, but the agents inside it have no idea other participants exist. It is a collaboration layer around the agent, not inside it.
Mosaic (YC S26) — Shared Memory, Not Shared Sessions
Mosaic, a YC Summer 2026 company, started as a real-time coding environment and pivoted toward shared memory. Its current product (Ocean) syncs every AI session your team runs — Claude Code, Codex, Cursor — into one shared knowledge base that any agent can query. The thesis: if every agent knows what every other agent decided and why, you do not need them in the same room.
View the full review on Wavect →
A third-party review of Mosaic warns: "Do not assume concurrent edits are conflict-free. Collaboration and conflict-handling questions are treated as open." The review notes that Mosaic reports approximately 2,000 installs and 37 organizations actively syncing, though these are company-disclosed figures.
What it solves: Asynchronous context continuity. Agent B knows what Agent A decided yesterday without being in the same session.
What it does not: Real-time collaboration. Mosaic's value is in memory, not presence.
Agor (Preset) — The Spatial Canvas
Agor, from the team behind Apache Superset, is the most ambitious entry. It provides a visual canvas where Claude Code, Codex, and Gemini sessions run side-by-side on isolated git worktrees — but with live cursors, a facepile, scoped comments, and a shared multiplayer terminal. Drop a worktree into a spatial zone and it fires a templated prompt. An MCP server lets agents introspect and spawn other agents. Slack and GitHub threads act as portals into agent sessions.
What it solves: The orchestration UX. Agor gives you a visual overview of what every agent is doing, plus collaboration tools to coordinate between them.
What it does not: The isolation is still per-worktree. The agents themselves are not sharing a live session — they are running independently in adjacent boxes, with a human-facing collaboration layer on top.
{% youtube OL7kfezynJM %}
Why Shared Sessions Are Harder Than Parallel Fleet
The reason every tool solves a different slice is that the full problem is genuinely difficult. Parallel fleet (worktrunk-style) succeeds by making a simplifying assumption: agents do not need to coordinate in real time. Shared sessions throw that assumption out, and three hard sub-problems fall in.
1. Conflict Resolution Is Not Git Merge
When two agents edit the same file in a worktree model, you get a git merge conflict at PR time. Painful, but tractable — a human resolves it. In a shared session, the conflict happens in real time. Agent A writes line 42 while Agent B deletes lines 40-45. Who wins? Git's three-way merge does not help here because there is no "commit" boundary — edits are streaming. This is the same problem that Google Docs solved for text with Operational Transformation (OT) and CRDTs, but no one has applied it to agent code edits at the semantic level. Character-level OT does not understand that a renamed function changes every call site.
2. Context Pollution
In a shared session, every participant's actions become part of every other participant's context window. If Agent A is debugging a CSS layout while Agent B is writing database migrations, Agent B's context now includes CSS debugging noise. This is the "open office problem" for agents — proximity breeds distraction. Source control for multi-agent repos is hard enough when agents work sequentially; real-time shared context makes it exponentially worse.
3. Permission Scoping
Who can approve what? If Agent A and Human B are in the same session, and Agent A wants to delete a file, does it need Human B's approval? What about Human C who just joined? The approval model in current agent harnesses assumes one human, one agent, one permission scope. Shared sessions blow that up.
View the Multiplayer AI Manifesto →
The Multiplayer AI Manifesto by Sergey Karayev explicitly lists "permissions, privacy, accountability, and governance" as open problems, and notes that no platform meets the entire manifesto today.
> The Contrarian Take: Shared sessions might be an anti-pattern. The reason agents work well on isolated worktrees is precisely because they cannot step on each other. Introducing real-time collaboration multiplies the failure surface — merge conflicts, context pollution, permission escalation. The 2-3 concurrent agent ceiling that practitioners report may be fundamental, not a tooling gap. "Multiplayer" might be a VC pitch that sounds great and ships badly. Before adopting any shared-session tool, ask: is my bottleneck actually coordination, or is it throughput?
The Landscape Map
Here is how the current tools map against the three hard problems:
| Tool | Real-Time Presence | Conflict Resolution | Agent-Aware | Permission Scoping |
|------|-------------------|---------------------|-------------|-------------------|
| Worktrunk | No | Git merge at PR | No | N/A (isolated) |
| Delta (Zed) | Partial (transcript) | No (human resolves) | No | No |
| Conductor | Yes (workspace) | No (per-agent sandbox) | No | Workspace-level |
| vibelive | Yes (cursors) | No | No | Host-authoritative |
| Mosaic | No (async memory) | No | Partial (shared memory) | No |
| Agor | Yes (canvas) | No (per-worktree) | Partial (MCP introspection) | Zone-level |
The pattern is clear: every tool has presence OR isolation, never both with conflict resolution. The cell that says "Yes" for all four columns is empty. That is the product that does not exist yet.
View original post on X →
What Practitioners Should Do Now
If you are building with multi-agent setups today, the honest advice is: do not chase the shared-session dream yet. Here is what the maturity ladder looks like:
> Step 1 — File Collisions: If your agents trip over each other's files, you need isolation, not collaboration. Use worktrunk or Claude Code's built-in worktree support. The problem is separation, not togetherness.
Step 2 — Lost Context: If Agent B does not know what Agent A decided yesterday, you need shared memory, not a shared session. Mosaic, claude-mem, or even a well-structured MEMORY.md file solve this without real-time overhead.
Step 3 — Pair Programming: If you pair-program with an agent and want a colleague to jump in, Delta is the most mature option for session sharing between humans. It works, it is in beta, and it does not try to be more than it is.
Step 4 — Agents Prompting Agents: If you need agents prompting agents in a shared workspace, Conductor's cloud workspaces are the closest to this, but expect to manage coordination yourself. The agents do not coordinate automatically.
Step 5 — The Full Vision: If you want multiple humans and agents, real-time, conflict-aware — it does not exist yet. Build accordingly. The agent swarms still cannot coordinate, and adding humans to the mix makes coordination harder, not easier.
> The Demand Signal Is Real: YC's Fall 2026 RFS explicitly asks for "a workspace where a whole team works with agents in real time." The Multiplayer AI Manifesto defines five principles for what this should look like and admits no platform meets them. GitHub Next is researching it (Ace). The gap is recognized. But recognized gaps and shipped products are different things.
The Prediction
Within 12 months, one of these tools will ship real-time conflict resolution for agent code edits — probably using a CRDT-based approach adapted from collaborative editors like Yjs. The winner will not be the tool that ships the most features but the one that solves the conflict-resolution problem at the semantic level (understanding that a function rename affects all call sites) rather than the character level.
When that happens, the agent-of-agents pattern will shift from orchestrating isolated fleet members to coordinating collaborators who share a live codebase. The abstraction layer will move from "launch N agents on N branches" to "invite N agents into one session with scoped permissions."
Until then, the honest answer is: your agents cannot share a room. And for most workflows, that is fine. The tools you need — isolation, memory, parallelism — already exist and already work. The shared session is the next primitive, not the current one. Build for what ships today, and watch this space for what ships tomorrow.
---
The multiplayer agent tooling landscape is moving fast. For the parallel-fleet approach, see our coverage of source control for multi-agent repos. For why memory matters more than models, see Memory Is the New Moat.
Originally published at AgentConn
Mentions
今日のGitHubトレンド max-sixty/worktrunk 提供されたREADMEには、プロジェクト名「Worktrunk」とドキュメントやライセンス等のバッジ情報のみが記載されており、リポジトリの目的に関する具体的な記述はありません。
worktrunk is a CLI for git worktrees, built for running coding agents in parallel. Each task gets its own checkout so agents stop overwriting each other. 11.1k stars. Boring git plumbing beats another dashboard. max-sixty/worktrunk
Your Agents Can't Share a Room. That's the Bug. Look at GitHub's trending page today. mattpocock/skills sits at 312,000 stars — a curated folder of markdown files worth more than most SaaS products. claude-mem crosses 112,000 stars with persistent context across sessions. worktrunk has hit 10,900 stars managing git worktrees so multiple agents can code in parallel without stepping on each other. The agent-infrastructure wave has consolidated two hard problems: memory and parallelism. But there is a third primitive that none of these repos solve, and a dozen startups are now racing to build it. > 📖 Read the full version with charts and embedded sources on AgentConn → The shared session — multiple humans AND agents editing the same live context at the same time — is the genuinely unsolved problem in agent tooling. Not "run five Claude Code instances on separate branches" (worktrunk handles that). Not "remember what happened last session" (claude-mem handles that). The hard thing is: two developers and three agents, same codebase, same terminal, same conversation, right now. And Y Combinator's Fall 2026 Request for Startups says it plainly: "Agents are still mostly single-player even though serious work is collaborative."  View original post on X → Parallel Is Not Multiplayer To understand why the shared session is hard, you have to understand what the current parallel-fleet model actually buys you — and where it stops. Worktrunk, the Rust CLI trending at +524 stars per day, is the poster child of the parallel approach. You run wt switch -x claude -c feature-auth, and it creates an isolated git worktree with its own branch, its own directory, and its own Claude Code instance. Five agents, five worktrees, five branches, zero conflicts. It is elegant and it works. But it works by avoiding the hard problem. Each agent is isolated. No agent knows what any other agent is doing. There is no shared context, no real-time awareness, and no way for Agent A to say "I just refactored the auth module — don't touch it" to Agent B. When the branches merge, conflicts appear for the first time. Practitioners in Reddit discussions report the practical ceiling: "2-3 active sessions is the practical ceiling unless the tasks are very separated." {% youtube ClWD8OEYgp8 %}  View on Hacker News → Maggie Appleton, Staff Research Engineer at GitHub Next, put it best in her AI Engineer London talk: the "one man, two dozen Claudes" model does not produce team alignment. Scaling one person's output through isolated parallel agents does not coordinate a team. Her research prototype Ace puts teammates and coding agents into one shared workspace for planning, conversation, and code — because the alternative is a dozen agents with local plans that nobody else can see. This is the gap. Parallel tools (worktrunk, Agent Teams) solve throughput. But real software engineering is collaborative: pair programming, live code reviews, cross-role handoffs between PMs and developers, debugging sessions where three people and an agent stare at the same stack trace. The current model forces you to choose between collaboration (single session, one agent, takes turns) and parallelism (many agents, zero coordination). The shared-session primitive is supposed to give you both. The Tools Racing to Fill the Gap A half-dozen tools launched in 2026 that each attack a different slice of the shared-session problem. None of them solve the whole thing. Delta (Zed) — Session Sharing Across Machines Delta, released by Zed Industries in August 2026, is arguably the most polished entry. The host runs /delta share inside Claude Code, gets an invite link, and the guest runs /delta join. Delta synchronizes the conversation transcript and the working copy across both machines. Both developers see what Claude tried, what failed, and what is uncommitted — without waiting for a commit.  View the full article on Zed Blog → Zed's announcement describes Delta as "a multiplayer environment for coding with agents and reviewing what they build." It is still in private beta. Claude Code is the first third-party harness supported, with Pi planned next. The plugin is open source. What it solves: Asynchronous context sharing between two humans working with the same agent. A developer picks up where their teammate left off without re-reading a branch history. What it does not: Agent-to-agent coordination. Delta shares a human-readable transcript, not a machine-readable state. Two agents cannot negotiate file ownership through Delta. Conductor (Melty Labs) — Multiplayer Cloud Workspaces Conductor, from Melty Labs (YC-backed, $22M Series A), launched Conductor Cloud on July 30, 2026. It started as a Mac app for running parallel Claude Code sessions and evolved into multiplayer cloud workspaces. Teammates invite each other into the same workspace, prompt agents together, and watch progress from the desktop client.  View the full changelog on Conductor → Each cloud workspace runs in an isolated microVM (built on Vercel Sandboxes) with the repo and dependencies preinstalled. Agents keep running when you close the app. The model-agnostic design supports Claude Code, Codex, Cursor, and OpenCode. {% youtube fQmlML9Lay4 %} What it solves: Persistent, cloud-native multiplayer. A teammate joins your workspace and both can prompt agents. The workspace outlives your laptop lid. What it does not: Real-time co-editing. Conductor's multiplayer is more "shared workspace" than "shared cursor." Two people can prompt different agents in the same workspace, but they are not editing the same file in real time with conflict resolution. vibelive — Figma-Style Cursors in the Terminal vibelive takes a different approach entirely. It wraps any agentic coding terminal — Claude Code, Codex, Gemini — and adds live Figma-style cursors, presence indicators, and in-terminal chat. You run vibelive host -- claude, get a join URL, and collaborators see your terminal in real time. What it solves: Real-time presence and awareness. You know who is watching, who is typing, and where their attention is. It is the closest thing to "Google Docs for terminals." What it does not: Conflict resolution or agent awareness. vibelive shares the terminal stream, but the agents inside it have no idea other participants exist. It is a collaboration layer around the agent, not inside it. Mosaic (YC S26) — Shared Memory, Not Shared Sessions Mosaic, a YC Summer 2026 company, started as a real-time coding environment and pivoted toward shared memory. Its current product (Ocean) syncs every AI session your team runs — Claude Code, Codex, Cursor — into one shared knowledge base that any agent can query. The thesis: if every agent knows what every other agent decided and why, you do not need them in the same room.  View the full review on Wavect → A third-party review of Mosaic warns: "Do not assume concurrent edits are conflict-free. Collaboration and conflict-handling questions are treated as open." The review notes that Mosaic reports approximately 2,000 installs and 37 organizations actively syncing, though these are company-disclosed figures. What it solves: Asynchronous context continuity. Agent B knows what Agent A decided yesterday without being in the same session. What it does not: Real-time collaboration. Mosaic's value is in memory, not presence. Agor (Preset) — The Spatial Canvas Agor, from the team behind Apache Superset, is the most ambitious entry. It provides a visual canvas where Claude Code, Codex, and Gemini sessions run side-by-side on isolated git worktrees — but with live cursors, a facepile, scoped comments, and a shared multiplayer terminal. Drop a worktree into a spatial zone and it fires a templated prompt. An MCP server lets agents introspect and spawn other agents. Slack and GitHub threads act as portals into agent sessions. What it solves: The orchestration UX. Agor gives you a visual overview of what every agent is doing, plus collaboration tools to coordinate between them. What it does not: The isolation is still per-worktree. The agents themselves are not sharing a live session — they are running independently in adjacent boxes, with a human-facing collaboration layer on top. {% youtube OL7kfezynJM %} Why Shared Sessions Are Harder Than Parallel Fleet The reason every tool solves a different slice is that the full problem is genuinely difficult. Parallel fleet (worktrunk-style) succeeds by making a simplifying assumption: agents do not need to coordinate in real time. Shared sessions throw that assumption out, and three hard sub-problems fall in. 1. Conflict Resolution Is Not Git Merge When two agents edit the same file in a worktree model, you get a git merge conflict at PR time. Painful, but tractable — a human resolves it. In a shared session, the conflict happens in real time. Agent A writes line 42 while Agent B deletes lines 40-45. Who wins? Git's three-way merge does not help here because there is no "commit" boundary — edits are streaming. This is the same problem that Google Docs solved for text with Operational Transformation (OT) and CRDTs, but no one has applied it to agent code edits at the semantic level. Character-level OT does not understand that a renamed function changes every call site. 2. Context Pollution In a shared session, every participant's actions become part of every other participant's context window. If Agent A is debugging a CSS layout while Agent B is writing database migrations, Agent B's context now includes CSS debugging noise. This is the "open office problem" for agents — proximity breeds distraction. Source control for multi-agent repos is hard enough when agents work sequentially; real-time shared context makes it exponentially worse. 3. Permission Scoping Who can approve what? If Agent A and Human B are in the same session, and Agent A wants to delete a file, does it need Human B's approval? What about Human C who just joined? The approval model in current agent harnesses assumes one human, one agent, one permission scope. Shared sessions blow that up.  View the Multiplayer AI Manifesto → The Multiplayer AI Manifesto by Sergey Karayev explicitly lists "permissions, privacy, accountability, and governance" as open problems, and notes that no platform meets the entire manifesto today. > The Contrarian Take: Shared sessions might be an anti-pattern. The reason agents work well on isolated worktrees is precisely because they cannot step on each other. Introducing real-time collaboration multiplies the failure surface — merge conflicts, context pollution, permission escalation. The 2-3 concurrent agent ceiling that practitioners report may be fundamental, not a tooling gap. "Multiplayer" might be a VC pitch that sounds great and ships badly. Before adopting any shared-session tool, ask: is my bottleneck actually coordination, or is it throughput? The Landscape Map Here is how the current tools map against the three hard problems: | Tool | Real-Time Presence | Conflict Resolution | Agent-Aware | Permission Scoping | |------|-------------------|---------------------|-------------|-------------------| | Worktrunk | No | Git merge at PR | No | N/A (isolated) | | Delta (Zed) | Partial (transcript) | No (human resolves) | No | No | | Conductor | Yes (workspace) | No (per-agent sandbox) | No | Workspace-level | | vibelive | Yes (cursors) | No | No | Host-authoritative | | Mosaic | No (async memory) | No | Partial (shared memory) | No | | Agor | Yes (canvas) | No (per-worktree) | Partial (MCP introspection) | Zone-level | The pattern is clear: every tool has presence OR isolation, never both with conflict resolution. The cell that says "Yes" for all four columns is empty. That is the product that does not exist yet.  View original post on X → What Practitioners Should Do Now If you are building with multi-agent setups today, the honest advice is: do not chase the shared-session dream yet. Here is what the maturity ladder looks like: > Step 1 — File Collisions: If your agents trip over each other's files, you need isolation, not collaboration. Use worktrunk or Claude Code's built-in worktree support. The problem is separation, not togetherness. Step 2 — Lost Context: If Agent B does not know what Agent A decided yesterday, you need shared memory, not a shared session. Mosaic, claude-mem, or even a well-structured MEMORY.md file solve this without real-time overhead. Step 3 — Pair Programming: If you pair-program with an agent and want a colleague to jump in, Delta is the most mature option for session sharing between humans. It works, it is in beta, and it does not try to be more than it is. Step 4 — Agents Prompting Agents: If you need agents prompting agents in a shared workspace, Conductor's cloud workspaces are the closest to this, but expect to manage coordination yourself. The agents do not coordinate automatically. Step 5 — The Full Vision: If you want multiple humans and agents, real-time, conflict-aware — it does not exist yet. Build accordingly. The agent swarms still cannot coordinate, and adding humans to the mix makes coordination harder, not easier. > The Demand Signal Is Real: YC's Fall 2026 RFS explicitly asks for "a workspace where a whole team works with agents in real time." The Multiplayer AI Manifesto defines five principles for what this should look like and admits no platform meets them. GitHub Next is researching it (Ace). The gap is recognized. But recognized gaps and shipped products are different things. The Prediction Within 12 months, one of these tools will ship real-time conflict resolution for agent code edits — probably using a CRDT-based approach adapted from collaborative editors like Yjs. The winner will not be the tool that ships the most features but the one that solves the conflict-resolution problem at the semantic level (understanding that a function rename affects all call sites) rather than the character level. When that happens, the agent-of-agents pattern will shift from orchestrating isolated fleet members to coordinating collaborators who share a live codebase. The abstraction layer will move from "launch N agents on N branches" to "invite N agents into one session with scoped permissions." Until then, the honest answer is: your agents cannot share a room. And for most workflows, that is fine. The tools you need — isolation, memory, parallelism — already exist and already work. The shared session is the next primitive, not the current one. Build for what ships today, and watch this space for what ships tomorrow. --- The multiplayer agent tooling landscape is moving fast. For the parallel-fleet approach, see our coverage of source control for multi-agent repos. For why memory matters more than models, see Memory Is the New Moat. Originally published at AgentConn
Worktrunk, a Rust CLI that makes git worktrees as easy as branches, is trending on GitHub. It's built for running many coding agents at once. Plain git has you type the branch name three times. wt switch -c -x claude feat does it and starts the agent. max-sixty/worktrunk t.co
今日のGitHubトレンド max-sixty/worktrunk Worktrunkは、トランクベース開発におけるGitブランチ管理を効率化することを目的としたツールです。
worktrunk — Worktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows Link: max-sixty/worktrunk #OpenSource #GitHub #DevTools
讲真，Worktrunk 居然可以让多个 AI agent 各干各的还不互相踩。 再也不用手动敲一串 git worktree 命令了，分支名就是工作区、一条命令切换清理，懂的都懂，赶紧安排。 max-sixty/worktrunk
3/ The build cache is the most interesting part probably. It shares 𝘁𝗮𝗿𝗴𝗲𝘁/ and 𝗻𝗼𝗱𝗲_𝗺𝗼𝗱𝘂𝗹𝗲𝘀/ between worktrees with 𝗰𝗼𝗽𝘆-𝗼𝗻-𝘄𝗿𝗶𝘁𝗲, so a new worktree does not rebuild and does not copy gigabytes. That needs APFS, btrfs or XFS. Check the repo: max-sixty/worktrunk
同时开 5 个 agent 改同一仓库，最怕互相踩文件。 worktrunk 让 git worktree 跟分支一样顺：一人一个独立目录，wt switch 一句切过去，顺手起 Claude。 适合多开 agent 并行干活的人，省掉啰嗦命令。 你并行开几个 agent？ #Git #AI编程 @grok max-sixty/worktrunk
Git Worktrees for Parallel AI Agents, in 1 Command Running multiple AI coding agents at once? Git worktrees give each agent its own working directory, but the git UX is clunky. Worktrunk is a CLI that makes worktrees as easy as branches. In this short: • wt switch -c -x claude feat: create a worktree and launch Claude in one command • wt list: every worktree with its status • wt merge main: squash, rebase, merge, and clean up • Hooks, LLM commit messages, an interactive picker, and shared build caches Install: brew install worktrunk && wt config shell install Docs: worktrunk.dev Repo: max-sixty/worktrunk (MIT OR Apache-2.0, v0.81.0 at time of recording) Unofficial explainer. I'm not affiliated with the Worktrunk project. Facts are from the README and docs as of Oct 31, 2026. #git #gitworktree #claudecode #aiagents #devtools #shorts