Signals

2026-10-24 / Claude Code

Claude's managed guard preserves policy asks over user mods

Edited by Michael Ruescher

The guard at bf2323b3 ships in 2.1.299 and holds policy-backed asks, denies and pinned environment entries over user mods when loaded. Ordinary mode-owned asks are different, and administrators can relax holds. Version 2.1.304 adds decider: "person", which routes to a permission dialog or host callback rather than auto approval. Version 2.1.302 also returns some unconfigured headless jobs from auto to default. Both stable-selector 2.1.308 and latest 2.1.310 contain these changes.

What this changes for operators

  • Managed mod and CI owners: use latest 2.1.310 for the complete current repair set, verify the built-in guard is seated, and keep allowManagedModsOnly=true where user code must not join policy. Released delivery ends the old wait; it does not sandbox admitted mods.
  • Set the permission mode in each unattended job. Without one, fresh installs, third-party providers and telemetry-disabled headless sessions now use default. A job unable to ask can stop where it formerly used auto, creating a deliberate policy decision before dispatch.
  • Test a rule-backed ask against a user-mod allow, an environment-pin change and decider: “person” with neither a dialog nor host callback available. If a human must decide, verify that any host callback actually routes to one. Refusal traces in each deployed mode would settle enforcement; regenerate mod types before using this decider because the public type mirror lags it.

Signal metadata

Source findings

Featured in

Run: 2026-10-24-weekly-digest-2026-10-13_2026-10-24-frontier-v0

Schema: bitter.frontier_signals.v0 / ID: 2026-10-24-claude-code-policy-asks-hold-over-user-mods

Research evidence and publication history are open in the repository.