Signals

2026-10-13 / Claude Code

Claude mods join the permission chain before the classifier

Edited by Michael Ruescher

Mods are released and enabled by default in 2.1.287, which ignores the old environment off switch. At cutoff, stable is 2.1.287 and latest is 2.1.296. Admitted mod code can replace an ask or non-managed hook block and, in auto mode, skip the classifier. Deny precedence depends on the built-in guard loading under managed settings or Team/Enterprise sign-in, with allowModsToOverrideDenyRules left false; mods' own process and file calls remain outside tool rules. Ask and environment holds are main-only.

What this changes for operators

  • Managed fleets: use latest 2.1.296 and set managed pluginConfigs[“cc-plugin-sec-default@builtin”].options.allowManagedModsOnly to true. Stable lacks later guard repairs. Before adding disableSideloadFlags, check CI invocations: it also rejects --agents and --mcp-config.
  • Unmanaged users: inspect claude plugin validate for tool.check, then review or remove untrusted mods, or use --safe-mode or --settings ‘{“disableAllHooks”:true}’; built-in mods remain. CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=0 is ineffective from 2.1.287. Keep whole-process containment because mods are unsandboxed.
  • Plugin admission now requires reviewing code that can answer permission questions. A released binary containing the main guard’s ask and environment holds, plus mode-specific denial tests, would settle that narrower repair; it would not turn the guard into hostile-code isolation.

Signal metadata

Source findings

Featured in

Run: 2026-10-13-profile-refresh-2026-09-21_2026-10-13-frontier-v0

Schema: bitter.frontier_signals.v0 / ID: 2026-10-13-claude-code-mods-can-answer-permission-checks

Research evidence and publication history are open in the repository.