Skip to content

fix(approvals): keep approval protocol out of context handlers #416

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
robelest wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

fix(approvals): keep approval protocol out of context handlers #416

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
36e6406
test(approvals): keep approval protocol out of context handlers
robelest Oct 15, 2026
8e19f2b
fix(approvals): keep approval protocol out of context handlers
robelest Oct 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,9 @@
# Changelog

## Unreleased

- Fix continuing a tool approval when a context handler returns history beyond `recentMessages`; context handlers no longer see approval requests or decisions, and pending approvals are left out of context instead of auto-denied (#416)

## 0.7.8

- Fix answering a tool approval after an earlier approval in the same thread
Expand Down
19 changes: 9 additions & 10 deletions docs/tool-approval.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,16 +169,15 @@ single-decision helpers so the request history is read only once.
If a partial continuation requests another approval, that newer request also
remains pending while you resume an earlier sibling.

If an unrelated generation starts while approvals are still unresolved, they
are **automatically denied** with the reason
`"auto-denied: new generation started"`. This prevents broken message
histories where tool calls lack results. These denials are synthetic and only
added to the model's context for that request; they are not saved, so the
approvals remain pending in storage.

This does not apply when resuming approvals: on that continuation, earlier
approvals that were not part of the resume are omitted from that model request.
No response is written for them, so they remain pending in storage.
If an unrelated generation starts while approvals are still unresolved, their
tool calls are left out of its context. The model does not see them, and they
stay pending, so you can still approve or deny them later.

Approval requests and decisions are never passed to a
[context handler](./context.mdx), nor are tool calls whose approval has not
Comment on lines +176 to +177

@ianmacartney ianmacartney Oct 20, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems a little strange to me. I thought the context handler was supposed to have full control over the context. e.g. if users are trying to log all of the messages that are sent to the LLM, they will no longer have a complete picture in this callback?

@robelest robelest Oct 20, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, it misses them today. Exploring giving the handler the full context and resolving approvals after it returns, though the continued decisions would still be appended after it.

run. When generation continues from a decision, the stored calls and decisions
are appended after the handler's messages, so only decisions saved with these
methods can run a tool.

@cubic-dev-ai cubic-dev-ai Bot Oct 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: This wording implies that every tool execution requires a saved approval decision, but non-approval tools execute normally and callers can supply ordinary tool calls through messages. Say that only a saved decision can authorize an approval-gated tool call.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At docs/tool-approval.mdx, line 180:

<comment>This wording implies that every tool execution requires a saved approval decision, but non-approval tools execute normally and callers can supply ordinary tool calls through `messages`. Say that only a saved decision can authorize an approval-gated tool call.</comment>

<file context>
@@ -169,16 +169,15 @@ single-decision helpers so the request history is read only once.
+[context handler](./context.mdx), nor are tool calls whose approval has not
+run. When generation continues from a decision, the stored calls and decisions
+are appended after the handler's messages, so only decisions saved with these
+methods can run a tool.
 
 ## Client-side flow
</file context>
Suggested change
methods can run a tool.
methods can authorize an approval-gated tool call.


## Client-side flow

Expand Down
Loading
Loading