feat(acp): surface session/update tool_call notifications at Info level#1141
Open
codebit0 wants to merge 1 commit into
Open
feat(acp): surface session/update tool_call notifications at Info level#1141codebit0 wants to merge 1 commit into
codebit0 wants to merge 1 commit into
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
Behaviour
Test plan