Claude Code fixes silently ignored Bash allow rules

Claude Code 2.1.282 fixes a bug where Bash permission rules with a mid-pattern :* never matched when they came from a settings file. That's according to the Claude Code changelog. A rule written as Bash(git:* push) in settings.json was silently skipped. The same rule passed through --allowedTools worked fine.

That gap matters because settings files are where teams put their actual allow lists, not flags typed per session. A rule copied from documentation or a teammate's config, with the wildcard placed mid-pattern instead of at the end, did nothing. No error, no warning. It just sat there looking active. The release adds a startup warning explaining how rules get matched, so a rule that fails now says why.

The same release closes a separate gap in permission scoping. Repository, user, and --add-dir skills could previously pre-approve their own tools through allowed-tools even when an organization had set allowManagedPermissionRulesOnly. That setting exists so only centrally managed rules decide what runs. A skill bundled into a cloned repo could route around it and grant itself tool access anyway. 2.1.282 stops that.

Both are permission-boundary bugs, not features. A related fix in the same release closes a settings-driven path for project config to switch on OpenTelemetry export, another route by which a cloned repo's config could act against the user rather than for them. Anyone running Claude Code with a shared settings.json should diff it against the previous version. A rule that silently failed before this release may now match traffic it never touched, with permission consequences nobody tested for.