Consolidate ACP Tool Call Events from 3 to 2

[OhadRubin]

Consolidate ACP Tool Call Events from 3 to 2

Summary

Reduce tool call event emissions from 3 events (pending → running → completed) to 2 events (running → completed) by removing the redundant pending event.

Problem

Currently, we send 3 ACP events per tool call:

• pending: tool_call event with no input parameters (empty {})
• running: tool_call_update event with the actual input parameters
• completed: tool_call_update event with results

The pending event provides no useful information since part.state.input is empty by design, creating unnecessary noise in the ACP event stream.

Root Cause Analysis

The pending event has no input content by design. In src/session/prompt.ts:1076, when the "tool-input-start" event occurs, the tool part is created with:

state: {
  status: "pending",
  input: {},  // Empty object - no parameters yet
  raw: "",
}

The input parameters are only populated when the tool transitions to "running" status. This means:

• pending state: Tool is queued, but part.state.input is empty ({})
• running state: Tool is executing, part.state.input contains actual parameters

In src/acp/agent.ts, when we receive the pending event via this.config.sdk.event.subscribe, the part.state.input field is empty.

Conclusion: The pending event is inherently empty and provides no useful information beyond the tool ID. The original 2-event approach (skip pending, only send running + completed) is correct.

Solution

Skip the pending state and only emit 2 events:

• running: tool_call event with input parameters and status: "in_progress"
• completed: tool_call_update event with results

Changes

In src/acp/agent.ts:150-165:

• Add break in pending case (no-op)
• Consolidate tool call emission into running case with actual input parameters
• Send status: "in_progress" instead of separate pending/running events

Testing

Tested with the latest version of Zed and it works.

[rekram1-node]

@OhadRubin but the first party supported agents by zed set this, so why shouldn't we do the same to be consistent with them?

Also it is part of the spec to set it isn't it

[OhadRubin]

I mean sure it's part of the spec, but the event is nothing useful, you are logging no useful information by emitting this event, just that *some* tool id. Either we log the actual arguments for the tool call via a 'pending' call (but it's set later) or remove it.

…

On Mon, Nov 10, 2025, 6:36 PM Aiden Cline ***@***.***> wrote: *rekram1-node* left a comment (anomalyco/opencode#4155) <#4155 (comment)> @OhadRubin <https://github.com/OhadRubin> but the first party supported agents by zed set this, so why shouldn't we do the same to be consistent with them? Also it is part of the spec to set it isn't it — Reply to this email directly, view it on GitHub <#4155 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAOKQQ4B5Y2JMZUBWHCET334C5IBAVCNFSM6AAAAACLU7VIYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJSG4ZDQNRTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[OhadRubin]

Also, I was comparing the interface with the other zed acp adapter and this is the only implementation where tool_call did not have the arguments of the tool call. So take that as you will

…

On Mon, Nov 10, 2025, 7:13 PM Ohad Rubin ***@***.***> wrote: I mean sure it's part of the spec, but the event is nothing useful, you are logging no useful information by emitting this event, just that *some* tool id. Either we log the actual arguments for the tool call via a 'pending' call (but it's set later) or remove it. On Mon, Nov 10, 2025, 6:36 PM Aiden Cline ***@***.***> wrote: > *rekram1-node* left a comment (anomalyco/opencode#4155) > <#4155 (comment)> > > @OhadRubin <https://github.com/OhadRubin> but the first party supported > agents by zed set this, so why shouldn't we do the same to be consistent > with them? > > Also it is part of the spec to set it isn't it > > — > Reply to this email directly, view it on GitHub > <#4155 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABAOKQQ4B5Y2JMZUBWHCET334C5IBAVCNFSM6AAAAACLU7VIYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJSG4ZDQNRTGE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >