[BUG] Grep/Glob restore opt-in (2.1.162) only works via --allowedTools CLI args — settings.json permission rules are ignored

Summary

Since ~2.1.161 the built-in Grep and Glob tools are removed from the toolset whenever a shell is available, and the system prompt switches to instructing the model to search with shell find/grep instead. 2.1.162 added an explicit opt-in that restores the dedicated tools: naming Grep or Glob in --allowedTools flips an internal searchToolsOptIn state. The problem: that opt-in is only evaluated while parsing CLI permission args. The same permission rules declared in a settings file do nothing, so the preference cannot be made persistent per-user or per-project, and cannot be distributed to a team via checked-in settings.

This is distinct from #52121 and #64136, which report the removal itself — this issue is about the opt-in mechanism added in 2.1.162 not being expressible in settings.

Environment

• Claude Code 2.1.162, native macOS arm64 (~/.local/share/claude/versions/2.1.162)
• ripgrep present (system and embedded — not the cause; USE_BUILTIN_RIPGREP only selects which rg binary the search implementation shells out to)

Repro

Works — CLI flag:

claude --allowedTools Grep,Glob -p "list your available tool names"
# → Grep and Glob loaded

Works — the one surviving entrypoint exemption:

CLAUDE_CODE_ENTRYPOINT=local-agent claude -p "list your available tool names"
# → Grep and Glob loaded

Does not work — identical rules in a settings file:

echo '{"permissions":{"allow":["Grep","Glob"]}}' > /tmp/grep-optin.json
claude --settings /tmp/grep-optin.json -p "list your available tool names"
# → Grep and Glob absent from both the loaded tools and the ToolSearch deferred pool

Consistent with the bundle: the 2.1.162 gate is j2(){if(!tH("true"))return!1;if(yF6())return!1;return process.env.CLAUDE_CODE_ENTRYPOINT!=="local-agent"} with registry spread ...j2()&&V1()?[]:[eb,yN] (eb=Glob, yN=Grep), and yF6()/searchToolsOptIn is set only from CLI permission-arg parsing (EF6([nO,f5].some((u)=>w.includes(u)||z.some((F)=>kA(F).toolName===u)))). Settings-file rules never reach it. Note 2.1.161's sdk-cli/sdk-ts/sdk-py entrypoint exemptions were removed in 2.1.162, so that workaround is dead.

Expected

Grep/Glob in permissions.allow in any settings file (user, project, or --settings) should trigger the same opt-in as --allowedTools — or a dedicated documented setting should exist.

Why settings-level matters

• Projects that govern Bash usage with PreToolUse hooks rely on the structured Grep/Glob tools as the enforceable policy surface: a Grep tool call is cleanly matchable and permission-scoped, while shell grep/find must be string-parsed out of arbitrary command lines.
• A shell alias wrapping --allowedTools can't be checked into a repo for a team and doesn't reach sessions not launched from the user's shell (daemon/background/scheduled sessions respawn with their own flags).
• When the tools are absent, the system prompt actively instructs the model to use shell find/grep, which directly conflicts with project policies that restrict shell search — the model is left with no sanctioned search path.