Allowlist-based tool selection to cap context overhead as built-in tools grow (alt. to #66073 / #54716)

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

Problem Statement

Claude Code loads its full set of built-in tools into every session by default, and this set only grows over time as new tools ship. The model-specific tools, new agent capabilities, new task/scheduling primitives. Two prior issues (#66073, #54716) measured this cost directly: ~16,000+ tokens across ~30 built-in tools, and 20.2k tokens (10.1% of a 200k context) from built-in deferred tools specifically. I independently measured the same order of magnitude from a separate live session containing 30 built-in tools, 124,646 characters of combined JSON schema, ~31,150 estimated tokens (schema_chars / 4, a heuristic since no endpoint tokenizes a single tool definition in isolation), confirmed byte-identical and resent on every single turn, not a one-time startup cost.

Both prior issues proposed a denylist (disabledTools / disabledBuiltinTools) and were closed as not planned. But a denylist has a structural problem neither discussion addressed: it only ever catches up to what already exists. Every new built-in tool shipped in a future release is automatically on by default for every existing user, silently growing the baseline, until someone notices and manually excludes it. As the built-in tool count grows, which it demonstrably will, given the pace of new tool categories already shipped; an opt-out list requires permanent, ongoing maintenance just to stay even with a moving target. It never actually shrinks the problem, it just chases it.

I built a small local tool tonight specifically to capture and measure these token counts from real request/response traffic, as it's what
surfaced the numbers above and what prompted me to file this.
Happy to share more detail on the measurement approach if useful, and to beta test any proposed solution here.

### Proposed Solution

Proposed Solution

Add an opt-in allowlist instead of an opt-out denylist:

json
{
"enabledTools": ["Bash", "Read", "Write", "Edit", "WebSearch", "WebFetch"]
}

Behavior:

If enabledTools is present, only the listed tools (plus whatever minimal core set Claude Code genuinely requires to function) load into the session, then everything else is simply absent from the schema sent to the model, not just hidden or deferred.
If enabledTools is absent, current behavior is fully preserved and every built-in tool loads exactly as it does today. Opt-in only, zero risk, fully backward compatible and the same safety bar both prior proposals correctly required.

Critically: a newly-shipped built-in tool in any future release does not appear for a user who has already configured an allowlist, unless they deliberately add it. This is what a denylist structurally cannot offer as the default-inclusion problem is solved once, not re-solved by every user after every release.

This mirrors how MCP servers already work in Claude Code, as nothing loads until a user explicitly runs claude mcp add. Built-in tools are one of the few surfaces that still default to 'everything on'. This proposal just extends the same, already-trusted opt-in model consistently across both.

### Alternative Solutions

_No response_

### Priority

Consider this as High.

### Feature Category

CLI commands and flags

### Use Case Example

_No response_

### Additional Context

_No response_

No specific files or tests are named. Start by locating where Claude Code reads configuration and assembles built-in tool schemas for a session, then check how CLI command/flag settings are represented. Done would mean an absent enabledTools preserves current behavior, while a configured allowlist prevents unlisted built-in tool schemas from being sent.

Rédigé par le modèle d'indexation à partir du texte de l'issue.