fix(agent): prompt for destructive PostHog exec sub-tools in auto mode#3514
fix(agent): prompt for destructive PostHog exec sub-tools in auto mode#3514skoob13 wants to merge 1 commit into
Conversation
Auto mode only promises hands-off file edits and shell commands, but the PostHog exec destructive gate short-circuited to silent allow in auto mode, so update/delete/destroy sub-tools were the only exec calls that never produced a permission_request. Non-destructive exec calls already prompt in auto mode (and web clients auto-approve them client-side), which made the gate exactly backwards on the cloud surface: safe calls asked, destructive ones ran silently. Keep the bypass for bypassPermissions only; persisted allow_always sub-tool approvals still skip the prompt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| ) { | ||
| // "auto" deliberately does NOT skip this gate: the mode only promises | ||
| // hands-off file edits and shell commands, and destructive PostHog | ||
| // sub-tools must still surface a permission prompt to the client. |
There was a problem hiding this comment.
When an auto-mode cloud session has no desktop connected, this branch reaches the approval flow, but the cloud permission client falls through to selecting the first option, allow. An unapproved destructive PostHog sub-tool therefore still executes without presenting a permission request, so the changed gate does not protect that reachable auto-mode path.
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
1 participant
Problem
The PostHog MCP exec destructive gate (#1991) re-gates
update/partial-update/delete/destroysub-tools at sub-tool granularity — but it short-circuits to a silent allow when the session permission mode isauto, not justbypassPermissions.The posthog_ai web surface creates runs in
automode and relies on its client-side policy (products/posthog_ai/frontend/policy/toolPolicy.tsin PostHog/posthog) to auto-approve safepermission_requests and show an approval card for destructive ones. Because the gate never emits a request inautomode, that card never triggers.The result is exactly backwards in
automode: non-destructive exec calls (e.g.call insight-create) are not in the auto-allowed tool set andexecis annotatedreadOnlyHint: false, so they fall through to the default permission flow and do prompt — while destructive calls are the only exec calls that run with no permission request at all.Changes
canUseTool: the destructive PostHog exec gate now only skips prompting inbypassPermissionsmode. Inautomode it consults persistedallow_alwayssub-tool approvals and otherwise goes throughhandlePostHogExecApprovalFlow, emitting apermission_requestthe client can decide on.Behavior on other surfaces:
full_auto.How did you test this?
"bypasses the PostHog exec gate in auto mode"unit test to assert the new prompting behavior (gate consulted,requestPermissioncalled with the PostHog-specific title, no approval persisted onallow_once).pnpm vitest run src/adapters/claude/permissions/ src/adapters/claude/hooks.test.ts— 86 tests pass.biome checkclean on changed files; repo-widepnpm typecheckpasses via the pre-commit hook.Automatic notifications
🤖 Generated with Claude Code