fix(telemetry): stop reporting user permission rejections as tool errors

Draft
AL
4d ago
+106-0

Summary

Automated fix proposed by the Altimate software factory; a maintainer reviews every change.

The problem, fix and criteria below are the agent's own account; check them against the diff.

Problem

The session step loop and the tool error wrapper treated a user declining a permission prompt as a tool failure, so each rejection was sent as a permission-class error fingerprint and a core_failure event.

The telemetry message is the masked text of the RejectedError message from packages/core/src/v1/permission.ts:72, which reaches the error_fingerprint loop as an errored tool part and is classified permission by keyword.

Fix

When a user rejects a permission prompt, the CLI no longer sends error_fingerprint or core_failure events, while config-rule denials and real permission failures are still reported.

Acceptance criteria

  • A tool call the user rejects at the permission prompt, with or without feedback, produces no error_fingerprint record and no core_failure event
  • A tool call blocked by a config rule (DeniedError) still emits core_failure
  • Messages like 'EACCES: permission denied' or 'Access denied' are still classified and reported as permission errors
  • The tool_call event with status error is still emitted for rejected calls

Changes

4 files changed, 106 lines added, 0 lines removed.

  • packages/opencode/src/altimate/telemetry/error-detail.ts
  • packages/opencode/src/session/prompt.ts
  • packages/opencode/src/tool/tool.ts
  • packages/opencode/test/altimate/permission-rejection-telemetry.test.ts

New tests

  • packages/opencode/test/altimate/permission-rejection-telemetry.test.ts

Independent review: accepted, confidence 0.86

Verification

  • Verify job: passed

Summary by cubic

Stops reporting user permission rejections as tool errors in telemetry.

Previously, declining a permission prompt was treated as a tool failure, sending permission-class error fingerprints and core_failure events. Now a user rejection (with or without feedback) produces no error_fingerprint or core_failure event, while config-rule denials and real permission failures like EACCES are still reported. The tool_call event with status: error is still emitted for rejected calls.