You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
serena-hooks auto-approve (introduced in v1.1, tracked in #920) only emits an allow decision when Claude Code reports permission_mode == "acceptEdits". It is silent in every other documented mode.
Claude Code's hooks docs list six values for permission_mode:
permission_mode: Current permission mode: "default", "plan", "acceptEdits", "auto", "dontAsk", or "bypassPermissions".
The most user-visible gap is auto mode. Claude Code docs describe it as:
auto: Auto-approves tool calls with background safety checks that verify actions align with your request. Currently a research preview.
Auto mode is the mode users adopt when they want hands-off autonomous execution — the same use case that motivated #920. In auto today, Serena's MCP tool calls are not auto-approved by Serena's hook; they fall through to Claude Code's auto-mode classifier, which makes per-call probabilistic decisions rather than the deterministic "the user chose a permissive mode, extend it to Serena" semantic that #920 established.
Extend PreToolUseAutoApproveSerenaHook so that Claude Code's auto mode is treated equivalently to acceptEdits for the purposes of Serena auto-approval. The minimal change is adding "auto" to the accepted set alongside "acceptEdits".
How to make that configurable is the maintainers' call. Two shapes I can see working:
--modes option on the auto-approve subcommand. Let users opt into any subset via something like serena-hooks auto-approve --client=claude-code --modes=acceptEdits,auto. Preserves today's default for existing users while letting new adopters opt into auto.
Happy to write the PR once direction is confirmed — per CONTRIBUTING.md I'm raising this as an issue first.
Describe alternatives you've considered
User adds Serena tools to autoMode.allow. Claude Code's auto mode has its own classifier with a prose-based allow list users can extend. In principle this works, but it's fragile (tool names evolve), per-tool (multiple entries), and crosses the boundary Make Serena respect Claude Code's accept edits mode #920 was built to draw — Serena auto-approval should track the user's permission mode choice, not require maintaining a parallel allowlist.
Shell wrapper around the hook. A few lines of bash in ~/.claude/settings.json can check permission_mode and shell out to serena-hooks auto-approve. Works today, but duplicates logic every Serena user has to author.
Verified against serena-agent 1.1.2 (installed via uv tool install -p 3.13 serena-agent@latest --prerelease=allow) and main at commit 14cd3ef.
Claude Code's auto is labeled "research preview" in docs; the permission_mode hook field that exposes it is stable and canonically documented, so coupling to the field is low risk even if auto-mode semantics evolve.
bypassPermissions and dontAsk are also silent in the current implementation. Those modes already suppress prompts at the Claude Code level, so the hook's silence is architecturally harmless — just noting for completeness in case maintainers want a while-you're-there fix.
Is your feature request related to a problem? Please describe.
serena-hooks auto-approve(introduced in v1.1, tracked in #920) only emits an allow decision when Claude Code reportspermission_mode == "acceptEdits". It is silent in every other documented mode.Claude Code's hooks docs list six values for
permission_mode:The most user-visible gap is
automode. Claude Code docs describe it as:Auto mode is the mode users adopt when they want hands-off autonomous execution — the same use case that motivated #920. In
autotoday, Serena's MCP tool calls are not auto-approved by Serena's hook; they fall through to Claude Code's auto-mode classifier, which makes per-call probabilistic decisions rather than the deterministic "the user chose a permissive mode, extend it to Serena" semantic that #920 established.The behavior is controlled by a single literal string check at
src/serena/hooks.py:371:Reproduction
Verified against
serena-agent==1.1.2and main @14cd3ef:Only
acceptEditsemits a decision:All non-
acceptEditsmodes produce no output.Describe the solution you'd like
Extend
PreToolUseAutoApproveSerenaHookso that Claude Code'sautomode is treated equivalently toacceptEditsfor the purposes of Serena auto-approval. The minimal change is adding"auto"to the accepted set alongside"acceptEdits".How to make that configurable is the maintainers' call. Two shapes I can see working:
acceptEditsandautoby default. Simple, matches the Make Serena respect Claude Code's accept edits mode #920 pattern.--modesoption on theauto-approvesubcommand. Let users opt into any subset via something likeserena-hooks auto-approve --client=claude-code --modes=acceptEdits,auto. Preserves today's default for existing users while letting new adopters opt intoauto.Happy to write the PR once direction is confirmed — per CONTRIBUTING.md I'm raising this as an issue first.
Describe alternatives you've considered
autoMode.allow. Claude Code's auto mode has its own classifier with a prose-based allow list users can extend. In principle this works, but it's fragile (tool names evolve), per-tool (multiple entries), and crosses the boundary Make Serena respect Claude Code's accept edits mode #920 was built to draw — Serena auto-approval should track the user's permission mode choice, not require maintaining a parallel allowlist.~/.claude/settings.jsoncan checkpermission_modeand shell out toserena-hooks auto-approve. Works today, but duplicates logic every Serena user has to author.Additional context
serena-agent 1.1.2(installed viauv tool install -p 3.13 serena-agent@latest --prerelease=allow) and main at commit14cd3ef.autois labeled "research preview" in docs; thepermission_modehook field that exposes it is stable and canonically documented, so coupling to the field is low risk even if auto-mode semantics evolve.bypassPermissionsanddontAskare also silent in the current implementation. Those modes already suppress prompts at the Claude Code level, so the hook's silence is architecturally harmless — just noting for completeness in case maintainers want a while-you're-there fix.