Repository navigation
feat(server): switch tool-approval policy mid-session - #607
Conversation
Approval policy was fixed at session creation; the webui dropdown only
affected newly created sessions. Add an `approval` field to
RuntimeConfigUpdateRequest and apply it in place (like the thinking fast
path, no pipeline rebuild): mutate the live ApprovalPlugin via a new
set_policy(), update session.approval_policy, and persist. The webui
approval dropdown now POSTs to /sessions/{id}/runtime-config for the
active session. Endpoint accepts POST in addition to the existing PATCH.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 48 minutes and 9 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
PR #607 applied approval/thinking in-place and persisted BEFORE the fallible replace_session_runtime_config call. A request mixing approval (and/or thinking) with model/provider/base_url would leave the approval policy changed + persisted even when the runtime replacement raised — a partial, non-atomic update. Reorder so the fallible rebuild runs first; only after it succeeds apply thinking_config and approval (to the rebuilt updated_session, so a new pipeline's ApprovalPlugin gets the new policy) and persist once. Approval/thinking-only updates keep the no-rebuild fast path. Add a regression test asserting that when approval+thinking+model are sent together and the replacement raises, the live plugin policy, session.approval_policy, thinking_config, and the persisted store are all unchanged. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Why
Approval policy was locked at session creation. In the webui, switching the approval dropdown (interactive → auto/yolo) had no effect on the running session — every tool call still prompted — and there was no way to change it without starting a new session. (Reported during o6n live RAG testing.)
What
Backend
approvalfield toRuntimeConfigUpdateRequest(patternyolo|interactive|auto; explicit null rejected like model/provider/thinking).ApprovalPluginvia a newset_policy(), updatesession.approval_policy, and persist session metadata.session.runtime_pipeline._registry.get("approval")with a guarded fallback scan; if the pipeline isn't built yet it only persists the policy (next runtime picks it up), and it raises rather than guessing if a pipeline exists but the plugin is missing.POSTin addition to the existingPATCH.Frontend
updateRuntimeConfig(sessionId, { approval })toapi.ts(no such client method existed).runtime-config; surfaces an inline error on failure. With no active session it just updates local state (next session uses it).Test
286 passed(runtime_config_schema + plugins/test_approval + ui/test_http_server). webui: typecheck clean,14 passed.Note
The live-plugin access reaches into pipeline internals (
_registry/_plugins) — defensible given the in-place design goal, but a public accessor on the pipeline would be cleaner long-term.🤖 Generated with Claude Code