Thanks for the architecture. Agents being just keypairs with their own subscriptions, and everything being one signed event log, is great. I've had this idea in my head for a while and Buzz is the first thing I've found where it wasn't a fight to build.
Draft PR with the code: #3050 (#3050)
The idea
Let multiple people share one agent session, in an agent view instead of a chat thread.
The problem I was trying to solve
1. Engineers want to stay in the agent view, not a chat thread.
When I'm actually working with an agent I want to be in the harness. More control, more visibility, I can see what it's doing and steer it. A chat thread is a worse place to do that work. But the moment you go work in your own terminal, your team loses all visibility into what you're doing.
So what if the agent view itself was the collaborative surface? You stay where you like working, and your team can drop in, watch, and chime in. That's the idea, multiple people in one session.
2. You need to see the work, not just the output.
Right now the panel shows the transcript, but there's no persistent "what is it doing right now." When the agent is mid-turn it can look hung. For someone actually building, the logs and tool calls matter as much as the final answer. That's how you know whether to let it keep going or redirect it.
So I added a live status line: elapsed time, token count, the shell commands currently running, tool progress. All of it comes from data the observer stream already carries (usage_update, tool startedAt/completedAt), nothing is estimated.
Those two things are the core value: keep engineers where they want to work, and give everyone real visibility into what the agent is doing.
Screenshots
Entry point, terminal icon in the thread header
The session view
How it works
You @ an agent and get a thread like normal. A terminal icon shows up in the thread header. Click it and the session opens full screen. From there you type to the agent directly, the thread's message history sits on the left so you can see what everyone has asked, and the transcript streams the agent's thinking and tool calls live in the middle.
It's URL addressable, so the view survives a reload and you can send someone a link to the session.
I know this is a big PR
That's why I'm opening an issue instead of just throwing the PR at you. If you want it, here's how I'd break it up:
- Put the full screen view behind
preview-features.json, the same way Workflows, Projects, Pulse and Forum Channels shipped hidden first
- Split the small independently useful pieces into their own PRs. Tool call groups rendering expanded, and an in-channel way to reach agent activity when the agent isn't mid-turn (right now the composer pill only shows while
composerWorkingBotPubkeys.length > 0, so there's no entry point for an idle agent)
- Land the full view last, behind the flag
Totally fine if the answer is "no thanks" or "we'd want this differently." That's useful to know before I keep building.
Two things worth flagging
Naming. I've been calling it "harness mode," which collides with how Buzz already uses "harness" for the ACP runtime (goose / claude-agent-acp / codex-acp). Happy to rename it.
File size guard. ChannelPane, ChannelScreen and AgentSessionTranscriptList are all sitting at their line caps on main already. ChannelScreen has one line of headroom. So wiring anything through them trips check:file-sizes. I pulled most of my code out into its own hook, but the integration points themselves still push those files over. Rather than restructure your files in a first contribution, I'd rather ask where you'd want this mounted. Details in #3050.
Duplicates
I searched open issues and PRs, none found for this. Closest is #2201 (activity feed message content), which is adjacent but different. The existing "harness" issues (#1946, #2535) are about the ACP runtime config screen, not this.
Environment
macOS, built from source with just dev. Agent: Fizz via @agentclientprotocol/claude-agent-acp 0.62.0.
Thanks for the architecture. Agents being just keypairs with their own subscriptions, and everything being one signed event log, is great. I've had this idea in my head for a while and Buzz is the first thing I've found where it wasn't a fight to build.
Draft PR with the code: #3050 (#3050)
The idea
Let multiple people share one agent session, in an agent view instead of a chat thread.
The problem I was trying to solve
1. Engineers want to stay in the agent view, not a chat thread.
When I'm actually working with an agent I want to be in the harness. More control, more visibility, I can see what it's doing and steer it. A chat thread is a worse place to do that work. But the moment you go work in your own terminal, your team loses all visibility into what you're doing.
So what if the agent view itself was the collaborative surface? You stay where you like working, and your team can drop in, watch, and chime in. That's the idea, multiple people in one session.
2. You need to see the work, not just the output.
Right now the panel shows the transcript, but there's no persistent "what is it doing right now." When the agent is mid-turn it can look hung. For someone actually building, the logs and tool calls matter as much as the final answer. That's how you know whether to let it keep going or redirect it.
So I added a live status line: elapsed time, token count, the shell commands currently running, tool progress. All of it comes from data the observer stream already carries (
usage_update, toolstartedAt/completedAt), nothing is estimated.Those two things are the core value: keep engineers where they want to work, and give everyone real visibility into what the agent is doing.
Screenshots
Entry point, terminal icon in the thread header
The session view
How it works
You @ an agent and get a thread like normal. A terminal icon shows up in the thread header. Click it and the session opens full screen. From there you type to the agent directly, the thread's message history sits on the left so you can see what everyone has asked, and the transcript streams the agent's thinking and tool calls live in the middle.
It's URL addressable, so the view survives a reload and you can send someone a link to the session.
I know this is a big PR
That's why I'm opening an issue instead of just throwing the PR at you. If you want it, here's how I'd break it up:
preview-features.json, the same way Workflows, Projects, Pulse and Forum Channels shipped hidden firstcomposerWorkingBotPubkeys.length > 0, so there's no entry point for an idle agent)Totally fine if the answer is "no thanks" or "we'd want this differently." That's useful to know before I keep building.
Two things worth flagging
Naming. I've been calling it "harness mode," which collides with how Buzz already uses "harness" for the ACP runtime (goose / claude-agent-acp / codex-acp). Happy to rename it.
File size guard.
ChannelPane,ChannelScreenandAgentSessionTranscriptListare all sitting at their line caps onmainalready.ChannelScreenhas one line of headroom. So wiring anything through them tripscheck:file-sizes. I pulled most of my code out into its own hook, but the integration points themselves still push those files over. Rather than restructure your files in a first contribution, I'd rather ask where you'd want this mounted. Details in #3050.Duplicates
I searched open issues and PRs, none found for this. Closest is #2201 (activity feed message content), which is adjacent but different. The existing "harness" issues (#1946, #2535) are about the ACP runtime config screen, not this.
Environment
macOS, built from source with
just dev. Agent: Fizz via@agentclientprotocol/claude-agent-acp0.62.0.