ACP tool_call/tool_call_update use generic titles while running

[nizheming]

ACP emits generic tool metadata before completion.

In packages/opencode/src/acp/agent.ts, tool_call and tool_call_update(status=in_progress) use part.tool as the title, and toolStart() sends rawInput: {}. Only the completed update uses part.state.title and the richer input.

This means ACP clients often show bash, read, or skill while a tool is pending/running, even when a semantic title is already available in part.state.title.

Current local source still does this on v1.4.11-199-ga419f1c50.

OpenCode version

v1.4.11-199-ga419f1c50

Steps to reproduce

1. Run opencode acp with an ACP client that displays tool progress.
2. Trigger a tool with a semantic running title, for example a skill or connector-backed action.
3. Observe the pending/running tool card.
4. Compare it with the completed tool event.

Expected

Pending/running ACP events should use the best available semantic metadata:

• prefer part.state.title ?? part.tool
• prefer part.state.input ?? {}

Actual

Pending/running events use generic values:

• title: part.tool
• rawInput: {} in tool_call
• generic titles such as bash, read, skill until completion

Why this matters

Downstream ACP clients cannot render meaningful running status if the adapter only sends generic metadata before completion.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [ACP] Opencode sets rawInput back to empty #7370: Describes the same behavior — ACP tool_call events emit rawInput: {} and generic titles (e.g. bash) before the richer metadata arrives via tool_call_update. The root cause and symptoms are essentially identical.
• [Zed ACP] Tool call panel doesn't display actual terminal commands #14034: Related — ACP tool call panel shows generic/description titles instead of actual command content, also caused by the same protocol metadata ordering issue.

If your report adds new context (e.g. the part.state.title fix direction or the skill/connector case), it may still be worth keeping open — but please review those issues and comment there if they already cover your case.

[nizheming]

Thanks. This does overlap with #7370, but I think this report still adds a narrower ACP adapter fix and a concrete patch.

The new part here is that the adapter can already prefer semantic metadata during pending/running events when it is available:

• title: part.state.title ?? part.tool
• rawInput: part.state.input ?? {}
• locations: recomputed from that input for early ACP events

That matters for cases where clients currently show generic labels like bash / read / skill until completion, even though a semantic running title is already present.

I opened a minimal fix PR here: #23948.