Skip to content

feat(acp): surface session/update tool_call notifications at Info level#1141

Open
codebit0 wants to merge 1 commit into
nextlevelbuilder:mainfrom
codebit0:feat/acp-tool-call-log
Open

feat(acp): surface session/update tool_call notifications at Info level#1141
codebit0 wants to merge 1 commit into
nextlevelbuilder:mainfrom
codebit0:feat/acp-tool-call-log

Conversation

@codebit0
Copy link
Copy Markdown
Contributor

Summary

`session/update` notifications that carry tool-call state (the spec's `ToolCall` struct and the `tool_call` / `tool_call_update` inline variant) were only dumped at `Debug` level inside the raw params blob. From an operator's vantage point, `security.tool_granted` ("permission granted") and an actually-successful execution looked identical in `journalctl` — there was no signal for the failure path in between.

This made a recent regression hard to diagnose: an ACP agent was granted permission to run a script, the script silently failed inside the bridge, the agent then hallucinated a fake success message — and the only visible Info-level evidence was `security.tool_granted`, with no `status=failed` indicator anywhere.

Change

Emit one structured Info log per `session/update` notification that carries tool-call state:

```
acp: tool_call_update sid=... id=... name=... status=completed|failed|in_progress
content_preview="<first 400 chars of textual content>"
```

Two emit sites cover both spec shapes:

  • Outer `update.ToolCall` (newer ACP layout)
  • Inline `update.Update.SessionUpdate == "tool_call" | "tool_call_update"` (Gemini's current emission)

Behaviour

  • No logic change beyond logging.
  • Preview is bounded to 400 chars + truncation marker.
  • Debug-level params dump preserved.

Test plan

  • `go build ./...`
  • `go build -tags sqliteonly ./...`
  • After deploy: triggering a cron showed `status=failed` immediately after `security.tool_granted` for the first attempt and `status=completed` for the second — the gap the granted-only log was hiding.

session/update notifications carrying a ToolCall (or inline tool_call /
tool_call_update kind) were only dumped at Debug level inside the params
blob. Operators could see `security.tool_granted` (permission granted) but
had no way to tell whether the tool actually executed successfully — both
"permission granted then failed silently" and "permission granted and
succeeded" looked identical in journalctl.

Add a structured Info log emitting toolCallId, name/title, status, and a
content preview (truncated at 400 chars) whenever the notification
contains tool-call state. This is what made it possible to diagnose the
recent .goclaw/-path-deny regression — `status=failed` immediately after
`security.tool_granted` revealed the gap that the granted-only log hid.

No behavior change beyond logging volume; preview is bounded.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant